RomRaider

Option #2 it is. I guess I need to add the RamTune "Info" byte address in the RamTune tag (in the ramtune_def.xml). If it's value is "1", the ECU is referencing RAM values, if "0", it is using the ROM ones.

Otherwise, the real-time map-switching activated by some car input (which honestly kinda scares me) seems like it would just add to the ROM code. It doesn't really affect the application.

J

Both could be done, but initially the user map switching can be controlled by RomRaider only. Maybe later if we can figure out how to flash the CEL then the on-the-fly switching could be added.

You would need to define a generic RamTune byte which would be used and which bit corresponds to which flag - RamTune active bit, Map Switching bit, Error Switching bit.

example attributes:


Ramtune Active Bit - SET if RamTune is active. CLEAR - RamTune disabled, no map switching, ecu uses rom tables (RomRaider will set this bit when it writes RamTune maps (assuming no error). Default to clear post-reset.

Map Switching Bit - SET if using RamTune tables. CLEAR if using rom tables. (manipulated by ecu if on-the-fly map switching is used, otherwise determined by RomRaider and defaults to rom tables post reset).

ErrorBit - SET if RomRaider encounters write error (checksum) or possibly some error checking could be added to rom code. RamTune would be disabled. CLEAR - no error. If SET, ecu uses rom tables and map switching is disabled (same as RamTune active bit but is an indication to RomRaider that an error has occured in the past in order to prompt user (maybe have an option to automatically do a ram dump that they could submit to the forums).

I don't think it's necessary to define the individual bit offsets because that's going to be the same among all ROMs, correct?


It appears that we only need the active bit. If the ECU wants to setup the tables and flip this bit, more power. If the application encounters an error, it'll report it when it happens and set the active bit off. Alterations to RAM tables (copying and map value changes) will happen in the following order:

1. Set the active bit to "0", if it isn't already
2. Perform the alterations
3. Set the active bit to "1"

Doesn't that sound like the same functionality, minus some complexity?

J

Most likely. Probably be ok not to define it.


The active bit is cleared after a reset because ram is cleared. Therfore there is no distinction between an error and a reset. I'll probably add some form of error checking in the rom code. So if the rom code clears the RT active bit due to an error, as far as RomRaider is concerned, there's no difference between this and a normal reset even though an error occured (and no indication to the user). No, the error bit isn't absolutely necessary but it does provide the user with more information, otherwise RomRaider will just keep writing Ramtune maps to ram even though there might be an error, say, in the definitions.

RomRaider should not clear the RamTune active bit before it writes to ram as that would momentarily cause the ecu to run the normal rom tables which would be a bad thing if someone is live tuning with the engine running.

RomRaider HAS to deal with the map switching bit, though, which determines whether the ecu uses Ramtune tables or normal rom tables. The user needs to know what the current map switching status is (rom or ram) and also needs the ability to switch between the two when live tuning with RomRaider.

I think I'm missing a subtlety here because the active bit and the map switching bit sound the same.

The intention was to switch to the ROM maps, alter RAM's contents, and pending no failures, switch back to using the RAM maps. I don't see a problem with running the ROM maps for a temporary time to perform safe writes. If someone is attempting live tuning, then it should be safe to assume they have a working set of maps on the ROM. Am I making too many assumptions?

J

Individually they function the same, but together they do provide a necessary function.

Scenario 1:
Let's say we only use the active bit. User resets ecu. Ram is therefore cleared (active bit is cleared so ecu uses rom tables). User then tries to do map switching through RomRaider which would set RamTune to active. Ecu would switch to RamTune tables but nothing is there. Definitely a bad thing, especially if it was done at speed. Car would immediately stall out. With the map switching bit in this scenario, it would also be cleared post-reset. However, flipping the MS bit in RomRaider would not switch to RamTune maps if the RamTune active bit was not also set. Only RomRaider can set the RamTune active bit. Of course, there's a number of ways to overcome this by using only the active bit, but nothing as simple as an extra bit check. For example, you could have RomRaider read the RT block in ram and refuse to set map switching to ram if it is clear, but that adds more complexity than just dealing with the map switching bit.

Also, for future on-the-fly map switching (with defogger switch), I would need the MS bit anyway, otherwise the same thing could happen (user switches to ram maps post reset when nothing is there).

Then you have the whole issue of an error. With just the active bit, and the user experiencing a past write error and then later attempts to switch back to ram maps, RomRaider would allow this. So, the ecu would be running off who knows what corrupted table data.


The rom might not be a conservative map. You don't want to be switching to the rom maps unless absolutely necessary (say a write error where the rom map would obviously be the lesser of two evils). Even if the rom map was a conservative map and say you were tuning on a dyno at high load, it would not be good thing to be switching between two very different maps even if for a split second. We know that with Cobb's proven RT setup they can't switch to rom maps EVER. And they are tuned on a dyno all the time without issue.

I didn't communicate this earlier, but I should've said that if the application decides to activate RamTune by flipping the bit to the "on" position, it would first copy the ROM maps to RAM.


If the RAM maps are derived from the ROM maps, then the ROM has to have worked in some capacity.


Why not? But for argument's sake, let's say that we don't switch to ROM maps before making RAM adjustments. There doesn't seem to be a way to guarantee a RAM write failure could be recovered. Are you saying that when this moment occurs, we then switch to the ROM maps?

J

? I'm not sure what you are trying to say. My response was to clearing the active bit right before RomRaider does a write. This would be bad as it would momentarily switch to the rom map when the user is obviously tuning and expecting to be running off the RamTune maps. The two maps could be completely different. Maybe the rom tune is an economy map. So, switching, even momentarily, without the user wanting to, just before writing to ram would force the ecu to run the rom tune which could have less than desirable results especially at full load on a dyno. Even if it doesn't do any harm, it could result in an unnerving stutter every time something is written.

We only want to switch to rom maps if A. the user switches via map switching B. There is a write error which obviously could have unpreditable results and the rom map would be a better choice rather than some random corrupted table data (say 50 degrees timing at 3.0 g/rev load) C. post-reset.


Yes. A write error should be extremely rare. And the error checking I'm going to add to the rom code would immediately disable ramtune and therefore switch to rom maps if the either the map type byte or row size is incorrect (checking anything else would be too costly in code). RomRaider could also disable ramtune if the write fails the checksum (covering the rest the table not checked by my rom code).

J[/quote]

What I mean by "derived" is that in order to get a map in RAM, it must first be copied from ROM. I.E. you start with the ROM version and then use the RAM to tweak it. When you're finished, you commit it back to ROM. Is there another way to get a map into RAM?


Ok, but like I said this doesn't cover the scenario where a write failure occurs and the new data in RAM is indeterminate (e.g. 14.7 AFR in a high-load, high-RPM AFR target).

J

Another option when an error occurs is maybe I can disable boost control as a safety measure while switching to the rom tables at the same time. That way, if someone does have an aggressive tune as the rom tune, there will be less chance of a problem. And it will be obvious to the user that something is wrong.

I going to assume you will be able to save a real-time map as a file, right? So anyone can create real-time map if they have the copy of the rom in question. And that real-time map could consist of any tune whatsoever within the realm of the 9+ tables that are supported. And it could be loaded by anyone who shares the same rom. So, I could have valet RamTune map that looks nothing like my base rom map. Or a high octane RamTune map that I only use with race gas (or maybe I load THAT as a base rom map which would be a problem if the user is running regular gas with the less aggressive map as the RT tune). Yes, we could tell users to make sure the base rom map is the "safer" version between the two, but not everyone is going to listen.


This would be covered by the checksum handled by RomRaider during the write process as we discussed a while back. If it fails, RomRaider can set the error bit and ecu will revert to rom tables.

As long as the SSM protocol's error reporting is reliable enough, I will report any error as quickly as possible. When the application is in the mode that writes changes as soon as they are entered into the cell, any problem will immediately result in RamTune's de-activation and a popup alerting the user to the problem.

I imagine at this point that the changes in RAM should be considered lost as the next time RamTune is enabled, the RT initialization process will begin again:

1) Deactivate RT
2) Copy tables defined in the LUT
3) Upon success, Activate RT

