3P's TCCS Disassembly/Analysis

[auto351]

This here is the code from the 7MGE

ld #0x7, $0x1F // Sets the five least significant bit of the SMR register to 1
di // Disable interrupts
ld #0xD, $0x20 // inits the timer comparison LSB with the port A data (?)
ld #0xF, $0x0 // inits the timer comparison #3 with the port A direction status (?)
ld #0x40, $0x22// Sets the first byte of the RAM with the port B data
ld #0xFF, $0x1 // Sets the last byte of the RAM with the port B direction status

and the code from the 1G

ld #07h, $1Fh ; Mode control Register
di
ld #01h, $20h ; Port A Data Register
ld #0Fh, $00h ; Port A i/o config
ld #40h, $22h ; Port B Data Register
ld #0FFh, $01h ; Port B i/o config

Thanks to Brutus & 3Ps work my task is a little easier as these two ECUs look to be Structured alike.
what documentation are you using for the ECU operation I have the basic Toshiba 8x info is there anything else ?

 

[3p141592654]

Hi,

You said the 7MGTE A/T & M/T CPU code is different is the numbering printed on the chip the same?

With the 1G A/T & M/T ECU the CPU Chip has the same numbers printed on them which leads me to think they are the same code (I will confirm this soon.) The 1G A/T has extra chips to control the automatic transmission, this maybe getting done inside the CPU on the 7M unit hence the different code for this reason but the main engine tuning is the same?

I hoping this board above will replace the CPU only so with some mods I can fit this to the 1G ECU
Also will you need a special lid to conceal the new daughterboard?

The chip part numbers are different. The code revision number is actually printed on the processor as well. It is the second line, usually something like 7433-xxxx on the 7M where xxxx is software id, which can also be found in the code just before the vector table.

The 7MGE code has both A/T and M/T code inside. It runs one or the other based on the resistors installed on the board. The 7MGTE uses different processors between A/T and M/T. No simple resistor switch will convert the two.

We will need a lid to conceal the daughter board as it will sit above the digital board.

what documentation are you using for the ECU operation I have the basic Toshiba 8x info is there anything else ?

You will need to map the engine sensors/controls to the processor I/O to get anywhere from here. Until you know how the engine sensors and controls connect to the processor ports it is very hard to proceed.

 

[Victor Charlie]

You will need to map the engine sensors/controls to the processor I/O to get anywhere from here. Until you know how the engine sensors and controls connect to the processor ports it is very hard to proceed.

Yes, I've been working on the disassembly as well. I'm amazed how far you guys got already. I've been editing the comments and address labels and color coding to set apart different sections of code so I can make sense of it. Once I get everything all pretty I'll post it on assembla.

You seem to have figured out a lot of the connections to the processor ports already, according to the assembly code. Are all these connections mapped out somewhere, or does it need to be done experimentally with the circuit.

Also, I wonder if it's time to crack the code for the turbo version, since the comparison with the non-turbo might give some useful clues to both?

 

[3p141592654]

The GE ECU I/O has been completely documented by Henri (Brutus). He developed a simulator to trace signal paths in the ECU since it is very hard to do it by inspection of the traces since many of the ICs are undocumented Denso parts. That work has been folded into the disassembly files that you are looking at. I did many hours of the disassembly work for the GE on cross-country airplane flights to and from Washington DC. Its about the only time I can get 3-4 hours of focused time. There is a lot of time sunk into understanding that code... not too mention writing alot of test codes to figure out how the processor works.

Henri has got most of the GTE I/O mapped as well. It is mostly the same as the GE. The biggest difference is the KV AFM that comes in on an ASR port instead of the ADC like the GE. No surprise at all if you think about it.

An interesting tidbit, the GTE uses two signals IGA and IGB to select which coil to fire. Those signals are generated by two Denso ICs that use NE and G1/G2 as inputs. The processor does not compute IGA and IGB, and in fact does not even know they exist.

A good question: why aren't we working away on the GTE code?

The main reason is that I want to get the diagnostics hardware running as it will make it so much easier to disassemble the GTE code. Instead of guessing about what a variable is doing, it will be possible to see it as the ECU is running. That will make it much easier and faster to figure out. Also, Jason (rotor3) has made some nice improvements to IDA that make the decompiled code more understandable. I need to get that compiled and up on Assembla as well.

 

[Victor Charlie]

