Memory dump of ECU

[RoughSilver92]

So I have began an attempt to analyze the assembly code of the US ECU on Phil's page. This is all pretty new to me, I must admit, but I am fairly persistent and can usually figure things out pretty well with a little guidance. I need some guidance!

So far I have gone through and labeled all of the addresses that have been documented by Phil, Tom, Mike, and others. I am at the point that I am marking all commands accessing the memory between 8000 and 8fff that have not yet been documented and I just want to make sure my understanding is correct:

When an address with a final character other than 0 is accessed, such as "0x86a1" does the 1 indicates the first hex number in the 86a0 line?

This is the assumption I have been operating under, as it is the only logical explanation to me, but a confirmation that this is correct would make me feel better. I just finished a semester of Intro to C++, but as you all know this assembly language is a whole other thing!

[b3lha]

Originally Posted by RoughSilver92

So I have began an attempt to analyze the assembly code of the US ECU on Phil's page. This is all pretty new to me, I must admit, but I am fairly persistent and can usually figure things out pretty well with a little guidance. I need some guidance!

So far I have gone through and labeled all of the addresses that have been documented by Phil, Tom, Mike, and others. I am at the point that I am marking all commands accessing the memory between 8000 and 8fff that have not yet been documented and I just want to make sure my understanding is correct:

When an address with a final character other than 0 is accessed, such as "0x86a1" does the 1 indicates the first hex number in the 86a0 line?

This is the assumption I have been operating under, as it is the only logical explanation to me, but a confirmation that this is correct would make me feel better. I just finished a semester of Intro to C++, but as you all know this assembly language is a whole other thing!

Yes. That is exactly right. My hex dump program just writes out 16 bytes on a line for convenience. So 86a0 is the first byte on the line, 86a1 is the second.....86af is the last.

There's a few threads on SubieSmart that might help you get started.

http://www.subiesmart.com/forum/inde...opic,26.0.html
http://www.subiesmart.com/forum/inde...opic,43.0.html
http://www.subiesmart.com/forum/inde...opic,44.0.html

Good luck.

[RoughSilver92]

Great information and links. I read on the one of the posts that bits are read from right to left, and have noticed a discrepancy between the bitmap definitions posted by LAN and the diagnostics codes listed on your site. I believe that the bits are labeled backwards on the definitions spreadsheet, for example the crank angle bit for 1026 on the spreadsheet is labeled as hex 01 when it should in fact be hex 80. Is this correct?

[b3lha]

Originally Posted by RoughSilver92

Great information and links. I read on the one of the posts that bits are read from right to left, and have noticed a discrepancy between the bitmap definitions posted by LAN and the diagnostics codes listed on your site. I believe that the bits are labeled backwards on the definitions spreadsheet, for example the crank angle bit for 1026 on the spreadsheet is labeled as hex 01 when it should in fact be hex 80. Is this correct?

You're right. There's a discrepancy. One of us has got it backwards and I think it's LAN:

If you look for the "seb" (set bit) insructions, you can see that bits 0x01, 0x02, 0x04, 0x08, 0x80 and 0x20 of address 0x1028 are all set in the same subroutine. These correspond to the six injectors error codes 14,15,16,17,18 and 19. It makes sense that the six injectors would be tested in the same subroutine. So I think I've got it right on my website.

(The "test injectors" subroutine is address 9F5B in rom 722527)

As you said, the crank angle sensor error is bit 7 (0x80) of address 0x1026.

[longassname]

Thanks, I'll fix it right now.

[longassname]

Ok, should be right now. I had copied and pasted the switches from one of my spreadsheets and the error codes from Phil's website and my sheet is layed out in hex order and his in binary.

[longassname]

I need to add the definitions for a few tables that are scaled by load but asside from that I think the definitions file is pretty complete. The tables I just mentioned are the only things I ever edit that I don't already have in the definitions file.

[longassname]

Phil,

Does your dissassembler comment defined locations?

[b3lha]

Originally Posted by longassname

Phil,

Does your dissassembler comment defined locations?

Yeah, I think the one Calum sent me does that.

I normally disassemble to a text file, without comments, and then I run a sed script that does a regex search and replace in the text file:

eg. search for lines containing 106F and append " ; RPM " at the end of the line. Something like this:

s/(^.*106f.*$)/\1; RPM/g

[RoughSilver92]

That sounds a lot better than going through the document with the find feature for every address and typing/pasting the description like I have been doing. It only took about three days of working on it on and off, but I have everything that has been documented labeled! Now I can begin attempting to unravel the code so I can see what exactly is happening. I also want to try to define every bit of 8000-8fff. This is everything we are able to modify (i think) so it would be nice to know what every piece does does and what it affects.

[b3lha]

Originally Posted by RoughSilver92

That sounds a lot better than going through the document with the find feature for every address and typing/pasting the description like I have been doing. It only took about three days of working on it on and off, but I have everything that has been documented labeled! Now I can begin attempting to unravel the code so I can see what exactly is happening. I also want to try to define every bit of 8000-8fff. This is everything we are able to modify (i think) so it would be nice to know what every piece does does and what it affects.

Which ROM are you looking at? 722525? I'll post whatever info I have about it in case it helps you.

Most likely people will modify the maps and constants between 8000 and 8fff. But it is also possible to carefully modify the program code too. Paul in Uganda has added a launch control feature to his 95 impreza by doing just that. He just changed the program to use a lower rev limit when the vehicle speed is below a certain threshold.

[RoughSilver92]

Yes-722525.
So when you burn the chip you burn the code in as well or do you have to modify the program some other way? I was under the impression only 8000-8fff was burnt.

[b3lha]

Originally Posted by RoughSilver92

Yes-722525.
So when you burn the chip you burn the code in as well or do you have to modify the program some other way? I was under the impression only 8000-8fff was burnt.

The chip replaces the entire eprom from 8000 to FFFF.

[b3lha]

Here's a zip of my 722525 directory. I was working mainly on the JDM rom 742512, so there's not much to see. It's been so long since I worked on it that I can't really remember what state it's in, but maybe you will find something helpful in it.

I split the disassembly up into different files for each subroutine and started naming the subroutines according to what I thought they did. You can easily find the different maps by looking for calls to the graph lookup subroutines and seeing what parameters are passed in.

Don't assume any of it is accurate, because it's undoubtedly full of mistakes.

[RoughSilver92]

I don't see the file. I look forward to it.