 I got this ECU years ago when I bought a JDM TT engine (just in case the high compression TT idea did not work out - lol). Anyways, my tuner tried to read the chip back then and it looked like a bunch of junk, so we assumed the ECU was no good and I haven't looked at it since. Anyways pulled it out last week for a closer look at the hardware and discovered some interesting stuff. In summary it appears to be a socketed dual image hardware-switchable software-encrypted hardware-decrypted ECU from a 90-92 JDM AT TT that will accept a 512 kbit chip with two ROM images. In English - it lets you have two programs in your ECU and switch back and forth to them from the driver's seat. It also keeps anyone from copying all your secret tuning magic stuff because the chip "appears" unreadable to an EPROM programmer. Here are the details >>>
I looked up these codes on the net. According to some data I found on zcar.com, this ECU is from a 90-92 JDM AT TT.
The chip is a TMS JL 27c512-15. This is an old Texas Instrument chip - they don't make it anymore. Anyways it is 512 kB so it is twice the size of the stock ECU chip and capable of holding two ROM images. Interestingly it is a 150 ns chip which I thought was too slow to run our cars. I thought I read somewhere that the stock chip was closer to 90 ns. The good news is that they don't even make these anymore - new 512's are cheap and fast.
A little work with a multimeter and I figured out the wiring. The blue wire connects to ground. The white wire connects to pin 1 on the chip (which turns out to be address bit 15). The red wire connects to pin 28 (which is the supply voltage Vcc for the chip). Resistance from white to blue and white to red are both approximately 10.5 kOhms. So what does all this mean? Well, connecting the circuit between the white wire and the red wire SHOULD connect address bit 15 to Vcc. In other words address bit 15 is set high or to 1 in binary terms. Connecting the circuit between the white wire and the blue wire should connect address bit 15 to ground. In other words bit 15 is set low or to 0 in binary terms. Basically this is how the hardware switch works - white to blue switches to the ROM image in the lower address set, and white to red switches to the ROM image in the higher address set.
At this point I read the chip with an EPROM programmer and checked out the maps in NISTUNE. To my surprise the maps looked like junk, but not random junk. I started to wonder if there was some type of encryption being applied. A closer inspection of the ECU and the board revealed that the builder had deliberately switched address pin 0 and address pin 13 on the chip. I assume that they used some type of software or perhaps a hardware key to burn their chips such that the correct data is located in the encrypted address so that the ECU actually gets the correct data after the hardware decryption.
At this point, I was still unsure as to whether or not this ECU actually worked or not. I decided to test all these different ideas by installing it in my car and reading the chip via the OBD dataport using Nistune. I hooked it all up and connected Nistune and, to my surprise, a pop-up window in Nistune asked if I would like to read ROM image 1 or ROM image two. Long story short the chip does contain two ROM images. The hardware switch does let you switch from one to the other as described above, and the hardware encrypter actually decrypts the chip such that the ECU sees the correct maps. (I'll post copies of the maps in a separate post if anyone wants to see them.)
Next Step: I am going to try to build a hardware encryption key that will let me actually use this thing. Not sure what I am going to do with the second map. Maybe I will use it in conjunction with a water injection - my main objection to using water injection is that I don't want to rely on it with my setup at the limit if the water runs out. But if I could connect a sensor and automatically switch to a safer map as the water supply drops ....
 
|
Interesting find - modified JDM ECU - 
