ECU Disassembly - the very basic version

[AndyF]

Oh God, where do we start!!!!

Right then, in simple terms, the ECU code just consists of a series of hexadecimal (http://en.wikipedia.org/wiki/Hexadecimal) numbers that it uses in order to tell it what to do.

Now in order to be able to see all these numbers, you need a hex editor. I use ECUEdit but there are plenty of free editors out there that will do the same job.

So when you open up your bin file in a hex editor you will see something like the following

http://i64.photobucket.com/albums/h200/Andyfox21/ECU%20maps%20etc/hexmap.jpg

Now you're probably sat there thinking :eek: WTF is all that :D and that is where the fun part of disassembly comes in

[AndyF]

The next thing that you then need to find is either a good disassembler program (IDA Pro is very good but quite expensive) or you can try and find a code seeking disassembler for your particular processor type.

What these programs do is convert the above hexadecimal values into something very slightly more readable. They do this by having effectively a table within them that converts each hexadecimal value into a particular ECU instruction.

For example, in the early evo processor, a hex value of 96 actually means 'load accumulator A with the memory value contained in the next hex value'... a value of 39 means 'return from subroutine' and so on. These tables that the disassembler has within them are just convertors really to try and get the code into something that we might have a hope of understanding.

Again, although this is the early evo processor version, you can see the list of what numbers mean what in the instruction set pdf file I posted up here (http://www.geekmapped.com/forums/showthread.php?t=7).

So the output from the disassembler generally looks something like the following (again, based on the early evo ECU I'm afraid)

http://i64.photobucket.com/albums/h200/Andyfox21/ECU%20maps%20etc/disassembly.jpg

See, it's now all so much clearer than that silly looking mash of hexadecimal numbers isn't it :D :D

[AndyF]

Now this is where being a :> really comes into it's own. It's all been relatively easy and straightforward so far.

The next step is in trying to understand what all of the above code means in terms of how the engine ECU actually runs etc. etc.

This is the part that takes days/weeks/months of testing and checking and hitting your head against large heavy objects however you then, if you're really lucky, may end up with your disassembly looking something like this (again, this is from my own early evo disassembly so others will probably look different) and also note that this isn't fully finished etc...

http://i64.photobucket.com/albums/h200/Andyfox21/ECU%20maps%20etc/commenteddiss.jpg

This part of the code deals with getting the ignition timing from one of the ignition timing maps stored elsewhere within the code.

[Cossie1]

Do you speak english ?? lol

[AndyF]

Don't worry Russ, in reality it's a lot more complicated than I've made out above :D

I don't understand much of it above the basics at the moment. You need to be an uber geek to understand it all which is why I'm merely a super geek ;)

Andy

[Cossie1]

lol

btw this 10 character minimum reply thing is crap lolol

[AndyF]

Have removed the 10 character limit now Russ

[Cossie1]

Good stuff

[Aidy]

Andy did you add the address labels yourself? If so I think L9F0A should be L9F0B :)

A note to everyone else, alas the disassembled code won't come with comments :( and those funny letters are called mnemonics. It makes it easier to google, so if you want to know what LDA means then googling it will give you nothing, but google "lda mnemonic" and you'll get what you're looking for.

[Cossie1]

A note to everyone else, alas the disassembled code won't come with comments :( and those funny letters are called mnemonics. It makes it easier to google, so if you want to know what LDA means then googling it will give you nothing, but google "lda mnemonic" and you'll get what you're looking for.

Cheers for the info Aidy.

Disassembly is still well over my head though :(

[AndyF]

Aidy,
Definitely should be L9F0A,

9F04: 37 - psh B
9F05: 4D - tst A
9F06: 27 02 - beq
9F08: C6 FF - LDB FF
9F0A: F7 01 AA - STB

And there is a description of the mnemonics in the instruction set that I've posted on this thread (http://www.geekmapped.com/forums/showthread.php?p=20#post20)

And yep, you're correct about the comments. That's the part that is the real pain in the arse to try and work out and takes days/weeks/months of testing and head scratching

Andy

[Aidy]

Ah, ok, the beq is relative and not absolute, that makes sense :>

[Technoprisoners]

huh???

[Aidy]

An absolute address uses two bytes to store the actual memory address to jump to whereas a relative address is the number of bytes forward or backward from the current address and only uses one byte. I thought BEQ used absolute addresses so would take 3 bytes of memory (the op code + the low and high bytes of the absolute memory address), but it uses relative addresses so only uses two bytes of memory (the OP code + the relative number of bytes to offset). That's why it took one less bit of memory than I thought.

Well, I hope that cleared that up.

[AndyF]

Aidy, All the branch addresses for the early evo processors are relative. Why they don't use extended addressing I don't know. They seem to have the options for extended, relative etc. for most other commands... Bizarre

[Aidy]

Obviously I haven't coded for that chipset, but relative jumps are provided mainly to keep code smaller and faster. Obviously it limits the distance the code can jump, but many times you only need a small jump anyway (loops, or jumping to small subroutines in a small program). So if you only need to jump the 127 bytes or whatever you can take advantage of a relative jump, and only use absolute jumps if you really need them.

If it was done that way more in the early evos maybe it's just cos back then there wasn't the processing and space there is now and space and performance was more important back then. If you think about it...surely a 2 byte instruction is a 33% faster than a 3 byte one?

[bloke101]

That sounded like and episode of stargate.

And its the kind of interesting i wish i understood deeper.

[AndyF]

It's not as bad as it seems when you get into it, it just takes a bit of getting used to that's all.

You have to try and convert it all into simple terms that you 'sort-of' understand.

What I might do tonight if I get time is put up a few sample bits of code and explain them in a bit more detail to give you an insight into it all.

Andy

[soldave]

A lot of good info here Andy. Will try and sink my teeth into it all over the weekend.

[bloke101]

It's not as bad as it seems when you get into it, it just takes a bit of getting used to that's all.

You have to try and convert it all into simple terms that you 'sort-of' understand.

What I might do tonight if I get time is put up a few sample bits of code and explain them in a bit more detail to give you an insight into it all.

Andy

Engines i get.

I get everything up untill the wire/firbe hits the ecu case. I get why the signal is sent how it is produced and what it if for.

I understand the very basic ideals of how an ecu works.

But my knowlege ends at the ecu case.

Looking forward to learning.

[Spanpody]

What I might do tonight if I get time is put up a few sample bits of code and explain them in a bit more detail to give you an insight into it all.That would be handy.

Many moons ago I used to write assembler code for the 8051 series of microcontrollers so its not all alien to me :thumbup1:

[AndyF]

Right then, just to start us off, I'll talk you through a piece of code that I've written for the early evos to give launch control anti-lag

Part of the actual code in hex looks like the following

96 CA 81 1E 23 0B FE 01 69 8C 03 41 24 03 C6 BC 01 39

So what we do now is use our code seeking disassembler to give us a bit more detail as to what is going on...

The output from the disassembler reads as follows:

________ldaa___*VEHSPD
________cmpa__#0x1E
________bls____DC36
________ldx____TCAS
________cpx____#0x0341
________bcc____DC36
________ldab___#0xBC
________nop
DC36:___rts

So what does this mean in 'normal' terms then...

Well firstly, I think I need to explain briefly about how the ECU stores and uses values.

The early evo ECU has 5 memory locations that are used to store values that are being worked upon by the code.

These locations are given the desingations A, B, D, X and Y.

Now A and B are fairly straightforward and are called accumulators.

They can only hold 1 byte of data each and various mathematical functions can be carried out upon them.

D is a 2 byte accumulator that is made up of a and b... so if you were storing the value of 0a in accumulator A and the value of 03 in accumulator B then the value stored in D would be 0a03. The D accumulator can be used to store values that are greater than those obviously only storeable in either A or B and so gives a greater range of values that are possible to be calcualted etc.

Now X and Y are a little bit different and are called index registers.

These are normally used in a function called index addressing which is way beyond the level we are looking at at the moment so I'll just ignore it :smile:

So now we know a little bit about how things are stored, we'll take each instruction in turn and go into it in a bit more detail...

96 CA ------> ldaa *VEHSPD
For this instruction we can use the early evo instruction set to find out that the 96 part refers to ldaa or 'Load Accumulator A' with a 'direct' value. The fact that the value is 'direct' means that it is a memory location. Therefore we are loading the value at memory location CA into accumulator A.

If the first value had been an 86, this is 'Load Accumulator A' with an 'immediate' value. This would have meant that we would have loaded the hexadecimal value of CA into accumulator A and not the memory location.

Now you will notice in the above disassembly that it actually states *VEHSPD. This is because in my course of disassembling the ECU I actually know that the value stored at memory location CA is the vehicle speed and so whenever my code seeking disassembler sees memory location CA, it automatically recognises it as vehicle speed.

So anyway... after all that talk, all we have actually done is load the existing vehicle speed into accumulator A. Next.....

81 1E ------> cmpa #0x1E
Now again using the instruction set, we can see that 81 is an instruction to compare accumulator A to an immediate value. Now if you recall from the paragraph above this means that it's the actual hexadecimal value that we are comparing it to and not a memory location.

So we are comparing the vehicle speed to the hexadecimal value of 1E but what does this mean in terms of mph etc...

I also know from logging the values seen in memory location CA and comparing them to the speedo readings that the conversion formula is 360/X = speed in mph

So a value of 1E in decimal terms = 30 so we are comparing our current speed to a speed of 360 / 30 = 12 mph

23 0B ------> bls DC36
I'll start to speed up the descriptions now etc as you should hopefully have an idea as to what I'm going on about...

bls = branch if lower or same and is followed by a 'relative' value

So we are comparing the value in the speed sensor memory location to hexadecimal value 1E and if the value is lower than 1E then we will jump the next 0B bytes of code.

The thing to remember here is that although this seems back to front it isn't. If you look at the conversion formula for the speed sensor you will see that it is 360/X therefore as our speed gets higher, the value stored actually gets lower. As an example in decimal terms, say we were doing 30 mph then the value stored would be 360/30 = 12 and if we were doing 60 mph then the value stored would be 360/60 = 6.

So in reality, although this is a branch if lower or the same instruction, what we are saying is that if we are above 12mph then jump the next 0B set of instructions and resume from address DC36

FE 01 69 8C 03 41 24 03 ------> ldx TCAS, cpx #0x0341, bcc DC36
This instruction loads index register X with memory address 0169 which happens to correspond to the TCAS value (which is the crank sensor and relates to the engine rpm). This part of the code therefore compares the rpm to a given value of $0341 which happens to equate to 4,500rpm and if the actual rpm is less than this then it just jumps to the normal code i.e. don't activate the ALS timing below 4,500rpm.

C6 BC ------> ldab #0xBC
Eventually we reach the point that we actually load the timing we want to run on launch control (BC = - 5 degrees) into accumulator B where it sits ready to be processed in the next part of the main code...

01 ------> nop
No operation... this is just left over from when I was initially trialling various bits of code and from a perfection point of view should be removed as it is just a waste of space and processing time

39 ------> rts
Return from subroutine to the main part of the code that we came here from




And that is about all on that for now!!!! What you need to realise though is that above is the process of disassembly... In order to write the code initially I had to go through the process in reverse i.e. work out what I needed to do to each value etc. and then look up the appropriate codes in the instruction set and write them all down.

Hope it's a little bit clearer now

Andy

[scandinavian flick]

Jon boy is leaving the building... Jeesus

[paul]

wow wow and wow mad stuff http://smilies.sofrayt.com/%5E/h0/spineyes.gif

[jabberwocky]

I usually just count sheep to get to sleep, looks like I have found another way :unsure: :blink: :omg:

[MattS00]

Wow, I love this site. I haven't stopped reading since I found it. I really appreciate you taking the time to put this together. It makes things clearer than they were before. The subroutine that you wrote is actually pretty simple, but my head is still spinning trying to read it. BTW, how is this code added to the rom so that the rom is still the correct size? Also, what in the main code references the b accumulator for the value of $BC (-5 degrees timing)? I also don't understand the 0B part. Also, shouldn't there be address for each line?

[AndyF]

Wow, I love this site. I haven't stopped reading since I found it. I really appreciate you taking the time to put this together. It makes things clearer than they were before. The subroutine that you wrote is actually pretty simple, but my head is still spinning trying to read it. BTW, how is this code added to the rom so that the rom is still the correct size? Also, what in the main code references the b accumulator for the value of $BC (-5 degrees timing)? I also don't understand the 0B part. Also, shouldn't there be address for each line?Hi Matt,
The code is added into a section of the ROM that is currently empty so the ROM file still remains the same size as the original.

Yes, there should be an address for each line but I didn't bother adding them :)

The 0B part is the number of bytes of code that the instruction will skip. In this case 0b = 10 in decimal therefore the code will jump the next 10 bytes worth of instruction. It is a quicker way of jumping to a section of code rather than saying jump to address XXXX as it uses up 1 byte less of code to perform the same function.

Andy

[MattS00]

Hi Matt,
The code is added into a section of the ROM that is currently empty so the ROM file still remains the same size as the original.

Yes, there should be an address for each line but I didn't bother adding them :)

The 0B part is the number of bytes of code that the instruction will skip. In this case 0b = 10 in decimal therefore the code will jump the next 10 bytes worth of instruction. It is a quicker way of jumping to a section of code rather than saying jump to address XXXX as it uses up 1 byte less of code to perform the same function.

Andy

Would using the 0B be considered using the address offset instead of absolute address?

[AndyF]

Yes that's correct Matt,
It's just an offset number of bytes from the current code position rather than an absolute address value.

Andy

[systemshock]

How do you know which code set to use to disassemble the code? I know its going to be specific to the processor type, but is there any way to figure it out?

Rich

[DanielN]

Ok guys.....I will try to add some basic IDAPro tutorial and you will understand more what Andy is doing.I do not consider that I know the program because I think it will take you months to understand how this is working.

The best way to start learning this is to start with somebody's assembly file because most of the ROM`s are similar as a body code.

I will try to explain step by step how to start to use the program.

I will assume that you have the program installed on your computer.I use the version 5.2.0 64-bit.

1.Open the program

2.Use "open" from file tab and open your hex file

3.One window will appear (load a new file)

http://img199.imageshack.us/img199/3292/42103057.jpg

4.Change the procesor type from "Intel 80x86 processors: metapc" to "Hitachi: SH4B" and press ok

http://img199.imageshack.us/img199/2631/93291081.jpg

http://img199.imageshack.us/img199/6915/59951452.jpg

5.A new window will appear called "Disassembly memory organization.Into the window you will have "Create RAM section. Change the RAM start address to 0xFFFF0000 and RAM size to 0xFFFF and press OK.

http://img199.imageshack.us/img199/8969/18956918.jpg

http://img12.imageshack.us/img12/3123/79787331.jpg

***At this moment another window will appear (chose the device name) thank press OK.

http://img12.imageshack.us/img12/9997/34362327.jpg

The hex will be shown on your idapro window.

http://img268.imageshack.us/img268/7389/64692899.jpg

6.Now you would need to go at the start so use keyboard "G" for jump to address. Press "G" insert 0000 and press OK.

http://img268.imageshack.us/img268/3291/26528475.jpg

***Now you are at the beginning of the code***

7.Press keyboard "D" 3 times and that reference will transform into another number

http://img268.imageshack.us/img268/8015/23316765.jpg

8.Double mouse click on that new number and you will be moved to that location.

http://img268.imageshack.us/img268/8015/23316765.jpg

9.Now you need to press keyboard "C" and wait. This will convert the code from binary into assembly.It will change to something like this.

http://img268.imageshack.us/img268/6260/77677600.jpg

***Congratulations ***

From here you can search for ROM subroutines.

Use Keyboard "G" to jump to the location into the code.

For example if I want to find my MUT table I open my xml file and from there I see the address with is 37944.I press "G" and jump to 37944 location than on the right I will have the subroutines for that table.

http://img268.imageshack.us/img268/1240/85246786.jpg

My MUT 00 is 6A09.You will see it into the code also as FFFF6A09.

http://img268.imageshack.us/img268/4791/12543161.jpg

http://img12.imageshack.us/img12/5113/34500737.jpg

Just rename your 37944 with MUT TABLE for example in order to read it after.

http://img12.imageshack.us/img12/6477/97893091.jpg

[bassed]

This is all fantastic stuff!!

Take me back to my days at Uni Coding in Motorola assembly language...

Great stuff !!

[AndyF]

This is all fantastic stuff!!

Take me back to my days at Uni Coding in Motorola assembly language...

Great stuff !!
Ooooh, we have a professional in our midst then :D :D

Will come in useful ;)

Andy

[GrayW]

Ooooh, we have a professional in our midst then :D :D


The site could do with one:tt2:

[bassed]

Ooooh, we have a professional in our midst then :D :D

Will come in useful ;)

