I hope this is the correct place for this thread. I'm finally putting in a bit of effort into some disassembly and interpretation of the Evo X m32r ROM. Since the Evo X ROM uses a language and layout that hasn't been discussed previously on EvoM, I'm hoping this thread can serve as a place to ask useful questions and report useful methods to disassemble and interpret the ROM code.

Anyhow, I'm looking at a USDM 52680018 GSR ROM.

To get my feet wet, I'm starting off by looking at the layout of table data and interpreting the table lookup routines. My hope here is to get a feel for the m32r assembly language and to use the table header data to find RAM addresses for key variables because, ATM, we have no guide to the RAM addresses like we did with the MUT table in the Evo 8/9 SH ROM.

Below is what I've got for the x-axis layout. The x-axis layout is identical to the layout used in the Evo 8/9 SH code.

First word: RAM variable that stores lookup
Second word: RAM variable used for input into axis
Third word: number of table elements

The difference is how the m32r deals with RAM addresses in table axes. It is storing them as relative addresses. To find the actual RAM address, a little math is needed as follows:

AbsAddr = FFFF|RelAddr (sign extension) + RefRAMAddr

The reference RAM address is 0x80C000. For this axis below, the absolute address for the input RPM RAM variable is:

AbsAddr = 0xFFFFC746 + 0x80C000 = 0x808746.

The x-axis below was for ignition table lookup, so for the 52680018 ROM, it appears that the RPM RAM variable used for ignition table lookups is 0x808746.

The load RAM variable for ignition table lookup is is 0x808590.

 

and about 1% of EvoM readers will understand any of this

 

Nice find, what an odd way they do it! That will need some creativity for cross referencing as you mentioned by PM.

I mentioned to gunzo that there was more code likely to be found by disassembling the interrupt vectors for timers if it is anything like DSM and Evo 7-9 code. Not sure whether this is a remaining issue or not?

Also, finding the entry vector was interesting until it was realised that it is actually an instruction to be marked as code, rather than a vector to be marked as data. Just a note for anyone puzzling over their first disasm attempt.

 

Yeah, there is no specific forum for this kind of thing on EvoM. For the Evo 7/8/9, this type of discussion happens in the Evo 7/8/9 ECUFlash forum. Seems to work out ok.

 

Yeah, its kind of an odd way to do the RAM address referencing. The math I took from the table axis subroutine, and the ref address I took from Colby's script. I don't know how he figured out the ref address, but it seems to be right.

I spent about 1/2 day going through finding more vectors and unanalyzed hex. I'd say that autodisassembly gets only about 2/3 of the code. There are many indirect references to subroutines (stacks of subroutine addresses), so quite a bit of searching for unanalyzed hex seems to be necessary. I suspect that some of these indirectly addressed subroutines are OBD related, as that's what many of the indirectly addressed subroutines in the Evo 8/9 ROM are as well.

 

Indirect addressed subroutines are likely non engine related also (gearbox/immobiliser/ETACs comms etc) .. that should account for some of the unreferenced maps I was telling JCSBANKS about ..

Good thing about this newer ROM is there's plenty of room for expansion ..

 

I am somewhat familiar with open ecu and what the tables look like, and am currently trying to learn more about how to correctly use the interface. I have read NJ1266's write up on "how to tune an evo" and found a lot of useful information in there, but I am still trying to learn more. As far as this stuff goes... I'll just come right out and say it; I have only a vague conception as to what I'm looking at here. I assume that this "code" is what needs to be deciphered and interpreted to correctly create the open ecu software, correct? How did you guys even get this code to begin with? Did you guys just use a tactrix cable to pull the ROM image onto a computer? I know much more about cars in general and engine management than most people, but you guys are clearly in a different league so can you help an aspiring student learn more about this? Thanks for any help.

 

very thoughtful of you to start this thread. I will be starting my disassembly work soon in a few days. Its been a while since I did anything this hardcore. This will be a good reference thread for me.

 

The ROM is made up of tables of data and code. ECUFlash is used to read the data (ign tables, fuel tables, etc, etc), and there is other software (freeware and non-freeware) used to translate the hex into code. Knowing engine control concepts and having some experience with programming are both needed to do this kind of stuff. Its still a challenge though if you've never worked with assembly language. Took me several years to get the hang of it (hobby-level effort), and there's still so much that I need to learn about embedded processors to understand some of the finer aspects of how assembly language is used to control embedded processors.

The more people, the better!

 

+1 it looks like we are in the same boat . I have always wanted to know how to do this!

 

I believe the FP is set in one code path and left alone. Unfortunately lots of compilers are using indirect addressing, some nastier than others

 

Is this the right software manual?
http://documentation.renesas.com/eng...mcu/e32rsm.pdf

 

Yep, that's the right software manual. Some of the basic register handling commands are not included in the manual though. I can post a link to a more complete command set tomorrow.

If you want to download the processor manual, it appears to be a 32182 with 1 MB ROM size and 64 KB ROM. RAM starts at 0x804000 and ends at 0x813FFF.

 

Thanks, would like that link. Could you also post a snippet (or all of it) of ECU code if you have it?

 

I think there is a 10,000 character limit per post. The code size is roughly 512 KB... way too huge to post in its entirety. I could post up a short example (1/10000 of the total code size) tomorrow maybe.