The GE ECU I/O has been completely documented by Henri (Brutus). ...That work has been folded into the disassembly files that you are looking at.

Great, just wanted to be sure I had it all.

A good question: why aren't we working away on the GTE code?
The main reason is that I want to get the diagnostics hardware running as it will make it so much easier to disassemble the GTE code.

Even if we aren't working actively on it, there would be a benefit to
getting as far as snatching the contents of the GTE ROM and posting it for comparison. I don't know if it has already been read out by someone. It is the critical step that allows many others to get involved, and would be useful for years to come, so it would be a great contribution if someone would take that one step in case this effort runs out of steam before it gets completed.

I need to get that compiled and up on Assembla as well.

I'd love to see it, it's what I'm doing too, so I could possibly contribute some things to improve it further.

Thanks for all the good work you are doing.

 

[3p141592654]

Don't worry, I've been waiting for Henri to wrap-up the I/O analysis before posting the GTE code. We've had it dumped for a long time, but without the I/O mapping it is impossible to make any progress. There are still about 10 pins that need to be verified before it is complete.

 

[3p141592654]

Manuel sent me this PM, and rather than respond in private I thought I would discuss it in public so others can benefit. We have covered some of the 'dirty tricks' used by Toyota to save memory, and this is another example (see post 66 where we discuss a similar scheme)

Basically, the instruction "brn 0D26Dh" is a glorified 2 byte no-operation. It does nothing since brn is "branch never" and so the relative address following is ignored.

That means you can put anything in the last byte and it will always just be skipped over. Now, suppose that you purposely have a test somewhere in the code that branches to the second byte of the brn instruction. This is normally considered illegal, and disassemblers will flag it as an error as IDA does, but it is perfectly okay to do this if you are doing it on purpose to save space. In this case, the BLE instruction at address 201 does exactly that It looks illegal, but is in fact 100% intended. Thus, it will use, in this case, 67h (the offset to address D26Dh) as the instruction opcode, which is
SET c

This saves space because they don't need to add a branch after the "clr c" code to steer around it, since it blasts thru the brn as a NOP, saving one byte of code space. Yeah, one lousy byte, but they only had 12kB to work with, so it matters. I think this philosophy has it roots in even earlier ECU processors having as little as 2kB of ROM.

Note that the DOUT register is typically used to drive injectors and ignition. That fragment code looks familiar, and I think it is part of the ignition computation.

just working on the I/O mapping but had a quick look at the code again and I found a problem with the disassemble flow
the BRN is a branch never but IDA puts a red line to the address which follow the instruction,
this cause code to show up in the data area
the delow data should ends at D281 but finished at D,26B, becuse of the BRN