Andy

Ha ha, no that was a long time ago and I've fogotten most of it lol

It's amazing tho how reading this brings back the memory! Esp of how good I wasn't ha ha ha

[DanielN]

Something for basic understanding of the SH2 assembly language....
It can help you remember......

http://documentation.renesas.com/eng/products/mpumcu/rej09b0171_superh.pdf

Cheers,

[redeye]

This is all fantastic stuff!!

Take me back to my days at Uni Coding in Motorola assembly language...

Great stuff !!

hey can you help me find the injector constant in a m2.9 obd1 ecu .....8051 c517 processor for my vr6 turbo :tt2:

[ohde]

A theoretical question...
If the code is disassembled is it possible to change the size of the tables the code uses?
Since i have a n/a car that i am converting to a turbocharged i think that the
pressure -1- 1,5bar divided on 9 rows will make a not so nice map.

I guess this will be some coding and maybe moving the maps to unused parts of the code..

But is it possible to do?

[AndyF]

Yes it's possible. You need to find the section of code that deals with the scaling of the axes on the maps. With that disassembled you can then modify that section to increase the number of rows and columns that are found within the map itself.

As a basic example using the early evo code, whenever a lookup routine is called to get a value from a map there is a 16 bit constant that describes the number of columns in the map and any offset. All you do is change this constant from say 9 columns to 15 columns and the map size then changes.

