Memory dump of ECU

[b3lha]

Originally Posted by Nomake Wan

Phil,

I plugged the (old) adapter into a 94 L yesterday and sure enough, it worked just fine no matter how much crap I turned on. Weird.

Just waiting on the mailman.

Yeah. Some cars work fine with the old adapter, some need the extra circuitry. I think you were right when you put it down to tired old wiring.

Did you get the email I sent you to your yahoo address?

[Nomake Wan]

Yes, I got the email. It's been a while since I've soldered anything, but I'll do my best.

[Nomake Wan]

I just soldered together the upgrade board. It's really shoddy but it works. Had to adjust the potentiometer a bit but after that it runs great. No matter what I mess with the signal is clear and pure.

Please instruct me further! A way for us to talk in real-time would be preferred. The setup is already in the car, I've got wires run through the window so the laptop can be powered and the doors can be closed during the process. Keep in mind that I'm using a USB-to-Serial adapter. I'm not sure if that Knoppix disc has a driver for it.

But I'm ready to dump my ECU! Instruct me, master!

[Trevor]

Originally Posted by Trevor

Or is your input impedance/loading too low i.e. too sensitive. A higher relative loading would pull down the output/input signal voltage. This could be where the Subaru OEM monitor differs. The fact that you indicate that a zero voltage is not being recorded, points in this direction.

The lower the monitor input impedance/resistance; the greater the signal current; lower the voltage (Dependent on output capacity) and greater the immunity to noise. In all respects the transmitted signal is more robust, a worthwhile feature.

In other words, the existing signal could be overloading your gear. Think of the affect of overloading the input of an audio amp.

It has taken as long time to get things right in a round about way. I provided the answer as above way back in the thread.

[Nomake Wan]

I have an interesting thing to note.

When I initially tested the new board (prior to adjusting the potentiometer), I couldn't get the ECU to talk to me. The commands I sent resulted in no response.

For kicks, I then tried the TCU... and got totally coherent data back. I was perplexed. So I changed the potentiometer and eventually got the ECU to talk to me, albeit with "000000" repeated over and over. Yet still, the TCU was talking clearly. A little more messing with the potentiometer and all was well.

But I find it amazing that the TCU was able to communicate just fine independent of how the upgrade circuit was set.

[Trevor]

Originally Posted by Nomake Wan

I have an interesting thing to note.

When I initially tested the new board (prior to adjusting the potentiometer), I couldn't get the ECU to talk to me. The commands I sent resulted in no response.

For kicks, I then tried the TCU... and got totally coherent data back. I was perplexed. So I changed the potentiometer and eventually got the ECU to talk to me, albeit with "000000" repeated over and over. Yet still, the TCU was talking clearly. A little more messing with the potentiometer and all was well.

But I find it amazing that the TCU was able to communicate just fine independent of how the upgrade circuit was set.

Good one Nomake.

Could you please advise where the pot. was set when you ---

(1) Initially tested the new board.

(2) Then tried the TCU.

(3) Changed the potentiometer and eventually got the ECU to talk.

(4) After a little more messing.

Use a clock scale, twenty minutes to, through twenty minutes past, with twelve o'clock being halfway, and specify which end relates to ground/negative.

Congratulations that in spite of some problems building the circuit, you got there. You may find it interesting to back track in this thread, to my notes regarding "ugly" wiring techniques.

Cheers, Trevor.

[b3lha]

Originally Posted by Nomake Wan

I have an interesting thing to note.

When I initially tested the new board (prior to adjusting the potentiometer), I couldn't get the ECU to talk to me. The commands I sent resulted in no response.

For kicks, I then tried the TCU... and got totally coherent data back. I was perplexed. So I changed the potentiometer and eventually got the ECU to talk to me, albeit with "000000" repeated over and over. Yet still, the TCU was talking clearly. A little more messing with the potentiometer and all was well.

But I find it amazing that the TCU was able to communicate just fine independent of how the upgrade circuit was set.

I've never had a problem communicating with the TCU. I think it must produce a good square wave. With logic zero rock solid at ground and logic one rock solid at 5v.

I've been thinking that the "92 problem" might be due to bad grounding. Since the signal voltages are relative to ground, the ground at the receiver must be exactly the same as the ground at the sender. Perhaps the TCU always works because the ground wire in the SSM connector is directly connected to the TCU ground? Perhaps the ECU ground is not exactly the same potential as the TCU ground due to a little resistance in the wiring?

Pure speculation, of course, and it no longer really matters why the problem occurs because it has been solved.

[b3lha]

Originally Posted by Nomake Wan

