Memory dump of ECU

[b3lha]

Originally Posted by Nomake Wan

IT WORKS! You're a genious, Phil!! Now to go about making an if,then bit to detect whether the user of your program is using "real" serial or usb and then use the proper version of the baud code accordingly.

I'll go plug it in now! Good-bye, three hours of my life!

Yep, it's dumping smoothly. Just a waiting game at this point. Here's hoping my battery holds up!

Cool!

No need for an if,then the new code should work on traditional serial ports too. I must remember to update the version on my website.

[b3lha]

Originally Posted by Nomake Wan

Sorry it took so long, the dump was finished like two hours ago, but I spent the last two hours trying to figure out how to get it off of the laptop. Had a little problem with all the drives I own being NTFS and the only FAT partition being the boot drive. But then I remembered I had an SD card reader, so thanks to that I have the dump! Here you go!!!

EDIT: Oh yeah, do you by chance know what command forces the ECU to forget all of its saved values? I know the select monitor can reset the ECU completely but I see no reason why we can't do it with our laptops.

Thanks Nomake, you're a legend. I'll have a look at it and see how it compares to my JDM ECU.

There isn't a command to reset the values. The only commands are 78 to read, AA to write and 12 to STFU. Plus the ASCII mode stuff, of course. I guess the select monitor overwrites the learned values in RAM with default values.

I'll tell you one way we could maybe figure it out. Dump the RAM from 1000 to 14FF (with the engine off). Then disconnect the battery to reset the ECU. Dump the RAM again and compare the two. The differences would presumably be the learned values.

That's a cool idea. You're a continual source of inspiration. I'll give it a go, or you can, or both. Whatever.

Phil.

[Nomake Wan]

You know, the more I go through this with you, the more I wish I lived in the UK and could just stop by so our brainstorming wouldn't be limited to the brief periods of network access that coincide.

I'll actually go do that right now. The car's back outside (couldn't leave it in the garage forever) and stuff, but may as well see how your idea works! Not like I have anywhere I need to go at 12:45 in the morning anyway.

Oh yeah, you wanted a TCU dump as well, right? I went through your code and I guess the way you did this was you re-wrote the ssm_query in ssm.c to point at 45 instead of 78, right? If that's all I can recompile the thing myself and get to it after the ECU check. If there's more, or if you have a file already... please, do tell!

And it's rather funny... this morning, when I woke up and rolled off the couch, I thought to myself... "Why wouldn't the serial work at the baud command... is it the way the divisor is set?" And then saw your post and just smiled.

P.S. I found out that Linux doesn't like it when I try to recompile a file from the future!

EDIT: Just got the first batch of code. Now to wait while the car forgets itself so I can get the other.

[Nomake Wan]

Finished. They must be different because cmp reports that even the very first character of the first line has changed. But I'll let you peek at that. A zip with both dumps is attached. "Pre" is before unplugging the battery and "post" is plugging the battery back in after 1 hour and 15 minutes.

Interesting note, though... while the clock was reset to 1:02 and the radio is reset and apparently the ECU is reset... the security computer is not reset. It still responds properly to my keyfob. I couldn't help but be surprised at that.

Anyway, yeah. Now to go look up the proper procedure to do after plugging the battery back in...

[b3lha]

Originally Posted by Nomake Wan

You know, the more I go through this with you, the more I wish I lived in the UK and could just stop by so our brainstorming wouldn't be limited to the brief periods of network access that coincide.

Originally Posted by Nomake Wan

I'll actually go do that right now. The car's back outside (couldn't leave it in the garage forever) and stuff, but may as well see how your idea works! Not like I have anywhere I need to go at 12:45 in the morning anyway.

I really appreciate your efforts. This is a joint project, in fact it's a group project between everyone who is contributing to this thread.

Originally Posted by Nomake Wan

Oh yeah, you wanted a TCU dump as well, right? I went through your code and I guess the way you did this was you re-wrote the ssm_query in ssm.c to point at 45 instead of 78, right? If that's all I can recompile the thing myself and get to it after the ECU check. If there's more, or if you have a file already... please, do tell!

You are absolutely right, but ... there is one extra change you have to make.
You remember that to tell the ECU to STFU you can just send a single 12 but the for TCU it has to be 12 00 00 00. Well I was lazy when I wrote the code and only send a single 12 even though the 4-byte command would work for both devices.

So in send_reset() you have to do this:

1) increase the size of the cmd array from 1 byte to 4 bytes: unsigned char cmd[4];
2) populate the array with the extra zeroes:
cmd[1]=0x00;
cmd[2]=0x00;
cmd[3]=0x00;
3) Write 4 bytes instead of 1
rc=write(fd,cmd,4);
4) Check the return code shows 4 bytes written instead of 1
if (rc != 4) return -1;