The other thing you have to be wary of though is that if it is like the early evo code then there is a seperate routine for calculating the index value into the table and this will also need changing to give you the correct scaling for your application.

Again, using the early evo code as an example, there is a routine within the code that converts the engine 'load' variable into a column number for use in the fuelling and ignition timing tables. This part of the code needs to be changed so that for example, 1.5 bar of boost then uses column 15 rather than column 9.

Hopefully that will make some sense.

Andy

[And]

i'd like to start getting into the disasembly part of the ecu etc and I've downloaded the free version of the IDA pro (V5) it doesn't come with the h processor in the list does any one know if its possible to add to this version or do I have to get a full version?

I've add the idc files to the directories etc but it still doesn't appear in the list, I also get the following error when loading the h8_reg_name.idc
"Runtime error at main+0x00000016. Attempt to call a database related function without a database" i'm guessing its to do with the processor def??

Any help would be appreciated
Andy

[Lee5]

I've been looking at this over the last few months but I just cant get my head round it at the mo.

I have good idea and have mod'd some roms and found the addresses but I just caant work it out 100% yet.

Lee

[Lee5]

Ok chaps I have a download link for IDA Pro 6.1 full version if anyone wants its.

I will only PM it tho to people who I know and not random people.

Hope you all understand.

Cheers
Lee