If you feel the ROM RT programming can provide error information that would be useful to you as a feedback mechanism, we can do that.

J

RomRaider would determine the error:
1. calculate checksum before writing change
2. write via SSM
3. read what was written via SSM
4. Calculate checksum based on read
5. Compare checksums - if different, set error bit.


As far as RomRaider is concerned, the LUT for option #2 is nothing more than key and has no other use. You can't use it to copy anything. Creating a RamTune file based on someone's tuned rom (as a starting point) is done OFF-LINE. The user has their rom on their hard drive and selects some option which allows them to create a new RamTune file based on their rom. They can then tune it OFF-LINE and save the changes. When they hook up their tactrix cable, then RomRaider can copy this Ramtune data from this RT file to ram as long as rom id (ecu id) specified in the RT file matches the rom that is flashed to the car.

That is, when live tuning (laptop connected to car with tactrix cable), RomRaider will NOT be copy anything from rom to ram. Its only function would be to copy already tuned RT tables from an RT file stored on the user's HD OR live tune what is already loaded into ram previously. If nothing is in ram (say after a reset), then the user would have to create a new RamTune file based on their saved rom.

It has to be done this way because you cannot read the entire rom via SSM - it only operates in a limited range. It might be possible to modify the range or it may be possible that most tables would be in the range, but I don't think it is a necesary step. If anything, I could add code to write the tables from rom to ram after a reset (similar to what is done in option #2), so that there's always something there to live tune.

RomRaider should never disable RamTune before writing for the many reasons I have outlined in previous posts. 99.999% there is not going to be an issue with writes, but disabling RamTune (and therefore enabling a different the rom tune) right before the write only introduces the possibilities of problems more than helps anything.

Ok, using the LUT as a key to look up the RamTune definitions, the application would determine which maps to copy.

We have effective access to the entire ROM via the ROM image file that we currently require.

That's fine. I won't de-activate RT before writes to RAM then.

J

Most certainly, during the testing phase, once the UI for RomRaider is done, we can test writes and the added functionality without activating RamTune. We'll get an idea of how common a write failure is (or work out any bugs in RomRaider). The main issue would be how many bytes can be reliably written via SSM. I haven't messed with this much so maybe Paul (Kascade) can chime in. The largest proposed RamTune table, for 16-bit ecus, is Base Timing which is between about 305-325 bytes depending on the rom. The total size of our available "ram hole" is about 1100-1200 bytes for the usdm 02-05 wrx.

What do you think of disabling boost control upon an error? That way, by switching to rom maps upon an error we can minimize any issue if the user is running an aggressive rom map since they will only be running wastegate pressure at that point (and also would give them a clue that something happened).

If we want the ultimate in error handling that will pretty much cover all bases, we could have RomRaider write a word-sized checksum at the end of every table. I can modify the rom code to calculate a checksum as eash RamTune table is accessed and if they don't match, set the error bit and revert to rom maps. Compared to our previous proposal, this would cover corrupted data that didn't involve the map type byte or row size (two easy elements to check via rom code) and a write failure that RomRaider couldn't recover from (say RomRaider freezes in the middle of a write).