1997 JDM Legacy GT-B Twin Turbo

[oily]

Hi all!

I've got a '97 JDM Legacy TT I'm trying to interface with via the SSM port (mostly for fault diagnosis and datalogging) - I'm a complete newbie to the ECU hacking game so please humour my potential ignorance..

I've managed to build myself an interface cable built using a pre-assembled FTDI board and the AutoLeads Legacy stereo wiring adapter plugged into the yellow connector under the dash, and I've managed to successfully read random memory locations using the select monitor protocol and all the responses look valid (ie. it's echoing the correct location in the response from the ECU).

However, I'm getting stuck on reading the ECU ROM ID using the "\0FHI" command - instead of the three-byte response (0x7xxxxx) that I'm expecting, I'm getting a repeated 12-byte response back from the ECU instead.  Is this something that you guys have seen before?

Any help would be much appreciated!

Olly

[seport]

have you tried using evoscan software?

[oily]

I've not tried Evoscan, no.  Looking at the website I guess there's no way of getting a trial version to see if it works?

[seport]

I found many useful information here http://www.alcyone.org.uk/ssm/troubleshooting.html

I've not tried Evoscan, no.  Looking at the website I guess there's no way of getting a trial version to see if it works? Sad

I would then try the Hex com tool software.

[oily]

I've tried some of the linux software on http://www.alcyone.org.uk and it had similar issues - reading memory locations OK, but getting odd results when trying to read the ECU ROM ID.

I'll try lifting the carpet and seeing what the ECU is...

[oily]

Here we go - juicy photos!
(higher res versions are on my flickr account http://www.flickr.com/photos/oily/sets/72157618919662192/.

The ECU.
The label reads:
4G
22611 AC562
A18-000 DR5
7516
UNISIA JECS CORPORATION
MADE IN JAPAN


A funky little connector taped up next to the ECU.  Any idea what this is for?


The insides:


The two big daddy chips on the board.  I'm guessing CPU and ROM?



How does that lot compare to the 'usual' JECS kit?

[b3lha]

Haven't seen that before. What are the 12 bytes you are getting?

Please download the entire memory from 0000 to FFFF using ecudump and post the file here.

[oily]

I'll post the reply string later when I get back home to the laptop..

Is there a way of dumping the ECU that doesn't require leaving it sat on the drive for an hour on ignition position II (or do I have to leave it on PII and disconnect various bits under the bonnet to avoid burning out coil packs?)

[oily]

Here's the output I'm getting:

a2 01 13 f7 75 85 f8 c0 00 00 00 de

The response is repeated ad infinitum after the query, and after many attempts over multiple sessions I'm seeing the exact same data every time, so I believe the data's not been influenced by any kind of comms errors.  It's just not what I'm expecting to see!

One observation that may be of note is that there's an extra connector amongst the bundle of wiring under the dash that contains all the diagnostic connectors.  There's the usual yellow "data link" multi-plug, the grey "check connector" multi-plug and the two pairs of black and green connectors for the manual diagnostics mode.  The extra plug is a black 6-pin affair that doesn't correspond to anything on the wiring diagrams I have, although it does include the orange/white wire that would be an OBD-II K-line on a later car...... I'm probably entirely wrong in my suspicions, but interesting nonetheless! 

Photos of the offending bit of kit:

[b3lha]

I have no idea what that plug is for.

I think that the ROM ID might be A2 01 13 and the rest of it might be some flags to do with what diagnostic parameters the ECU supports. Have a read of this document that describes the newer version SSM protocol used by later model cars.

http://code.google.com/p/ecuexplorer/downloads/detail?name=ssm.pdf&can=2&q=

I think the F7 in your reply string might match up with "Byte 9" in the document.

[b3lha]

Is there a way of dumping the ECU that doesn't require leaving it sat on the drive for an hour on ignition position II (or do I have to leave it on PII and disconnect various bits under the bonnet to avoid burning out coil packs?)

The ECU has to be powered in order to communicate, so you need to keep the key on position II. I've done it many times and never had anything burn out. But if you want to unplug things, that's OK too. At least it will stop somebody driving off with your car when your back is turned.

[oily]

I've found a manual for a USDM car of the same year, and the wiring diagram seems to list the plug as a 'Diagnosis Connector' - four of the six wires I can tally up to the wiring diagram as being connected to the SRS and ABS/TCS subsystems.  The other two don't fit the diagram, but then I guess JDM/USDM differences are to be expected.  When I find the time I'll try to run an ecudump session and post the results up here.

The newer SSM protocol looks like an interesting avenue to investigate..

Thanks for the input so far!

[oily]

Thread resurrection time.... and some progress!

I've had the check engine light flash up a couple of times recently, and reading the error codes manually gives me a MAF error, so I've been trying again to get connected up to the ECU to see if I can deduce what dodgy readings the MAF is feeding to the ECU.

This time around I noticed this thread: http://www.subiesmart.com/forum/index.php?topic=51.0 which mentioned a 2.5 NA Legacy with the same microprocessor in the ECU.

I used the VWRX Select Monitor software, which identified my ROM ID as A20113 (the first three bytes of the string I was getting back in reply to the ROM ID command when I was trying before).  The select monitor has a few configurations in its .ini file for other vehicles of around the same age with ROM IDs starting with A, so I copied the memory locations for one of those into a new definition with my ROM ID and fired up VWRX.  The continuous scan mode wouldn't read all the values correctly -- often just returning all zeros.  However, if I only read a single value at a time, it seems to work perfectly.  At least the obvious values like speed, engine speed, battery voltage, ignition advance and throttle position seemed to work OK.

Now I'm going to have a go at grabbing the values through my own code, then I'll port it over to an Arduino board with an LCD module and try to get it to monitor the air flow value so I can check what it's doing if the check engine light comes on again.  Hopefully I'll be able to dig around and see if I can find some of the other values that VWRX doesn't seem to read (like boost pressure).

[oily]

A quick update - I've got my homebrew Select Monitor app up and running, and managed to work out the SSM quirks for my ECU.

The addresses in the VWRX SelectMonitor for ECU codes beginning with 0xA are definitely valid for my ECU too.  I've noticed that the read command does take notice of the fourth-byte parameter for number of bytes to read.  It'll read n+1 bytes in a continuous loop - eg:

command:
78 00 07 02

reply:
00 07 01 02 03 00 07 01 02 03

This makes it an awful lot faster to grab a block of parameters from the ECU.  I was grabbing 20+ parameters and getting 4-5 samples a second for each of them.

I even managed to get it logging on a run - looks like my MAF is toast though.  The CHECK ENGINE light coming on roughly coincided with a period of zero-readings on the MAF sensor in the log

[oily]

If anyone's interested, I've posted the code I used to dump my ECU parameters here:
http://github.com/oesmith/pyselectmonitor

I hope someone finds it useful!