Everything you ever wanted to know about the AW4

[kastein]

Yep, that's probably a good idea to get if you want to do this on a TCU to be reused.

I've got 18 (going on 19...) years of experience soldering and can do 0.5mm pin pitch PQFPs by hand, so I'll probably just slap a couple wires on the VDD, VSS, SCL, and SDA pins on the chip. Assuming of course that powering the EEPROM doesn't parasitically power the MCU, which would result in it booting up and interfering with any attempts to read data out of the EEPROM, so it might be wise to lift the VDD pin and wire it alone to the programmer/reader.

Still waiting on that stupid adapter though - everything hinges on it.

 

[O-Gauge Steamer]

It may be easier than we think... I just got off the phone with Banks Power and they claim that their part number 66120 AutoMind Handheld Programmer will allow the shift points to be altered among other nice to have goodies like the aux fan turn on point.

For my application, using it to fiddle with the ignition would just be silly. Unless there is a true gain to be had when not under boost...

Am not awaiting the manual to be emailed.

Not a cheap solution but one that would be very easy to play with.

Amazon linky:
http://www.amazon.com/Banks-Power-66120-AutoMind-Programmer/dp/B005TR6NCI/ref=sr_1_1?s=automotive&ie=UTF8&qid=1385581625&sr=1-1&keywords=Banks+Power+AutoMind+Handheld+Programmer+66120

 

[Alexia]

I already read the EEPROM on the AW4 TCU. There is basically crap on there.

 

[O-Gauge Steamer]

Well,

Thank you for that most illuminating piece of information. I think it safe to say what you say was hexadecimal values in memory.

This is called "Machine Language", not crap... Data...

 

[Alexia]

Well,

Thank you for that most illuminating piece of information. I think it safe to say what you say was hexadecimal values in memory.

This is called "Machine Language", not crap... Data...

No, I meant that it was crap, not useful, not going to help us with it alone. It says UAW with a few characters of unreadable data. Both the AW4 TCUs I read were this way. Nothing in that EEPROM gave details to its intended purpose other than a storage device.

 

[kastein]

Not machine language, it's for data storage only. Machine language is executed directly.

Also, "basically crap on there" is pretty close to useless. Yes, you can't interpret the data fields stored in the EEPROM without reverse engineering the firmware in the MCU... that's what I've already said.

Unless you've reverse engineered that firmware already and determined what exact parameters are stored in the EEPROM, of course.

Clearly nothing is going to give details to the intended purpose of any of the data - it's for parameter storage, not writing a novel or an ASCII human readable config file or something into. When you only get 256 bytes, you tend to be a little more terse than normal.

 

[Alexia]

Just looking at the data the majority of it was blank. With enough data present it is possible at a minimum determine a basic data format.

 

[kastein]

How much was blank? Assuming either 00s or FFs... and it's sorta possible, unless it's just a few bitfields/flags and some hardcoded shift point values that aren't in any recognizable unit, for instance I'd expect them to be in something like "timer ticks between OSS pulses after timer prescale factor has been applied" which could really be almost any 8 or 16 bit number depending on how fast the system clock is and how big the prescaler divisor is.

I was quite impressed by your work on decoding the 97-01 instrument panel odometer/VIN storage EEPROM, but I wouldn't be surprised if all the critical data we need to modify here fits within the size of the few smaller fields in that EEPROM that didn't have any discernible purpose.

 

[Alexia]

I will grab a fresh copy of it tonight and post it.

 

[Alexia]

https://dl.dropboxusercontent.com/u/9392221/EEPROM/AW4 TCM/1998-XJ-AW4.bin

My only thoughts other than it containing a checksum or firmware version is that they are reference values for the TPS signal.

 

[HappyDog]

https://dl.dropboxusercontent.com/u/9392221/EEPROM/AW4 TCM/1998-XJ-AW4.bin

My only thoughts other than it containing a checksum or firmware version is that they are reference values for the TPS signal.

Thank you for the PROM dump -- now I don't have to try to do it!

 

[O-Gauge Steamer]

Received the email from Banks. The Sales person went to Engineering who, calmly, informed her that the 66120 nor any Banks programmer can alter the TCM.

Back to square one.

 

[kastein]

I wrote a quick stab at decoding the EEPROM file given and then my stupid laptop barfed and lost it.

Here's what I felt like retyping: the first 4 bytes (0x55 0xAA 0x55 0xAA) are probably a signature - that's the same series of bytes that are used frequently to denote the start of a ROM or boot sector. Mostly because they're easy to remember, consist of alternating zero and one bits, 0x55 OR 0xAA is all 1s, 0x55 XOR 0xAA is also all 1s.

