RomRaider

I've been pondering creating a standalone RAM flashing and patching utility in order to allow for real-time tuning without worrying about the future development as it relates to RomRaider. The utility would do the following:

• Patch supported ROMs with RT code and map assortment that you choose (which user would then flash to ECU with Ecuflash)
• When connected to the ECU, determine current map assortment and allow user to open a ROM file and flash the RT-equipped tables from the ROM file to ECU's RAM (thereby changing the RT tune).

This would allow me to create a RT tuning solution without coming up with an editor from scratch. You would simply use RomRaider to tune your ROM, save, then open that same ROM file in the utility to flash the corresponding RT tables to the car. Not as good as tuning it directly, but still should be useful.

Problem is, there's a number of different ways to implement the RT tuning functionality. Each has its pros/cons. Looking for some feedback:

Version 1 (static maps / no on-the-fly map switching)
ECU would always run off RT tables in RAM. Post-reset, ECU would copy corresponding RT tables from the ROM to RAM. Changing maps: User could select any assortment of 1D/2D/3D tables currently defined by the latest ECU defs (and a combo which would fit within the RAM hole) and utility would update their ROM for which they would flash with Ecuflash and then be able to RT tune from there. This version is similar to Cobb's setup with the exception of allowing the user to choose any assortment of RT maps.

Pros:

• Allows RT tuning of any map (including 1D which would not be supported by other versions). Changes to map assortment require traditional flash.
• ROM code is very compact and very straightforward (compactness relevant for 16-bit ECU which have limited code space)
• Straightforward to user - no confusion on what tune is being run.
• This version would be the easiest to develop the flashing utility for.

Cons:

• No failsafe. ECU will always run RT tables from RAM. So, if RAM gets corrupted (from a bad write, for example), the ECU will continue to run those values and nothing can disable it except by flashing back to non-RT ROM with Ecuflash or resetting the ECU (which could be handled by the utility if it detects a problem but no possible with ROM code).
• No on-the-fly map switching possible.
• More difficult to test for bugs considering the number of tables added with 1D support.

[*]More time consuming (greater chance of bugs) in setting up for different ROM revisions.

Version 2 (static maps / on-the-fly map switching)
ECU has the ability to switch between RT tables in RAM and corresponding tables in the ROM. This could be done by the user on-the-fly (some combo of defogger switch/RPM for example), by the utility (user requested or if the app detects a problem with the RT tables), or by the ROM code (if it determines an error with the RT tables or post-reset). Changing maps: User could select any assortment of 2D/3D tables currently defined by the latest ECU defs and utility would update their ROM for which they would flash with Ecuflash and then be able to RT tune from there.

Pros:

• on-the-fly map switching allows you to change between RAM RT maps and ROM RT maps as you drive (requires no laptop). You could have a economy tune and then switch to a performance map with some combo of defogger switch and something else while you are driving.
• Allows for switching (by ECU or utility) to ROM map if a problem is detected with the RAM tables. Although this would only handle a narrow range of problems (checksum is too costly in CPU cycles to implement, plus issue with the partial write method of the ECU makes it impossible).

Cons:

• Larger and more complicated ROM code.
• Since we don't know how to flash the CEL, driver would not normally know when/if the ECU switched to ROM or RAM tables. "Base" ROM map would have to be conservative in case the ECU switches to it (due to an error). This could be confusing to the user (or damaging if someone put, say, a race gas map as their base map).
• Take notably longer to develop for utility than version 1.
• User couldn't add 1D tables to map assortment (only "injector flow scaling" 1d table would be supported and which would be added manually to ROM code).
• Greater chance for bugs due to the increased complexity.

Version 3 (dynamic maps / on-the-fly map switching)
Same as version 2 except the user can change their map assortment at any time without flashing (using the utility).

Pros:

• Same Pros as version 2
• User could change their map assortment at any time (although if you remove a tuned RT table from an assortment, ECU would default to the ROM table).
• As far as ROM code, not anymore complicated than version 2

Cons:

• Same Cons as version 2
• Development for utility would be more complicated than version 2 and take even longer.
• May be confusing for users who may not understand that when they remove an RT map they tuned from the assortment, that the ECU then defaults to the ROM table.
• May be overkill since you would still have to flash to make the changes permanent in order to move onto another assortment with what you done so far in the tune.
• Reduces the size of our RAM hole which potentially reduces the number (total size) of allowable tables in the map assortment.

I agree this would be useful, but you can't really call it Real Time Tuning. It's more like No Reflash Tuning.

Let me see if I understand the scenario correctly. Suppose I'm connected to the ECU and running this new program and decide I want to change the value in a cell in the Timing Advance (Maximum) table. In order to do this I must:

• Close this new program.
• Open the ROM image file in Enginuity.
• Open the Timing Advance (Maximum) table and make my change.
• Save and Close the ROM image file in Enginuity.
• Open the new program again and tell it to rewrite the Timing Advance (Maximum) table to RAM.

