I've patched my JDM Evo IX to allow me to read any memory location from Evoscan.

I type in the following into Evoscan custom request ID box with repeat custom request unticked:

E0
FF
FF
80
07

E0 is the unused request ID I've hijacked to send a 4 byte memory address from the loogger to the ECU. The address in this case is FF FF 80 07.

Then when I send E1 I get the reply with the contents of the above address.

This is not an end user product yet. Tech details on aktivematrix here:
http://www.aktivematrix.com/forum/vi...hp?p=1881#1881

Next step will be to use request E2 to load another buffer probably just of one byte. E3 will then write this byte to the address we defined with E0.

Then if you happen to have your maps in RAM you can do live mapping.

The steps to putting the maps in RAM are:

1. Change the pointers in the flash to point to RAM for the maps we want in RAM (easy).
2. Run a routine when the ECU is started to make sure the RAM contains valid data, if not copy the original ROM contents to RAM (routine is not too tricky, but research will be needed to find where to patch the ECU startup routines).

 

most of what you said is way over my head but if this means progress to getting live logging working this is very cool

thanks

 

This can be used not just for live logging, but for realtime live tuning, without the necessity to flash the ECU. Basically, you will be able to update the maps in the RAM itself.

The benefit is that you can tune on the fly with the car running....no need to shut it off, flash, turn back on, etc. Plus, you don't have to worry about the limits of flashing your ROM.

Basically, you can use the RAM to fine tune and then flash once or very rarely to keep this 'base' tune in the ROM.

I think this is great progress by jcsbanks. Good work!


Eric

 

that's nice, I'm spoiled by my e-manage setup on my Stealth and it's ability to tune while I'm rolling down the road. It's great because my brother can punch in numbers for me while I'm driving.

will this also allow the ability to trace the cells it's accessing live?

 

Now I have it writing as well

 

See screen grab of the datalog

 

Very nice! Great work, John!



Eric

 

Wow, very nice man.

 

Although I've been watching this fairly closely, I have stayed in the background until I knew for sure this stuff was working and we had a workable method for maps.

But remember, there's TONS of stuff in ram already that can be read in realtime.

Just remember, the existing MUT table contains alot of info that we don't clearly know what it does yet. And I think there are extended MUT values that we don't even know yet, and I suspect many of them are actually extended requests that I'd like to figure out, since I am thinking some of this might actually be in those requests. But we're still trying to understand whats in the existing code.

 

Within my limited abilities, I haven't been able to find any protocols I can decipher that read/write any address through the existing protocols. Most of the more complex stuff seems to be OBD related. Bez hasn't found anything of note in the disassembly that helps further I don't think, but obviously his work so far has been the foundation of what I've made here. So I agree there may be stuff there, but finding it is beyond me, and I suspect anyone else involved except Bez. Even then for Bez, the protocols aren't exactly easy to follow for these sorts of comms, they are horribly convoluted by their nature due to the protocols involved. We're also looking at disassembly rather than commented C which makes things quite tricky.

So we need to decide whether to adopt the protocol I've defined here for our real time mapping methods, because we need the loggers to support it, and I am unskilled in coding the PC side. Unless any other volunteers step forward to look at it I suggest we ask Bez whether to go with this protocol or look for something existing that might not be there?

There are parallels with the Enginuity project here - they have routines on the 16 bit ECUs for read/write, but I think they've stalled on stuff for the 32 bit ECUs for now and will need custom code.

I'm presently extending it to word read/write, properly latched so that the data isn't being changed in between reading/writing the two bytes.

 

Yeah, we'll keep that portion of the discussion on Aktivematrix until something pans out. I think your right about the extended stuff being used by OBD-II I just wish we could get through that stuff already since it seems like the community has quite a bit of interest in fixing CEL codes and other things.

 

CEL codes are another tricky area because they are so linked in with status bits that are really obscure.

It is easy to get lost in my own code segments and keeping them organised because assembly is often quite messy especially on the SH2 because you have to do most things through memory rather than immediates, and the conditional branching is very basic - this makes the code harder not easier to follow! The complexity is low compared with the whole ECU, but if I just gave an uncommented unlabelled hex file of my routine at 0X37000 to process custom request IDs it would be extremely difficult for anyone else to decipher I think.

 

Assuming you never d/c the battery or whatever it takes to clear RAM .

Good work john .

 

yeah this is begining to annoy me a bit - i just love the efficiency of all those pointers...