[cdrinkh2o]

i'd like to start getting into the disasembly part of the ecu etc and I've downloaded the free version of the IDA pro (V5) it doesn't come with the h processor in the list does any one know if its possible to add to this version or do I have to get a full version?

I've add the idc files to the directories etc but it still doesn't appear in the list, I also get the following error when loading the h8_reg_name.idc
"Runtime error at main+0x00000016. Attempt to call a database related function without a database" i'm guessing its to do with the processor def??

Any help would be appreciated
Andy

And - the free version doesn't have the Renesas SH4B processor options you will need to disassem the Evo ROMs. You will need to install IDA Pro 5.2.0 Advanced with the SDK, or 6.1 Pro. Both these have the proc options you will need.

[AndyCT9W]

Right, so.....well....

What I managed to get from this is; once disassembled into a raw text form, you can use certain portions of the text to determine what that portion of the ROM controls and then enter the address with the right parameters into your ROM's XML and voila! (Correct?)

Of course I know it's not straightforward textbook stuff and a lot of work and trial and error is involved.

So if that is a semi accurate summarization of ECU disassembly, is someone able to recommend me a good free hex editor and a good free disassembler program that I can download?

If the words good and free aren't able to go together in this context, is someone able to disassemble my ROM for me and send back the raw text file?

