RomRaider

I have read with interest the work on RAM tuning on the Subarus.

I have an Evo 9, and whilst this is not directly RomRaider related (I have used the software for a Subaru 05 STI - very nice BTW), I thought it would be nice to discuss progress with you guys.

The Evo 7-9 uses SH7052 or 7055 chip.

I am working with others on disassembly. I have already inserted my own code segments to map switch between the existing low and high octane fuel and timing maps in ROM, but like you guys I want to do real time mapping.

The problem is that the Evo MUT protocol we're all using that is high speed compared with OBD II only sends a byte request which is echoed and followed by a byte reply. I need a protocol that can read/write byte/word/long, and then I think locating maps in RAM and modifying them will be possible. Here is what I posted on evolutionm.net that may be of interest. I think you guys are well ahead of me on the Subaru but I think the comms are holding you up too? I'm really interested in your thoughts here or on evolutionm.net. http://forums.evolutionm.net/showthread.php?t=250922

"Having successfully inserted a jump in to the ECU code and inserted my own routine to change a single RAM variable in response to a requestID, the next step is to consider how to implement real time mapping.

The comms protocol is I suggest the place to start.

We need a method of reading and writing to RAM. To do this we need say:

One byte that is a command such as read or write
Four bytes to give the address (or maybe two if we are always in a 64 kilobyte range)
One, two or four bytes for the result of the read or the value to write

So really we need to send and receive packets. We need three write and three read commands to work on byte, word (2 bytes) or long (4 bytes). We need all of these lengths, because mapped values to change can be either byte or word. Addresses to relocated tables will be long.

A good protocol THAT IS SIMPLE, worked out now will pay dividends later.

This is I think the most difficult part of getting real time mapping going. It is fairly easy I think to relocate tables to other addresses by simply using a vector table in RAM that tells the ECU where to look - either the original ROM or in RAM.

Writing a protocol from scratch would be a pain and buggy! Hijacking something already there would be good. Bez's mods allowed the request ID to write out two bytes, hopefully we can modify it to do up to 8, and also receive up to 8.

I'm fairly happy to write the routines to process these packets I think. I'm using the Lauterbach monitor for assembling snippets, although I have to work out the offsets to read variables manually(!) and I then have to manually transfer the hex into the ROM using a hex editor."

The trouble IMO right now is getting something that will properly read all of the RAM in a reasonable time. On top of that the protocol for the 16bit and 32bit ecu's are farily different. We have been able to read RAM from 16bit ecu's in the past with ecuexploer but not the 32bits. With that, the 16bit ecu's will soon have the ability to tune in realtime but far away from the 32bits. From what I understand, the code has already been written to implement realtime tuning for the 16bit ecu's. The only hold back now is writting this into the current RomRaider format which will require an overhaul of the programming.

Awesome news! This isn't at all unrelated, actually -- we're working on an overhaul right now which should fix a lot of the existing problems with the tuning interface, including allowing support for signed integers, which is the only holdup for Evo support.

jfitzpat is working on interfaces for the logger which will allow protocols to be added quite easily, and we're planning on adding MUT. From there it should be relatively easy to add the ability to read blocks of memory, and in fact we've been planning that as well for reading stored 3d learning tables.

Writing to RAM is something we haven't really tried yet. Tinywrex and ev8siv3 had some success doing it via SSM, but I haven't had a chance to look in to this for myself.

Reading the memory shouldn't be slow -- with SSM we're able to log 10 parameters (20 bytes) at 10hz. Reading the entire 32kb is of course slower, but we won't need to do that for realtime tuning -- a full 16x10 table on a 32 bit ecu would be under 1kb, and you'd be able to do whatever you want while it's reading.

MUT protocol is a similar rate, about 200 per sec, although we have worked out how to increase the baud rate by making code changes in the ROM.

If we're economical then most of the time a modification should just be a simple human entry of a new value in a cell, or maybe a block inc/dec/scale.

John the SSP has built-in single write/blockwrite commands. In fact you need 1 command only, the blockwrite and you can use it for bytes, words,doublewords etc.
e.g.
<command byte><address><#data bytes><data>[data][data]

I havent looked into MUT protocol at all but i would suspect that is has a similar command. So either you dive into the disasm, or find out if a dealer tool has the ability to raise/lower idle or stuff like that (subaru does), that would imply that the command is there.

Can't find a read/write already in the protocol.

So I think we'll be expanding the byte request, byte echo of request, byte result to words. We already have the result changed to output as a word, really just need to get the request to the ECU as a word in a buffer, then I can play with it.

http://www.aktivematrix.com/forum/viewtopic.php?t=158

Now got a block read routine running, and a block copy.

So I have a datalogger command I can use to copy fuel map from ROM to RAM. I changed the pointers to run the fuel map from RAM and it works, can be edited by stringing together requests in a window. Obviously needs a GUI like you guys!

man, you evo guys are no joke.

We've got a bit further... but have yet to get the GUI to display the fuel map that can be read from RAM and send appropriate editing commands back to the ECU.

http://forums.evolutionm.net/showthread.php?t=261072

Just some debate on where we go with the protocol since the standard protocol is byte request, byte reply, and I am sending multibyte requests and replies using buffers and counters in my own code.

One user wants to scrap the entire Mitsi/OBD logging protocol entirely to setup our own without needing any init procedures, but the US guys need OBD compatibility for inspections.

Can you set aside a byte which, when set to a chosen value, causes the ECU start speaking your custom protocol? If you're ready to go to the trouble of creating a custom protocol, then adding some code to switch between protocols doesn't sound like much extra work.

(Says the guy who hasn't written asm since 1994.)

Yes I think we could do that.