The TCU ROM is smaller, you only need to read addresses C000-FFFF, so it takes half the time.

Originally Posted by Nomake Wan

And it's rather funny... this morning, when I woke up and rolled off the couch, I thought to myself... "Why wouldn't the serial work at the baud command... is it the way the divisor is set?" And then saw your post and just smiled.

P.S. I found out that Linux doesn't like it when I try to recompile a file from the future!

EDIT: Just got the first batch of code. Now to wait while the car forgets itself so I can get the other.

[Nomake Wan]

Originally Posted by b3lha

You remember that to tell the ECU to STFU you can just send a single 12 but the for TCU it has to be 12 00 00 00. Well I was lazy when I wrote the code and only send a single 12 even though the 4-byte command would work for both devices.

So in send_reset() you have to do this:

1) increase the size of the cmd array from 1 byte to 4 bytes: unsigned char cmd[4];
2) populate the array with the extra zeroes:
cmd[1]=0x00;
cmd[2]=0x00;
cmd[3]=0x00;
3) Write 4 bytes instead of 1
rc=write(fd,cmd,4);
4) Check the return code shows 4 bytes written instead of 1
if (rc != 4) return -1;

The TCU ROM is smaller, you only need to read addresses C000-FFFF, so it takes half the time.

Oh whoops, I actually did notice that in your code. But considering how frayed my brain's ends are I doubt I would've remembered to change it. I'll make the appropriate changes and dump the TCU now.

[b3lha]

I haven't yet had much time to look at Nomake's ECU dump, but I can already tell you that the fuel and timing tables are different.

This validates the long-standing rumour that the USDM cars are tuned differently to the rest of the world. Whether they are tuned up or down is a matter for debate. I have heard anecdotally that LAN's stage 1 didn't seem to make much difference to the performance on a non-USDM SVX so perhaps the JDM tuning is closer to LAN's stage 1?

It seems to me that a JDM ECU (if compatible), or a chip containing the JDM tables, might be able to improve the performance of a USDM car.

I'll do some comparison graphs later today so the engine gurus can pass comment.

[Nomake Wan]

The TCU is dumping as we speak. I went ahead and rewrote a few other parts of code so that I didn't have to type so much. Yay for lazy command lines. Dang it Phil, now look what you've done! I'm gonna end up running Linux on my laptop and get back into programming again...

As for the fuel map comment... since in the US we had a TSB ROM, was this particular TSB ever released for other markets? If we know this, then it's just a matter of getting our hands on the JDM ROM and placing it into a USDM socket. Though considering the likely rarity of such a ROM, it would probably be quicker (and cheaper!) to get LAN's Stage 1.

[b3lha]

Originally Posted by Nomake Wan

The TCU is dumping as we speak. I went ahead and rewrote a few other parts of code so that I didn't have to type so much. Yay for lazy command lines. Dang it Phil, now look what you've done! I'm gonna end up running Linux on my laptop and get back into programming again...

Originally Posted by Nomake Wan

As for the fuel map comment... since in the US we had a TSB ROM, was this particular TSB ever released for other markets? If we know this, then it's just a matter of getting our hands on the JDM ROM and placing it into a USDM socket. Though considering the likely rarity of such a ROM, it would probably be quicker (and cheaper!) to get LAN's Stage 1.

My JDM cars don't have a socket on the board, just two lines of solder blobs where a socket could be fitted. I would guess therefore that the TSB was not available in Japan. I don't think the average dealership mechanic would want to mess with soldering chips onto the ECU motherboard of a customer's car.

[Nomake Wan]

Originally Posted by b3lha

