Hello all - here goes my first post. As a quick intro I have been into reverse engineering uC firmwares for a few years, usually with a plan to add new functions rather than alter some data. My daily drive is stage 3 S4, d box.
Returning to the topic at hand
I agree with the DPP settings noted above.
Andy's plugin is unfinished, and there are only a few functions labelled. Some are correct, many are not. In particular Andy started calling various routines LookupA, through LookupZ and beyond. Then he tried to isolate what each Lookup did, here was a mistake.
ME7x uses the Lookup routines by data structure, not by motronic function. Ie there is a Lookup which reads 8byte signed integers, with independent external axes. It is not LookupIgnition for example as Andy hints.
I have reversed his plugin
It is a dead end, fortunately it only took a few minutes to figure out what it was doing and how it was doing it.
All in all, the excitement of the old plugin should fade quickly.
Now, where you load the binary. It is interesting as motronic is broken in to three areas by design. The ERCOS real time OS, a library area, and a user code area. What people upload on to the internet is usually the library and user area, starting at 0x800000 code , 0x810000 data and 0x820000 code. ERCOS resides much lower.
When you load ERCOS into the CPU internal rom you can see all those calls suchas calls 0, 754e etc line up perfectly. ERCOS *seems* byte compatible across the family. You can also see how the interrupts are routed through a gateway, some are handled by ERCOS, some are passed to routines in higher memory.
I have been trying to automate some of the donkey work with the reverse engineering. I have created some code which creates output like
With it if you give me an address of some ME7 data and a binary, I can more than likely locate it in another binary if it exists.
Spen