Vehicle is an 05 CT9W Evo 9 wagon. Those lovely folk at Mitsubishi decided to give the wagon a different ROM to any other evo 9 and since the wagon is not very common there aren't any (that I can find) well defined definition files to use with ECUFlash. I have an XML that has a some tables but I'd like to start adding to it and making it as well defined as I can. So kind of Mitsubishi.

Any feedback or assistance is hugely appreciated.

[bspain]

I've got a few questions regarding disassembly if anyone can help. More specifically for the early Evo's but any help is appreciated.

1. How do you know which memory location is storing the readings of which sensor? Like when IDA pro shows it as loading accumulator A with memory location 90, how do I find out what sensor or parameter is being stored there? Is there a table or something anyone has?

2. It appears when using adsolute values for branching or Jumping to subroutines the factory code uses an address slightly different to what IDA pro is using. i.e. Jumping to subroutine at '5C20' is being carried out using the high and low bytes of 'DC20'. Why is the code using 'D' instead of '5'? and how do I figure out what address is what?

[AndyF]

1. I have a list that I have put together that I'll post up when I get a spare 5 minutes showing what most of the memory values are.

2. The code in the chip effectively starts at memory address 8000 so you need to subtract 8000 from any of the given branch addresses e.g. if you have a section of code that jumps to EF20 then subtract 8000 from EF20 in hex to give you 6F20 which will be where the code jumps to in the disassembly