Offsets 55 (0x55) and AA (0xAA) are probably to do a very primitive/basic validity check of the EEPROM's programming. I haven't looked through the MB89665 instruction set in years (it's in the datasheet available on alldatasheet.com if anyone wants some light reading) but I'd guess that when reading values from the EEPROM, one writes the requested offset address (0x55 or 0xAA) out to the I2C controller and then reads the data byte back when it comes in. The firmware is probably written in assembly language based on how little ROM space is available in the MCU and how much functionality is jammed into it, so being able to simply write a value out of one register, wait for data to return, copy it into another register, and compare the two for equality is convenient/lazy as a way to check if the EEPROM data is valid at all.

Offsets 0x30 through 0xFF (aside from 0x55 and 0xAA) are all 0xFF, the default value for an erased EPROM or EEPROM due to how the floating polysilicon gate in each memory cell transistor works.

Offsets 0x20 through 0x2D are zero and probably meaningless or for debug data.

Offsets 0x2E and 0x2F are 0xF2. I'm guessing (but haven't verified) that these are a checksum; most likely all bytes in the EEPROM must sum (modula 256) to 0x00 or the TCU will report an EEPROM data corruption. If I get bored tomorrow I'll probably write up a quick program to sum the whole file and see if I'm right.

Offset 0x04 might be part of the signature/header, might be valid data. Not sure.

Offsets 0x05 through 0x0B are probably interesting parameters.

Offsets 0x0F, 0x18, 0x1B, 0x1F may also be interesting parameters.

Everything else is zero and probably either unset flags/options or just unused space.

 

[HappyDog]

Perhaps the EEPROM is used to store trouble codes and freeze frames. Why not purposely cause a TCM fault and see if the contents of the EEPROM change?

 

[kastein]

That is quite possible and definitely a good idea.

 

[O-Gauge Steamer]

From what little I have been able to glean, the TCM is a self diagnostic unit and will store codes IF they repeat within a limited time frame. Would have to look it up again but believe the time frame to be 7 seconds.

Multiple references are made in the Diagnostic Manual for using the DRBIII tool to read and clear these codes.

Given this to be true, I suspect that the "empty" memory locations are there for code storage. One would need on location per MIL event.

If you would be interested in the code list, I will go through the Manual and list them for you!

Need them?

 

[O-Gauge Steamer]

ERROR CODES:

Hex Name of Code
$B0 Solenoid #1 Shorted to Voltage
$B1 Solenoid #1 Shorted to Ground
$B2 Solenoid #2 Functional Fault
$B3 Solenoid #1 Shorted to Voltage
$B3 Solenoid #1 Shorted to Ground
$B5 Solenoid #2 Functional Fault
$B6 TCC Shorted to Voltage
$B7 TCC Shorted to Ground
$B8 TCC Shorted Functional Fault
$B9 Input Speed Sensor
$BA Output Speed Sensor
$BB Throttle Position Sensor Signal Circuit
$BC Check Shifter Signal
$BD CCD Message from JTEC Failure
$BF Internal TCM
$C0 Internal TCM
$C1 Transmission Voltage Low
$C2 Transmission Voltage High
$C4 Internal TCM

Each code has an associated Test Number with the exceptions of errors $BF, $C0 and $C4. Those three codes have "Replace TCM" as the recommended test. So, whatever those faults are, they are fatal...

 

[NoLimePlease]

I am in the process of swapping 4wd into my 97 XJ. The donor Tranny is from a 01 xj, and I am now dealing with the rear speed sensor issue. I can tell you that the 97 2wd two lobe tone ring for the speed sensor will fit the 01 4wd tranny. It is the same diameter, a little shorter but there is actually two sets of snap ring recesses on the 01 tail shaft to accommodate the older sensor ring. Unfortunately the sensor itself is not large enough to fit the oss hole.
Has anyone tried or heard of just grinding off 3 of the four ears on the newer ring and using the newer output speed sensor? The newer style is a magnetic pickup with the magnet on the sensor, not the ring. exact opposite of the old, but I would assume it sends the same hall effect signal...

 

[NoLimePlease]

or does the newer speed sensor create A/C voltage for tcm signal?

 

[kastein]

The newer sensors create AC voltage signals while the older ones are a reed switch. There are three ways you can go here:
1. swap the tailhousing from a 97 down 4x4 AW4 onto yours, along with the sensor and rotor from your old transmission.
2. build the circuit lawsoncl designed (it's linked in a few places in the first post) and use the sensor, rotor, and tailhousing that came with the new transmission.
3. build the circuit lawsoncl designed, but eliminate the CD4xxx series chip and wire the output of the op-amp directly to the 2Nxxxx series transistor. Then grind off 3 of the rotor lobes. Use the donor's modified rotor, tailhousing, and sensor.

I would personally go with #2, but I've been soldering and tinkering with electronics since I was around 8, so it kinda comes naturally.