here is the call and below that is the calling code
ROM1FB shl d
ROM1FC shl d
ROM1FD sub a, #06h
ROM1FF cmp a, $0C7h
ROM201 ble 0D205h
ROM203 clrc
ROM204 brn 0D26Dh ; CODE XREF: ROM201j
ROM206 ret
ROM206 ; ---------------------------------------------------------------------------
ROM207 .db 60h ; `
ROM208 .db 22h ; "
ROM209 .db 70h ; p
ROM20A .db 26h ; &
ROM20B .db 80h ; Ç
ROM


rem RAM data loaded when batt lost?
ROM263 .dw 9500h
ROM265 .dw 9680h
ROM267 .dw 9700h
ROM269 .dw 9855h
ROM26B .dw 9955h
ROM26D ; ---------------------------------------------------------------------------
ROM26D
ROM26D loc_D26D: ; CODE XREF: ROM204j
ROM26D st d, $55h
ROM26F ld s, $55h
ROM271 cmp x, $55h
ROM273 cmp y, $00h ; Port A i/o config
ROM275 cmp x, #608Dh
ROM278 ld y, $9Eh
ROM27A nop
ROM27B ld y, $00h ; Port A i/o config
ROM27D ld d, #5587h
ROM280 st d, x + 00h
ROM282 nop
ROM283 shl d
ROM284 shl $01h ; Port B i/o config
ROM286 dec x + 01h
ROM288 nmi

 

[auto351]

Jon,

I see byte saving techniques, I wasn’t clear in my PM, the problem I saw was the way IDA handled / interoperates the instruction BRN, IDA looks at the following byte (after BRN) and converts that to a branch address (which is correct) , IDA then assumes that address in a valid branch & contains code (which is incorrect)
In my case address D26D is data not code.
I got the code and put (2) NOP NOP at address D204 & D205 when this was disassembled the address D26D was taken as data as I expected. Looking at the original instructions at address D26D down you have 3 CMP which has no effect.
I know the code will not run with NOP in the above locations, as you said the BRN in like NOP in part, I wanted to test what would happen to a NOP in the same location.

My understanding is the modules Dx8.cgf & Dx8.W32 were custom written to work with the Toshiba within IDA, so it needed to be programmed/configured to understand the processors instructions, I wonder if it’s possible to change this interpretation of BRN so there is no branch assumed.

In my code there are 5 inconsistencies which resulted due to the current BRN interpretation, no big deal just nice to fix.

 

[3p141592654]

You are right, there is a bug in IDA on BRN. The 7M code doesn't use BRN so it slipped by, they seem to use the CMP function for this type of thing. There has been some work by Jason recently on making the IDA output cleaner. I need get that work out on assembla so everyone can benefit.

As far as I can tell, IDA cannot handle the branches to addresses that are "inside" an instruction, and flags them as an error. There may be a way to deal with that, but I don't know how myself.

 

[Victor Charlie]

I have collected all the data maps I could identify from the ECU disassembly into a simple text file. Open with a non-proportional font, like courier. Some interesting points: Most one dimensional maps are variable length single-byte values, terminated with the bytes 0FFh, 00h, 00h. Some two dimensional maps are preceeded by two bytes that specify the dimensions of the tables, #columns first, then number of rows.

I am a bit hampered by not having a processor manual. For instance, i don't know what the instructions "bsr" (binary 61), and "nmi" represent, as well as a few others. I'm also not clear on the stack protocol. I found some engine parameters being initialized at positive offsets from the top of the program stack, but I'm not sure if they are in the stack or following it. They don't seem to be referenced directly in the code other than initially calculating and storing them

There is still a lot to be done to identify the relationship of each map to actual operational inputs and outputs to the ECU, which I know is being looked at by Pi and Brutus, but we can probably do more with the disassembly to identify what system each of the maps pertain to and each place in the code they are used. Most maps are referenced by direct addressing in the code, but others may be referenced differently.

 

[auto351]

Hi,
I have a interesting ECU its marked as 645E A/T & Toyota part number 89661-529D9
There is an internal board which holds the CPU 2 * EPROM 27C64 and a TC156022AP (which is a PIA IC) plus the xtal

have a few questions
Just wanted to know if it was from a 7M the suffix for the chip is 1039 which is contained in addr 0xfffch & 0xfffd, however the chip is marked as 7433-1035 but both of these look like 7M as 1G I have seen are 7433-11xx or 7433-12xx but it may just be date related too ?


ROM:FFCF .db 0BFh ; +
ROM:FFD0 .db 86h ; å
ROM:FFD1 .db 0E0h ; a
ROM:FFD2 .db 0F0h ; =
ROM:FFD3 .db 68h ; h
ROM:FFD4 .db 68h ; h
ROM:FFD5 .db 52h ; R
ROM:FFD6 .db 6Ch ; l
ROM:FFD7 .db 75h ; u
ROM:FFD8 .db 0EEh ; e
ROM:FFD9 .db 73h ; s
ROM:FFDA .db 00h
ROM:FFDB .db 00h
ROM:FFDC .db 10h
ROM:FFDD .db 39h ; 9
ROM:FFDE .dw IVb ; External interrupt 0


My main question is about the EPROM arrangement one is marked "1" while the other "5" so I dumped the contents of both EPROMs.
Chip "1" contained data from 0xFD3h to 0x1FFh and chip "5" contained data in the complete EPROM.

When I combine these sets by appending "5" to "1” the result data takes up 0x302Ch bytes which then falls outside the mapping for the classic model Starting 0xD000 to 0xFFFF.
I changed the starting address to 0xCFD3h which then aligned the reset vector, but looking through the code there are still some funnies, where am I going wrong the file are labled as per the chips, you can see these number on the PCB also

EDIT::
The above chip is not a 156022 but infact a 15G022 and its some type of gatearay.

 

[auto351]

I picked up this ECU today and the PCBs are Identical to my other 1G PCB the main differnence beeing this ECU has a Toshiba CPU T5891



anyone know what the A & N mean I worked out what D was.

This would indicate the D151801-XXXX is from this family and not 7433 ?

 

[3p141592654]

Wow Manuel! A ceramic packaged version with a Toshiba logo. This is proof that Toshiba was the foundry that made all these chips. Doesn't seem to be any public domain data on it that I can find. Must have been a Denso funded project between Toshiba and Toyota.

Have you tried peeling the label off of it? Might be a window under it for UV erasable ROM. I know that such chips do exist as Jeremy found some.

"A" might be the application and "N" the version number. Just a guess.

 

[3p141592654]

VC,more info on the processor can be found here. http://toyota.kgbconsulting.ca/mediawiki/index.php/3S-GTE_Technical_Info

This is basically Kashi's datasheets translated into english. There is plenty of missing info, but this is a good start.

 

[3p141592654]

Manuel, the 15G022 ASIC is presumably being used to replace the ports lost in external mode. The same thing that we do today using the Xilinx CPLD chip. Only difference is they needed to make a full up ASIC and fabricate it in the Toshiba foundry to make that chip while we just program the CPLD flash memory using our VHDL code. A $15 solution versus a $150,000 chip run. How times have changed!

 

[Victor Charlie]

VC,more info on the processor can be found here. http://toyota.kgbconsulting.ca/mediawiki/index.php/3S-GTE_Technical_Info

This is basically Kashi's datasheets translated into english. There is plenty of missing info, but this is a good start.

Thanks, that's just what I was looking for. I'm just aiming to trace back the program flow from where the maps are accessed to summarize what we know about each calculation from sensor input to map use, to outputs affected. If am am reading your notes correctly, there are a few short sections needing decompiling still, apparently because the code in a few places comes down to a jump or branch that doesn't seem right. For example at ROM: E904h the jump at the end of the function doesn't seem to lead to a valid return, but jumps in to the middle of apparently unrelated code. I'm still analyzing it, but so far I don't get it. Most of the rest of the code follows very a very regular style and structure, so I'm sure the disassembly is right. Let me know if there is some specific task you would like me to work on.

 

[Kai]

Guys - this may or may not be of some use, but i thought this:

http://cgi.ebay.co.uk/MINES-ECU-Toy...arts_Vehicles_CarParts_SM?hash=item439ded3da5

Might be of interest - specifically because it has some closeups of the MINES daughterboard, and even some component names/numbers can be made out.

 

[7thousandpiecesMGTE]

Was it ever confirmed that the turbo A used a different ECU? I know it was mentioned a long time ago in this thread that it appeared to.....

 

[GregK]

Hi Guys,
I host the Toyota ECU wiki at http://toyota.kgbconsulting.ca. I can't believe I did not know about this thread and about the work you have been doing for 2 years! I just read through this whole thread and it's very exciting replaying your progress. I am going to look at svn.assembla.com next. Is that where the latest stuff get posted? I can contribute a ROM dump from a 1989 3S-GTE to your collection. Should be very similar.

Two years ago I translated Kashi's stuff and dumped the ROM from a 3S-GTE ecu using his dumping board schematics, just like you have done. Then I fed short byte sequences into Kashi's disassembler (limited version) to come up with the complete instructions set that's on the wiki and wrote a rudimentary disassembler, toshi. I don't think a free version of IDA was available back then or maybe I just did not find it. Looks like toshi is not useful any more now that you have ported IDA. I hope you found some of my info and tools useful to get you started. Great to see you are not keeping your discoveries secret either!

 

[Kai]

I've been going over the hardware side of things, noting down all the discrete components on my GTE PCB's, and although i've managed to track down a great deal, i come up short when presented with a 'Denso' part. I'm presuming these are either ASIC's, or rebranded parts from some other manufacturer.

Does anyone have any idea as to what IC's the following are:

ND SE022, ND MF122, ND MF166, D HC154, D IS121, D HE048 & D HC284

In addition, I have one 40 pin Denso 151801-5190 just below the Denso 151802-1940 - Two MCU's on the same daughterboard?

Finally, that TC15G022 is indeed a Toshiba ASIC, it's used in a few area's of the car, most notably the tail lamp failure module. The specs for it are:

3µM Process
2.5nS Gate Speed
2200 gates

If you need more info, this PDF has everything you need:

http://www.ic-on-line.cn/IOL/datasheet/tc17g032_209630.pdf

HTH!