RomRaider

Hi there, I'm working on a rpm/load based realtime timing tuning tool, after lots of study and research, it is time to do some tests on a living car.

what am i talking about is a 32bit dbw rom.

My plan is:
1. hijack the entry address of the rom, aka the first 4 bytes of a rom.
2. ECU will jump to my code when it is booting.
3. do some patching jobs, after jobs done, jump back to the original entry address.

it is definite that i will make mistakes during debugging. my problem is, if i hung the ecu with some error code, is it possible i can reflash the ecu?

Will the flash process use the ROM code? or is it running in a programming mode when flashing or what?

I don't think it's a good idea to place the hook at the very first instruction. On some systems, the first things that happen include configuring the memory controller, so you may not actually have access to RAM at that point. I suspect (but do not know for certain) that a bug in your code will prevent the reflashing code from running, so yeah, you'd need to send the ECU to Tactrix to get control of it again.

If you unfold the ECU code starting from the first instruction, you only get a few percent of the code, and it seems to end with a tight loop - at address X, jump to address X. My guess is that this code runs after all of the setup code, and everything is done by interrupt handlers after that point. So, that location might be a better place to insert your hook. You'd replace the tight loop with jump to your code, do your setup (copy ROM tables to RAM?) and then do your own tight loop. I haven't tried this, so I can't guarantee anything, but this is the approach I was thinking of using.

It occurs to me now that the processor documentation for reflashing probably has some answers. I haven't read it though.

Thank you very much!
Every point you mentioned is what i need to know.

So it is a interrupt driven model?
Yes, what i m going to do is copying rom to ram.
I'll do some more research then. It is great to read your reply before regret, haha.

On the other hand, should i say it is very safe if i don't mess up the interrupt handlers.
IIRC, merchgod or Freon posted something in a thread said that he never has a reflash issue
if he didn't change anything at the end of the code segement. i guess that is where those
interrupt handlers are?

I'll post at here if i get any progress.

There is definitely a lot of interrupt-driven code. I suspect that everything interesting is triggered by interrupts (crank or cam position sensors, maybe?) but I do not know this for certain. I haven't explored the whole ROM, so there could be a loop somewhere that constantly does important things.

I read about someone who was patching an ECU image and they inserted their code into the image, rather than overwriting region of the image, and that turned the ECU into a brick. There is some important stuff in the higher addresses.

However there is a LOT of space in the ROM image that is just 0xFF, and I figure it is probably quite safe to overwrite that with custom code.

A couple of quick questions:

1.) Are the contents of RAM persisted between ignition ON/OFF cycles? (I would assume so or Cobb's realtime mapping probably wouldn't work.)
2.) Are the contents of RAM zeroed after an ECU reset?

1 - Yes
2 - No

ECU reset rewrites (usually the first RAM word, have a look at SSM_WRITE_0x60 subroutine) and nothing more. At IgnitionOn the program verifies the region where this word (and learning values) lives and wipes those if checksum is incorrect.

Yeah, succeeded!

I'm so sleepy now so I do a quick post and explain later.

The testing rom is a stock AZ1G202G(from edm 08 sti).

I changed the KCA table data address to 0xFFFF5008, it is a static patch. The ECU reads KCA table from RAM address 0xFFFF5008 now.

Then I hooked the MaybeGetKnockCorrectionAdvance function address, and jump to my code to copy KCA table data to a block of free(maybe) memory 0xFFFF5008. My code runs only once by checking and setting a magic number at 0xFFFF5000.


Then I used SSM Test App in RomRaider to change the KCA data at 0xFFFF5008 when the car is running, yeah, it works, see the picture, the changed KCA kicks in at a very low rpm and load range, and effects the total timing.

Now two problems need to be done:
1. A table based front end is needed for easier tuning.
2. I have no idea about the RAM checksum for now, so the ECU will sweep the memory every ignition on, then an original KCA table will be copied from rom to ram every time. Downloading a whole timing table everytime is somewhat bothersome.

Congrats man, sounds like you've made good progress.