Hope that helps

Andy

[bspain]

Excellent! Thanks Andy. I have set the start point to 8000 and the absolute addresses now are making sense, I should have figured that was the case :blushing:

I'm getting there with understanding the code in the bins, just missing a few bits and pieces of info, so that would be great if you could post up your list :D

Its a real shame IDA pro doesnt cater for the Mitsubishi specific instructions, it would really make disassembling alot easier.

[AndyF]

I have a dissassembled code routine written in notepad if you want me to send it to you. I've filled it out with about 80% of comments as to what the code does etc.

Drop me a PM with your email address and I'll send over what I've got.

I didn't bother using IDA Pro for the early evo stuff I got hold of a free MH6711 code seeking disassembly program and it was far better.

Andy

[AndyF]

Actually,
Forget the PM, I'll post it up here either tonight or sometime later this week.

Andy

[Benny]

That would be great Andy, i'm looking into some coding stuff on the H8 ECU's.

[AndyF]

Here you go then ladies and gents.... 3 years of my life in a single 511kB document :lol:

Andy

[bspain]

Awesome! That is truely a sight to behold. You can see the 3 years of blood, sweat and tears in there :lol:

You are a legend Andy :thumbup1:

[AndyF]

Any questions on it then please just ask.

You will also probably notice various bits where I've run into dead ends or where I've got no idea on what is being monitored etc. so any help you can add will be good.

There are also probably various mistakes within it due to me deciding things are one thing and then changing my mind etc. :D

Andy

[Benny]

Are your disassembly notes relating to the 1-3 ECU's Andy?

[bspain]

Are your disassembly notes relating to the 1-3 ECU's Andy?

Yeah Andy's disassembly is of the evo 1-3 ecu.

[Aurélien]

Damn this is LOT of work ... Thank you very much !