Memory dump of ECU

[b3lha]

My circuit boards arrived today. They look fantastic. The fuzzy picture doesn't do them justice. Unfortunately I've been so busy with work that I haven't yet ordered the components to put on the boards.


For those who aren't up to speed, these boards are memory adapters. The EPROM chip that the ECU requires is obsolete. These will plug into the upgrade socket of the ECU and allow the use of modern EPROMs in place of the obsolete one.

I am not planning to make batches of these to sell. But I will make a howto on ordering the bare boards and components, assembling them and programming new EPROMS. It should be easy for anyone who is technically minded and can work a soldering iron.

[b3lha]

On a separate note, I've been studying the USDM TCU a bit recently. I know I said I was going to finish the ECU first, but something we were discussing in another thread prompted me to look. Then I made a little discovery and I had to follow it up.

So far I've figured out that the duty cycles for Solenoids A,B and C are controlled by the timer output compare interrupts toc2, toc3 and toc4.

I'll try and explain how it works. In the description below, I'm talking about milliseconds to make it easier to follow, but the units are not actually milliseconds. The actual unit is somewhat irrelevant, it's the percentage which is important.

There are four things to consider:
1) A Timer (T) that is constantly running. It's just a number that increases by 1 every millisecond.
2) The Compare value (C). The ECU will interrupt what it is doing and run the solenoid switching code whenever T=C.
3) The wavelength (W) of 20000 milliseconds. This remains constant.
4) The Pulse Width (P) which starts out at 19000 milliseconds and is adjusted by the TCU depending on driving conditions.

The operating range of P is from 1000 to 19000. When P=1000, P is 5% of W. In other words a 5% duty cycle. When P=19000, P is 95% of W, a 95% duty cycle.

Initially, the TCU switches on the solenoid and sets C=P. In other words, it switches on the solenoid and says run the switching code after P milliseconds have elapsed.
So, after 19000 milliseconds, T=C, the switching code runs. It turns off the solenoid and adds W-P to C. The solenoid has been on for 19000 milliseconds (95%), now it's going to be off for 20000-19000 = 1000 (5%).
After 1000 milliseconds, T=C again, the switching code runs. It turns on the solenoid and adds P to C.
This repeats over and over.

Iteration 1, T=0
Set C=19000
Turn Solenoid on
Iteration 2, T=19000
Set C=20000
Turn Solenoid off
Iteration 3, T=20000
Set C=39000
Turn Solenoid on
Iteration 4, T=39000
Set C=40000
Turn Solenoid off

etc..

At present, there is no software to read the TCU through the select monitor interface. But if anyone wants to read and log the duty cycles of their A,B, & C solenoids then I can explain how to do it with the Hex Comm Tool.

I am still working on figuring out how the TCU decides what the value of P should be at any particular moment for each of the solenoids. I found a great 6811 simulator program called "Wookie" which has a virtual oscilloscope function. You can actually change values in the software and view the resulting duty cycle.

[crazyhorse]

OK, if I'm reading this right, and I may not be, as my mind went a bit mushy through the calulations. But anywho, there MAY be coming a way to do a manual override of the TCU's active torque spilt?

This being the case, I'm looking forward to reading about this advance.

[Nomake Wan]

Originally Posted by crazyhorse

OK, if I'm reading this right, and I may not be, as my mind went a bit mushy through the calulations. But anywho, there MAY be coming a way to do a manual override of the TCU's active torque spilt?

This being the case, I'm looking forward to reading about this advance.

There is presently no method to do that. The question Phil was attending to was the actual torque split of the USDM transmission. It has been a topic of fierce combat over multiple Subaru forums what the actual duty cycle and torque splits are for US cars. With this, Phil has proven at least that the USDM duty cycles are 5% to 95%.

As for actually forcing these values to change, that would have to be done via a chip of some sort soldered onto the TCU. I don't believe it's possible to make real-time changes to the way the TCU operates as it is. You'd have to burn a chip that contains the modified code, then solder that chip onto the TCU board, and figure out how to switch the board over so it uses your chip instead of its onboard data.

That is, unless Calum does for the TCU what he's doing for the ECU.

[b3lha]

Originally Posted by crazyhorse

But anywho, there MAY be coming a way to do a manual override of the TCU's active torque spilt?

It's certainly possible. I could quite easily add a bit of code that says: if the stick is in 1 and the manual button is on then override the duty cycle such that the torque split is 50:50. Whether there would be any benefit in doing that is debateable.