Is there actually a RAM checksum? How would that even work since the content of the RAM is changing frequently and, on power down, the state is held and no writes occur. I can understand you implementing a checksum to ensure the contents of the RAM are written to correctly.

I think I'm approaching the challenge a little differently than you. I just don't have enough code together to test yet.

Again, nice job!

Limited area of RAM that contains learning values (IAM, FuelCorrections, FineIgnitionLearning) is checked at IgnitionOn. If sum (or EcuReset word) is incorrect values are reset to defaults.

In order to have correct checksum those learning values are followed by bit inversed 32 word. Thus remains checksum correct.

But the first 32 Denso ROM (512 kB JDM2003 Forester AT) I have checked does not allow this region (FFFF8000-FFFF8FFF) to be written directly by SSM_Write command.

In the engine management systems I've worked with most of the stuff is interrupt driven. Two types of interrupts: time and angle. Usually there are different time tasks like 5ms, 20ms, 50ms, 200ms and so on. The angle interrupts occur for instance once every crank rev at a certain position.

^ Correct.

The big 'Jump Tables' in the low ROM area that contain a ton of jsr, mov, jsr, mov.. all seem to be interrupt driven. I've encountered several that run on a rev-dependent basis, and others that operate on a timer.



That would work, but there are some issues in implementing the hook. On my rom, you can remove two words from the code (bra, nop tight loop) and there is a single word that appears to be unused in the data segment of the first segment. So you could mov.w - jmp, but then you'd have to find a spot below 0xFFFF to put the code or another jump.

The alternatives are to explore the last jump in that sub, and see if there is a better spot to hook at the end.

Or, you could replace the entire sub with mov.l, jmp, nop nop nop nop... point it to your code, which is a copy the original code with the ram transfer stuff appended before the tight loop.

Or, you could point 0x0 to your code, which contains the same as above.

How critical is it that the new code executes that early?

You're probably going to hook into the main code path somewhere in order to add whatever feature you want, like hooking the rev limiter to get LC/FFS, or hooking the MAF scaling lookup to get speed-density. Why not have the code you hooked in that way also do some one-time initialization stuff when it's called for the first time? The engine will be spinning pretty slowly at that point (probably under 1000 RPM), so it shouldn't matter if it takes a couple/few extra milliseconds to initialize some tables in RAM, or do whatever else needs doing.

I'd like to have my SD patch copy the VE table into RAM that way. What's missing is a GUI to actually edit the table.

I think the biggest worry is causing some sort of exception if the ram isn't initialized in time. That and erroneous timing values that could possibly fubar a motor.

Running the init from the 'logic' code should work if it precedes the first reference (I employ this tactic in some of my CEL/prog mode stuff), but if you're using several tables spread across several different routines, which are spread across several different interrupt processes, it could get pretty time consuming to track down the first instance of the first table referenced. With the different interrupt processing chains, it may also not be a consistent order, and wouldn't surprise me if it had significant changes between roms. Imo, using the reset vector would be a more universal, straightforward, and guaranteed process as I doubt there is much, if any variance in the boot-up logic between roms.

The only downside I see is the possibility of bricking a board while debugging the pilot code, but I know of three people with SHbootmode capability, so that shouldn't be an issue.

Ah, good points. I had been thinking of patches like SD and LC/FFS where data involved isn't touched by anything else in the ROM.

Now I'm curious what you're cooking up.

After thinking about it some more, calling from logic is certainly viable with my programming mode stuff.

The programming mode in its current form requires hooking the routines for each table used in map switching. These routines read the 'current_map' written by programming mode and use the corresponding table def offset.

I have the programming code running off of a jump table that appears to always run (key on) on a fixed timer, so initialization shouldn't be an issue. However, in the case that the 'current_map' is not initialized, the logic in the hooks can simply default to ROM.

To use RAM tables, the programming mode routine can check a state flag (initialized/not) in RAM to determine if the tables already exist in RAM. If the flag isn't set, it would call the initialization routine, and set the flag after the write is complete. This would provide a fail safe for someone starting the car during the write, or any other type of interrupt during the write. It might also be wise to change the status register interrupt level during the write to avoid a bad/partial/corrupted write.