Please instruct me further! A way for us to talk in real-time would be preferred. The setup is already in the car, I've got wires run through the window so the laptop can be powered and the doors can be closed during the process. Keep in mind that I'm using a USB-to-Serial adapter. I'm not sure if that Knoppix disc has a driver for it.

But I'm ready to dump my ECU! Instruct me, master!

OK. First step is to see if your laptop will boot into Knoppix. Make sure your USB/serial thingy is plugged in before booting so that it loads the driver (if it has one).

Try to boot from the CD and see what happens. Usually you can just hit enter at the linux boot prompt, but sometimes laptops can be picky:

On my compaq laptop, I have to type "knoppix26 nodma" at the boot prompt, otherwise the mouse doesn't work. On my dell laptop, I have to type "knoppix26 atapicd", otherwise it fails to boot because it can't find a driver for the CDROM. If you do run into problems, the error message should give you a clue why and there is a list of the codes to try at http://www.knoppix.net/wiki/Cheat_Codes

You need to extract the files from the attached zip onto a floppy disk. This is my ecudump software.

Once knoppix has loaded, you need to open a terminal window. Doubleclick on the icon that looks like a computer terminal.

Then you need to run the following commands, Incase you haven't used a unix shell before, I'll explain what the commands mean in brackets afer each one, don't type what is in the brackets.

su -         (switch from knoppix user to root user, to increase your access privileges)
cd ~knoppix          (go to the home folder of the knoppix user)
mcopy a:           (copy all the files from the msdos floppy disk to the current folder)
ls -l                   (show the list of files in the current folder)
chmod +x ecudump         (give execute permission to the ecudump program)
./ecudump -s 8000 -e FFFF -f ecu.dat       (download the ECU rom from address 8000 to FFFF into a file called ecu.dat)
ls -l        (There should be a file called ecu.dat 32768 bytes in size)
mcopy ecu.dat a:       (copy the ecu.dat file to the floppy)

Then email me the ecu.dat file and I'll be happy. (Then I'll start chasing you for a TCU dump )

Phil.

[b3lha]

Originally Posted by b3lha

You need to extract the files from the attached zip onto a floppy disk. This is my ecudump software.

That post would have looked a lot more clever if I had actually attached the zip file.

[b3lha]

Originally Posted by Trevor

It has taken as long time to get things right in a round about way. I provided the answer as above way back in the thread.

Indeed. Looks like you were spot on with your original assessment of the problem. Had I properly understood what you were saying, we could have got there sooner, but now I'm just glad the problem is solved.

[Nomake Wan]

Thankfully I've used Unix before, so this should be cool. Though the problem here is that my laptop has like... nothing in it when it comes to media devices. I'll have to mess a bit and see if I can't get the ecudump stuff onto the laptop another way. Well, I'm off!

[Nomake Wan]

I'm hosed. The laptop I'm using has a proprietary PCMCIA DVD drive, and Knoppix doesn't have a driver for it. I've tried a bunch of cheatcodes and none allow access to the disc. The problem I'm having is the same as these guys:

http://www.knoppix.net/forum/viewtopic.php?t=3815

So yeah, totally hosed. The only internal media loading devices the laptop has are the built-in LAN and the SD card reader. Everything else is external.

[Nomake Wan]

Fixed it. I copied all the CDROM files onto my flash drive, then booted from the CDROM. When it scanned the USB devices, it found the boot data and loaded. So now I have knoppix. Yay. I'll try the stuff now...

[Nomake Wan]

Wow, a quad post.

Anyway, sadly it doesn't look like your SSM object knows how to talk with my USB-Serial adapter. The adapter shows up in the Info Center under "USB Devices," but your ecudump program ends after the "Dumping Addresses..." with the error "(ssm_open... returned (-4)". Looking that up in your code, it's the TTY driver call, right?

At this point I don't know how to proceed.

[b3lha]

Originally Posted by Nomake Wan

Wow, a quad post.

Anyway, sadly it doesn't look like your SSM object knows how to talk with my USB-Serial adapter. The adapter shows up in the Info Center under "USB Devices," but your ecudump program ends after the "Dumping Addresses..." with the error "(ssm_open... returned (-4)". Looking that up in your code, it's the TTY driver call, right?

At this point I don't know how to proceed.

Well done on getting this far.

You are absolutely right, the -4 means the call to the tty driver failed. I should probably have put a check in the code to see what error was returned by the tty driver. Bad programming practice by me. Fortunately, the manual gives only two possibilities: Either "not a valid file descriptor" or "the file associated with the file descriptor is not a terminal".

The ecudump program tries to open /dev/ttyS0 by default. That is normally the name of COM1. But maybe it's different because of your usb to serial adapter.

Could you try running "dmesg | grep tty" and see what it comes back with?

If the device name is something else, you can specify "-d devicename" to the ecudump program.