I am not sure how many analog (voltage) inputs the TCU has. I know it has TPS Position, ATF Temp and Atmospheric Pressure. IF (and it's a big IF) there is another one that is unused then it might be possible to do some sort of DCCD-type arrangement. Where the torque split is set proportional to the voltage that you apply to a particular TCU pin.

At present the TCU is "idiot proof", you can't damage the transmission by in normal operation. But adding a manual override would allow the driver to do dumb things like bind up the transmission and damage it. It might be better to keep the torque split active and just change the parameters that determine the calculated duty cycle.

Originally Posted by Nomake Wan

As for actually forcing these values to change, that would have to be done via a chip of some sort soldered onto the TCU. I don't believe it's possible to make real-time changes to the way the TCU operates as it is. You'd have to burn a chip that contains the modified code, then solder that chip onto the TCU board, and figure out how to switch the board over so it uses your chip instead of its onboard data.

Correct. To modify the TCU, you have to solder a socket to the board, insert your programmed EPROM in the socket, and then disable the onboard EPROM by cutting it's "Chip Enable" pin. It has been suggested that, after cutting it, I should connect it to the Vcc pin with a little bit of wire to make sure it stays high. I don't know if this is necessary or not, but it sounds sensible.

I plan to try TCU mods soon.

[Nomake Wan]

I'd be more than happy to be your USDM guinea pig again. Heaven knows it's been little but productive and beneficial!

[crazyhorse]

I'm interested in the transmission work. There's a fellow SVXer in sweden, I believe, working on XT6 cybrid steering, and paddle-shifting a 4eat. Both with external circuits.

[b3lha]

Originally Posted by crazyhorse

I'm interested in the transmission work. There's a fellow SVXer in sweden, I believe, working on XT6 cybrid steering, and paddle-shifting a 4eat. Both with external circuits.

Paddle shifting could probably be implemented in software. I would use the wires for the power switch and the manual switch to indicate "change up" and "change down". You would leave the shifter in D and then replace the shift decision logic in the TCU software with some custom software. It might not even be very hard to do. But we don't yet have enough knowledge yet.

[b3lha]

Originally Posted by Nomake Wan

I'd be more than happy to be your USDM guinea pig again. Heaven knows it's been little but productive and beneficial!

Thanks Nomake. Did you ever get your USB cable working?

[Nomake Wan]

Originally Posted by b3lha

Thanks Nomake. Did you ever get your USB cable working?

I still haven't built the correction circuit but it works just fine for talking to the TCU without it.

[b3lha]

Originally Posted by Nomake Wan

I still haven't built the correction circuit but it works just fine for talking to the TCU without it.

Here's a new toy for you to play with, if you want it: tcuscan. It's a bit of linux software to display information from the TCU. I knocked it up in a couple of hours last night. It's not very good, but it's better than not having any software that can read the TCU.



I have tested it on my car and it seems to work. It should work on your car too because the ROM dump I'm looking at originated from your car.

[Nomake Wan]

Awesome!!!! I'll play with this tomorrow, since it's my day off.

[Nomake Wan]

Okay, I've got a problem again!!

Earlier, I was using the USB-Serial adapter along with you SSM adapter. Now, I'm using a USB-TTY adapter by itself. The Knoppix disc you gave me also had a bad sector (my own fault, it's scratched), so I'm using v5.1.1 of Knoppix instead. This appears to have caused a problem.

With your original TCUScan, the program ends returning -4. I tracked that down to opening the driver to set options.

I then changed the adapter to dev/tty and it returned a -2, something about invalid. So I changed it to dev/tty0 and it returned -1 "Permission Denied." Using any other number returned the same message.

So apparently, my new adapter is either not being mapped by Knoppix or it's mapped to something different from my original USB-serial adapter. Help! How do I find out where this thing is mapped to?

EDIT: I asked a Linux buddy of mine to help me out, and he found the problem; it's mapped to dev/ttyUSB0. Now I just gotta plug in and check it out!

[b3lha]

Originally Posted by Nomake Wan

Okay, I've got a problem again!!

Earlier, I was using the USB-Serial adapter along with you SSM adapter. Now, I'm using a USB-TTY adapter by itself. The Knoppix disc you gave me also had a bad sector (my own fault, it's scratched), so I'm using v5.1.1 of Knoppix instead. This appears to have caused a problem.

With your original TCUScan, the program ends returning -4. I tracked that down to opening the driver to set options.

I then changed the adapter to dev/tty and it returned a -2, something about invalid. So I changed it to dev/tty0 and it returned -1 "Permission Denied." Using any other number returned the same message.

Well done on figuring all that out.

Originally Posted by Nomake Wan

So apparently, my new adapter is either not being mapped by Knoppix or it's mapped to something different from my original USB-serial adapter. Help! How do I find out where this thing is mapped to?
EDIT: I asked a Linux buddy of mine to help me out, and he found the problem; it's mapped to dev/ttyUSB0. Now I just gotta plug in and check it out!

LOL. Isn't that where your old one was mapped to?

[Nomake Wan]

Originally Posted by b3lha

Well done on figuring all that out.

LOL. Isn't that where your old one was mapped to?

Funny thing! It turns out, that due to using the older version of Knoppix earlier (which didn't do the whole NTFS thing), I never saved my edited version of your loader! So imagine my confusion when I plug in my trusty old flash drive and it tosses an error! But yes, it's the same location.

And now, the results!

HOLY CRAP, MOST AWESOME PROGRAM EVER. You should've seen my grin as I drove around with the thing running. It's amazing how your programs seem to pull off what a certain other program can't--namely polling multiple variables all at once and returning accurate information 100% of the time in nearly real-time speed.

Turns out, the only time I could get Solenoid C into 95% (FWD I'm guessing) was if I put the shifter into N or P. As soon as I put it into drive, I'd usually get about 60%-70%. Drop it into 1st and that lowers to 45% or so.

I did manage to drop it to 5% once, when I mashed the gas from a dead stop. That was fun too.

After the whole test drive was done, I did notice that a second percentage appeared next to Solenoid C's duty percentage. 27%. What's that about? Glitch? It didn't change at all after I messed around sitting in the driveway... hm.

My only suggestion is that you add in an indicator for the Torque Converter Lockup. I'll test it the next time I hit the freeway.