I vote for Version 1 in the original post.

You wouldn't have to do all that:
1. Open ROM file in RomRaider
2. Make your tuning changes
3. Save ROM file (keeping RomRaider open)
4. Start RAM utility (if not already open)
5. Select File to read from (or there could be user-defined default) and choose to write RT tables to RAM
6. Go to step 2 to continue tuning

This would work because RomRaider does not keep your ROM file open once it is loaded. My app would also not open the ROM file until you do a write (you could select the ROM file name without actually opening it). So, after you hit step 6, you would be making tuning changes, save ROM file in RomRaider (same name), hit "write to ram" in my utility and so on.

The only potential issues is that RomRaider's logger (or overlay feature) could not be open. The only way to do the overlay (i.e highlighting current cell), would be to have the RT functionality added to RomRaider (or table editing functionality added to my app).

I like your idea and think it would be good to apply to the Evo.

In Ecuflash you can make an alteration and hit ctrl-s to save. Could leave it open and simply switch to another task that already has the same file name and it can read the buffer and write it to the ECU.

So far I've done a rudimentary PC program to edit fuel and timing maps and read/write them to RAM on the Evo. Can also load/save and copy/paste. However, I think it is best to abandon this given your brilliant idea.

On the Evo I think the best method is to use a 2k area of ROM for the realtime maps that are copied to RAM when the ECU is started. Presently they are spread around the ROM but we can change the pointers to organise them into a block. Ecuflash defs can also be updated to show the new locations.

Then I could use a routine to dump this 2k to the RAM. I think I would get the ECU to calculate a checksum on this RAM block after it was written and then get the PC app to show they were matched.

I can send the 2k of RAM to the Mitsubishi ECU in about half a second using my new DMA routines.

I didn't know this. I expected that any file editor, like RomRaider, would acquire and maintain exclusive use of the file while it is being edited (in order to prevent other editors from updating the file at the same time). The fact that it doesn't is a little bit scary.

So the "Change a table value" scenario isn't nearly as bad as I thought.

In this case it would seem to work better if each application reads the file into its buffer and works on it, and then writes out the buffer to save it when commanded to. This is the way Ecuflash appears to work since you can open a file it already has "open" with a hex editor concurrently.

I'm sure there would be improvements where the keystrokes to save the file in the editor and then write the info to the ECU in another app could be done in a macro.

Yeah, it is just too much work to come up with an essentially the same functionality from scratch as RomRaider/Ecuflash as it relates to table editing just for real-time tuning.


That's an interesting idea. This would work with our 32-bit ECU as well.

Without blowing smoke up your a$$ Merchgod, it is great to read your posts. They often give me good ideas! Thanks. I've been "worrying" about how to edit well for weeks.

The ECU already maintains data critical to engine operation in RAM. I doubt the ECU's microcode is doing any "checksumming" on that data. I expect that the ECU's microcode relies on hardware detection of any errors writing to RAM.

no problem. I am full of ideas, but often fall short with implementation. You Evo guys have got a lot done. I'm jealous.

Jon, the Evo's datalogging is very simple - send a byte request, receive a byte reply. There was no facility I found on disassembly to allow me to send a byte or block to the ECU's RAM like there is with SSM. So I rewrote the comms, and the final version uses a previous unused block of requests. After the initial request byte I wait 5-10ms for the ECU to process it and then I send a 6 byte packet at 62500 baud which contains a 4 byte address, 2 byte length. The ECU receives this using DMA, then it sets up a second DMA transfer to read, read indirected or write to the specified address and length. It seems to work fine (very fast compared to conventional comms, 4200 bytes per second), but I need to add two crucial elements - timeout on the ECU side in case the data written to it never arrives (eg cable unplugged, PC crashes etc) which would lock up the logging until the ECU is reset and checksum as I mentioned to ensure that the data received by the ECU and written to RAM matches what was sent by the PC. Since using the method Merchgod suggests I would not have a facility in my PC software to read out and display the RAM contents. A quick bit of code to do a simple 16 bit checksum would be better than nothing though.

Any chance that version #2 or #3 could work with a simple alky system's failsafe?

I know the EVO guys have figured out how to have on the fly map switching triggered by the a relay (most notably the relay in the alky system's failsafe). It would be pretty cool if we could do that.

Yes that would possible if there is an available, unused binary input. Although, I leaning towards version 1 because of its simplicity.

I would suggest going with the simplest method to give users something to work with, then as time permits work on more advanced implementations.

I just appreciate anything that improves my ability to tune my car so what ever avenue you decide is great. I am cheap (why I don't have an AP1/2) but very patient . Every time some new functionality comes out I donate to the cause though.

Jeff

Sounds great, I would go for number 1 with a checksum on the RAM tables. Dynamic tables aren't necessary, and map switching can wait.

How can we help? Do you need ram dumps?