RomRaider

At the moment I flash up a message box with an error. I had to deliberately force an error to see that it works.

It would be safest to force a fresh copy of the ROM to RAM (or switch back to ROM maps) if this error occurs. I've not implemented this so far.

by using a single bit to determine whether or not the data in ram should be used, you could do the following:

set the bit to dirty (ie- don't read data from ram)
write all changes to ram
set bit to clean (ie- safe to use data in ram)

if writing to ram ever fails with this method, you could be guaranteed to be using whatever was flashed to the ecu. the way i usually work is to start from a safe base flashed rom and work my way from there. i wouldn't necessarily want some real time changes without others (think about the case where you've raised boost pressure, but not lowered timing accordingly or something like that). that's why i'm thinking if a write to RAM ever fails, just revert everything back to the ROM flash, throw up an error message and then let the user fix it from there.

This had been discussed before and the main issue would be whether or not a notably different ROM tune might cause an problem when temporarily switching from ROM to RAM (during the write) under load (say on a dyno or a road tune). For example, you may be tuning out some knock due to over-advanced timing, and each subsequent write would temporarily run the old "base map" timing. The more you change each RT update, the longer it would run the base map values (unless the sequence was setup to write on a table by table basis). The same argument could be made against switching to ROM values upon a fatal error, but this can helped by disabling boost control and fixing the IAM to 0 when this is the case.

The alternative, without using this method, is that a failed write could cause issues. The most likely scenario would be a partially written table. I don't think it would be likely (possible?) for a failed write to cause an unknown value to be written to RAM table data (as long as the data size is taken into consideration when dealing with the larger tables requiring multiple writes). For example, if the request packet was incomplete or corrupted (due to say a crash of the app or cable gets yanked out), the ECU will not complete nor start the write anyway (the last byte is a checksum). The only thing would be if we were using version 3 (dynamic map selection), you would have to switch to ROM maps when the user was changing the map assortment regardless.

Unfortunately, there is not much error handling we can do at the ECU level. We cannot do a real-time checksum on each table because A. it is too costly and B. the ECU completes writes in 4-byte chunks. A checksum of all the RAM data is possible upon each ignition on sequence, however, where a switch to ROM tables could occur if it doesn't pass. The only real-time error handling at the ECU level we could do would be to verify the map type byte/row size byte, but that wouldn't cover any other table data corruption.

It probably would be safest to disable RAM maps upon writing, though, thinking about it more. Not sure what to do.

What about a new table. Then some bit somewhere that says to use it instead of the standard table. Could even be table of offsets.

stock_table + (offset_table * bit value).

Bit is 0 no modification is used. Bit is 1 it's the sum of both tables.

There's no on the fly writing of a whole table this way. Just the one bit. Getting negative offsets might be tricky.

I really like the old trick I could do in my Civic.
Stock ROM was 256K. Just make two 256K images, put them both into a 512K ROM. Modify a socket to accept the additional pins with a switch on the highest addressable pin. flick the switch and you instantly have an entire new program.

I don't expect any of this. Just jabbering.

I'm not sure what you are getting at, but this is what is already being discussed -> switch to ROM table until RAM table is updated. Unless you mean copy the existing RAM table to temporary location in RAM, write to the RAM location while running the table in the temp location until the write is complete. That is possible, but our ram hole is quite small, so this would severely limit the tables you could real-time tune as the largest 3D tables are around 1/4th the size of our ram hole.

The use model that I am thinking is that an error would be thrown if the write to RAM failed and the user would be instructed to be careful since the tune would be reverted back to the base ROM tune. The reason for this is that we know the ROM tune is good and if we have to choose between the ROM tune and the possibly corrupted RAM tune, then I think the former is more desirable. Again, an error should be thrown and the user could attempt to upload the realtime tune again and hopefully, this time, it should just work. If it fails again, then the user could just flash the tune into ROM and continue from there. Used correctly, I think this is the safest option, but I didn't really think through the performance degradation.

I guess the other option which would be a compromise would be to have an array of bits for each table- then you could only write the table or tables that was modified and hopefully not have too much of a performance problem. Since we are limited to the number of tables that can be put in ram anyway, having a status for each one shouldn't be too bad.