My JDM cars don't have a socket on the board, just two lines of solder blobs where a socket could be fitted. I would guess therefore that the TSB was not available in Japan. I don't think the average dealership mechanic would want to mess with soldering chips onto the ECU motherboard of a customer's car.

YIKES!! Well... that answers that, then... So basically, the Japanese got it right from day 1?

[Nomake Wan]

TCU dump complete! Have fun with it, Phil.

[b3lha]

Originally Posted by Nomake Wan

TCU dump complete! Have fun with it, Phil.

Thanks Nomake.

Haven't had a chance to go much investigating yet, but I have disassembled the code and put in on my website in the roms page. http://www.alcyone.org.uk/ssm/roms

I notice that the JDM TCU has an extra error code, 26, that the USDM TCU does not have. They both have a number of undocumented error codes too.

The complete list is:

JDM: 11,12,13,14,15,21,22,23,24,25,26,31,32,33,34,35,41 ,42,43,44,45,51,52,53,54,55
USDM: 11,12,13,14,15,21,22,23,24,25,31,32,33,34,35,41,42 ,43,44,45,51,52,53,54,55

AFAIK nobody has ever reported getting an undocumented error code from the blinky power light, so they must be for things that don't usually break.

[b3lha]

Here is an excel spreadsheet, with some pretty graphs. It shows the fuel, timing and knock correction maps of Nomake's USDM SVX compared with my JDM cars.

Hopefully this will be interesting reading for guys that understand tuning stuff.

I haven't yet figured out the units, so the numbers are rather arbitrary. Note also that the X and Y axes are reversed on the knock graphs compared with the others. (It looked better that way).

[b3lha]

Originally Posted by Nomake Wan

Finished. They must be different because cmp reports that even the very first character of the first line has changed. But I'll let you peek at that. A zip with both dumps is attached. "Pre" is before unplugging the battery and "post" is plugging the battery back in after 1 hour and 15 minutes.

Interesting note, though... while the clock was reset to 1:02 and the radio is reset and apparently the ECU is reset... the security computer is not reset. It still responds properly to my keyfob. I couldn't help but be surprised at that.

Anyway, yeah. Now to go look up the proper procedure to do after plugging the battery back in...

I've compared them, there are 205 differences. I can't imagine that the select monitor overwrites all of them. I wonder how it does it.

I think it must "reboot" the ECU somehow. When the ECU boots up it starts executing the software starting from it's "reset vector". This is at address 93C1. The code here initialises all the variables. Looking at the interrupt vector table, there are many other interrupts pointing at 93C1.

A/D Interrupt control 93C1
UART0 tx interrupt 93C1
UART0 rx interrupt 93C1
UART1 tx interrupt 93C1
UART1 rx interrupt 93C1
PWM1 interrupt 93C1
Timer B4 interrupt 93C1
Timer C2 overflow 93C1
Timer C2 strobe interrupt 93C1
External INT interrupt 93C1
Debug (unused?) 93C1
BRK instruction 93C1
Divide by zero 93C1
Reset vector 93C1
If we could trick the ECU into generating one of these interrupts then it would reboot and that would reinitalise all of the variables.

[Calum]

So I've picked up a couple of Subie ECUs recently. Not an SVX (don't usually see those in junkyards), but one was a JDM GC8 EJ20. I think this ecu is pretty close to a SVX ecu. I mapped out the memory interface, and its pretty straightforward, but interesting. The main cpu (7791) has quite a bit of interaction with the big house marked IC next to it. Among other things, the big dude is clocking the cpu, and interfaces to the cpu databus. I'm guessing that its memory mapped to the cpu. It also assists in the external memory reads. I didn't map out what goes to specific pins on the big dude because of lack of documentation on him. If I had to guess, he's probably a CPLD (or maybe custom ASIC), and is handling specific functions with tight time constraints. Maybe decoding CAS pulses or making the actual pulses for injectors. If you mapped out what outputs get routed back to him you could probably figure it out. Neat little setup. Anywho...

Memory interface for the ECU:

http://www.calumsult.com/calumsu/dis...0interface.pdf

and just for reference I put the 27C1028 datasheet and Kaele's schematic for a 27C1028 substitute in the SVX dis folder:

http://www.calumsult.com/calumsu/disassembler/SVX/