RomRaider

Yea, I wondered that myself. I've followed the bulk I/O serial transaction guidelines that I've seen EcuFlash use. It's trivially easy to tweak these values in code.


It seems like a good compromise. It still doesn't address the core issue where the ECU still has an opportunity to read and use that potentially hazardous mis-written address. I'm with you on not liking momentarily switching to the ROM maps because it'll look like a hiccup when the ROM and RAM are sufficiently different, though. Let's just switch to the ROM maps after a failed RAM write just because it's easy and the alternatives look pretty much the same.


You're right about this, but from what you've told me in the past I didn't even consider it because it sounds too expensive in terms of ROM space, ECU execution cycles, and development time.

J

Scratch that. You're right. We need to have the ECU run minimal boost and thus the "error bit" is necessary.

I'm with ya

J

checksum with CRC would definitely be out of the question, but not sure about a standard checksum. I think can add it and keep it a manageable size. Not so sure about its impact on the ecu. My gut tells me it won't make a bit of difference and should be fine even though it is a relatively memory intensive operation that will be run often.

The only other thing I can do that is easy and efficient is checking the map type byte and row size for 2d/3d table. But if the write error corrupts anything but these two bytes in a table, the error would pass unnoticed. So, I guess in any case, we need to come up with a write function in RomRaider that is as reliable as possible and one that can recover from a catastrophic failure.

The only thing the application can do after a failed write is tell the ECU to use ROM maps and disable boost control via the two bits we discussed earlier. I toyed with the idea of multiple write attempts, but the ECU has a lot more opportunity to use the indeterminate value during these attempts.

The problem with all of this is that:

1. Switching happens only after a failure -- the ECU has an opportunity to use bad values
2. If/when a failure happens, the opportunity for another failure exists when attempting to write to the RT active bit or error bit

I think we're just going to have to live with these facts if we don't want to switch to the ROM version before RAM writes. The risk for me personally is acceptable.

Also, I think that the "limp-mode" that we're introducing (the boost control / error bit) would be a very useful tool for all RomRaider features. Can we just tap into the ECU's existing limp mode functionality?

J

I starting looking at the SSM read/write subroutines and it appears that the ecu will read/write 12 bytes at a time. That is, if you send a request to write 72 bytes, it would be finished after 6 executions and THEN send back the confirmation string. Perhaps this is done to avoid bogging down the ecu? This also occurs during logging. I had assumed, before, that the ecu was sending back the logged items individually, because certain values were out-of-sync (that is, you could tell that some parameters were polled a slightly different times). But Kascade had said that the ecu returns all the requested parameter values in one string. However, what I think is happening is that the ecu polls 12 bytes at a time and won't return the entire string until it is done. That means, depending on how many items you are logging, groups of items will be logged at slightly different times.

I'm not 100% sure of the above. I only messed with it for like 10 minutes. But it seems to explain a lot. And does present some issues for RamTune. If it is true, then a checksum completed by RomRaider would probably be too little, too late, depending on how much is written. A solution would be to only allow changes up to 12 bytes at a time when live tuning outside of idle (that is each upload). Regardless, RomRaider should only write values that change. That means it should first read the table in ram, compare the values to the user's changes and then only write that which has actually changed. We could set it up to allow full writes (all RamTune tables) or changes over 12 bytes only at idle.

EDIT: Come to think of it, when the user first start live tuning, RomRaider could read the current ramtune values and display them to the user. Then if the user increments/decrements a value it would be automatically updated in ram (instead of user making changes and then hitting an 'upload' button). If out of idle, user would not be able to select groups of table values over 12 bytes. If in idle, user could make large changes to the tables or even upload an entire new ramtune map.

EDIT2: Looks like it actually read/writes 4 bytes at a time, not 12. I'll have to mess with it more to see what I can figure out.

Ok, more info:

If my calculations are correct, you can read/write about 250 bytes per request to the ecu. The ecu will read/write 4 bytes per execution of the SSM sub, I would guess as a means to not bog down the ecu when large read/writes occur. When finally all data is read/written it will return a response string.

When writing, the ecu will immediately read what was written, store this and return it in the response string when completely done. This means that it is unnecessary for RomRaider to write and then immediately read since this is already done by the ecu. RomRaider merely needs to look at the response string and compare it to what was supposed to be written. The problem with this, though, is that if the write is larger than 4 bytes, then the ecu will be running the corrupted data for a small period of time until RomRaider can set the error bit.

The last byte of the response string is a checksum (bits 0-7 of the sum of all response bytes). When a request string is sent to the ecu, the same type of checksum must be calculated and sent although I don't know what happens if your checksum is wrong.

Since Denso/Subaru found it necessary to limit read/writes to 4 bytes at a time (if I am correct, that is), then it probably would not be a good idea to use a checksum in the rom code. The only error checking I can efficiently implement would be checking the map type byte and col/row size. This would only catch errors where these bytes are overwritten, however.

As far as failsafes, we could hack two things fairly easily - disable boost control and disable KC (that is, KC = 0).

I was just about to post agreeing with this

Bump, as per post37670.html

I'm in the middle of life now, but will start a new thread to define the XML.

EDIT: here topic3881.html