There's no performance issue this way. The performance issue is at the ECU level if you were to have the ECU calculate a checksum everytime the table is accessed and compare it to a checksum written by the app for that table. It also wouldn't work because of the partial writes. As far as disabling the RAM tables when writing, that is not a problem other than what I mentioned as it relates to running the base tune temporarily. In fact, I would set it up so that if the write was never finished, the ECU would never allow switching to the RAM maps (and the app could read this error and prompt the user). That way, you don't have an issue where the user ignores the failed write and then attempts later to switch to the RAM maps through the app (or later when on-the-fly map switching is added).


There's no performance issue with running all RAM tables even though the tables may be identical to the corresponding ROM tables.

What I was trying to get at is avoiding writing an entire table. Reducing failures and checksum issues.
Modify the lookup so two tables are referenced. A toggle bit could effectively make the second table active or not.

From my perspective, using the RAM tables is either reliable or its not, otherwise it is not worth doing. Selectively reducing access to RAM tables would not be a solution because if there's any chance of corrupted values being used, that is a problem in and of itself.

That's a good point. Maybe we are overthinking this- maybe throwing an error and letting the user retry is the best course of action is the failures are very infrequent.

No, what I'm saying is that if there is any chance of a failure and no way to recover from it without user intervention, then real-time tuning should not be released. It needs to be foolproof. We cannot rely on the user to do the correct thing. Plus the fact that if you have corrupted data while the car is under load on dyno, it could mean a blown motor (imagine some random timing value(s) in the base or advance map), regardless of an error message or not.

Reverting to ROM tables while writing would be the safest option with the downside of possible problems if the base tune is drastically different from the RT tune (again leaving it up to the user to know what they are doing). A solution to that would be to only allow writes at idle, but that would hamper dyno tuning. I guess there's no perfect solution.

Imho, the latter will suffice for the meantime until a true realtime map editor (updates on the fly with load cells displayed) is coded, be it RR or some other app.

I finally see what you are saying. The reason I kept missing it was because I rarely make changes while the car is moving- maybe something like AVCS, but for the most part, the thing I use realtime tuning for is the ability to quickly make changes and then test them without having to reflash. I guess you could do some steady-state tuning while on a dyno and change timing or something like that. Since I am not usually moving while making changes, that's why I suggested the error and let the user retry. Never thought about the other case.

I get it now.


Thanks,
Mike

Could you sidestep this problem by making RAM changes only while the car is NOT under load? Like, force the ECU into a limp mode, write, verify, re-write if necessary, and only return to normal after the changes have been successfully verified. Or temporarily bring the rev limiter down to 750rpm during the write/verify stage.

This wouldn't be the same as 'real time' tuning, but it would be much faster than reflashing and would make it very hard for a bad write to do any damage.

That would be more complicated and less user friendly than just temporarily switching to ROM maps.

Really, there are 4 options:

1. Revert to ROM tables during write.
pros: If base map is conservative/close to RT tune, this is a very safe option. Write failure would cause no issues and user could not force the ECU to run the problem real-time tune no matter what.

cons: If under load and base map is notably different, could result in a stutter (say injector flow scaling in base map is different) or possibly problems (say you pulled some timing in the RT tune due to knock, but left it in the base map). Requires user to make sure they have a proper base map installed.

2. Keep running RT tables during write.
pros: no worries about base map tune being different. Best for dyno tuning in some ways.

cons: a write failure could possibly result in a partially written table which the ECU would continue to run. Would rely on the user realizing there was a problem and taking action to reset the ECU/clear the tune (assuming the issue is a connection problem in the middle of a write).

3. Temporarily copy and run current RT table to be overwritten to "staging" area in RAM and only switch to new table when write is verified.
pros: solves the cons of #2/#3

cons: greatly reduces the number/size of tables that can be real-time tuned at any given time. Much more complex to set up.

4. Write changes a table a time and revert to the corresponding ROM tables a table at a time.
pros: partially solves issues with #1 as only the currently written table would revert to ROM values.

cons: potentially not as safe as #1 as if another table is overwritten inadvertently, the ECU would immediately run those values. A write failure relating to enabling/disabling individual tables could cause an unpredictable combination of running ROM or RAM tables.