3P's TCCS Disassembly/Analysis

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#1
It's remarkable that after nearly 20 years the Toyota Computer Control System (TCCS) engine management computer used for the 7M remains a mystery as far as the public domain is concerned. Partly, this is because it uses a proprietary Denso microprocessor with zero official documentation available outside of Toyota, and also because the 12kB of ROM code is burned into the microprocessor itself making extraction a major effort, and also preventing any code changes without adding a complex daughter board to allow the processor to run with external memory.

Although several commercial companies cracked it (Techtom, Mines) they kept everything secret and in the case of Techtom even went as far as to encrypt their own code to discourage reverse engineering.

One Japanese site run by H. Kashima has published significant information on the microprocessor architecture, including schematic and layout of a nice board to read the code burned into the microprocessor. He also developed a disassembler for the processor, and has put together a datasheet for the chip pinout, register and memory structure, and so on. Probably because it is written in Japanese, and also because Kashi decided to sell his disassembler and processor datasheet rather than make them public domain, not too many have taken advantage of his hard work in this area.

Recently, Jeremy Ross a guy who hangs out on the UK MR2 forum IMOCUK, has developed a very nice daughter board and software to allow real time data logging and updating of the code tables in the MR2 Gen 1 and 2 ECUs, which are essentially identical to the 7M ECUs of the same vintage. However, Jeremy keeps most of his info to himself, and obviously has plans to sell his ECU kits, so once again nothing gets disclosed publicly.

Against this backdrop of secrecy, there is one glimmer of hope, which is a Canadian based Toyota ECU Wiki. Although not exactly a hotbed of activity, it does have some of Kashi’s stuff translated to English, and also a public domain disassembler for the micro written in Perl.

So, the purpose of this thread will be to read out and analyze the code embedded in these ECUs, and to analyze and publish the various fuel/ignition maps and algorithms used by the 7M ECU.

Acknowledgements:
A couple of people on the forums have helped me out by donating ECUs, and or getting them to me at way below market value.

S383mmber1 (William) gave me a 7MGE M/T ECU. This is an early ECU with only a single circuit board inside. As such, it is probably the best place to start as it is the simplest to analyze.

Supraholics (Miguel) sent me two ECUs including a grey plug 7MGTE M/T ECU for shipping only. This is going to be my first mule for testing things out.
 
Last edited:

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#2
Okay, we start with Williams 7M-GE M/T ECU. First step was to build the ECU reader, which closely follows the one published by Kashi.

I swapped a few components that I couldn't find here in the U.S., but otherwise it is the same. The schematic is attached as a thumbnail to this post. I had about 6 reader printed circuit boards fabricated, so anyone interested can buy one from me.

The reader board uses its own code burned into the 28C256 EEPROM on the board to run the microprocessor. It works by running the micro in a hybrid mode, where it can access both internal and external memory at the same time. A simple serial port interface connects to hyperterminal on a windows PC, and the code is dumped out on the terminal where it can be saved to a file. Kashi supplies a crippled demo copy of the assembly code he used to extract the ECU ROM. With an evening's work tracing his code, it turns out a simple change to one line of demo code is all that is needed to allow the extraction of the entire 12kB stored in the ROM.

Once the code is out, you can run a disassembler to convert it to assembler. Then comes the real challenge, interpreting the assembler to understand how the code controls the engine, discovering and analyzing the built-in maps, and learning how the various engine sensors and controls interface to the micro.

By the way, Jeremy Ross has discovered a high-speed data-logging feature hidden in the code that Toyota used during development. Every variable in the system can be read out up to 200 times a second with 16 bit accuracy. Explaining how to access this datalogger will be one of the first things tackled in this thread.

Below find a photo of the ECU reader board assembled and loaded with the target ECU, a D151801-3920 from William's ECU. Also, a schematic of the reader board, and hopefully the extracted binary code if I can figure out how to attach it to this post.




 

Attachments

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#3
It's a good question, and ultimately depends on how much time I can spend doing this.

First priority is to disseminate info on how these ECUs calculate engine operating parameters, and to publish the 7M ignition/fuel maps.

I already have a daughter board fabricated that will allow me to run the processor from code in an external EEPROM. This allows things like fuel-cut, AFM scaling, ignition maps and so on to be modified. But the process is clunky, you need to FLASH and swap the memory chip to make any changes. Its basically what Mines and Techtom offered back in the day.

Ultimately, I would like to go down the path of Jeremy Ross and work out a way to do real time changes to the maps. That will take some effort as you need to run the code in RAM, and write the software to do datalogging and map tweaking from a laptop. It's my goal, but it's a ways off right now.

I have little interest in making a business out of any of this. I have a real job so I see this as more of a hobby. Some things I may decide to sell if there is interest, such as pcb boards as they can be expensive and time consuming to have fabricated and I have a bunch of extras sitting around.
 

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#4
Hello,

First of all 3p141592654, thanks a lot for releasing this binary file.
This is a great job you've done extracting it! :bigthumb:

The file is 12Ko and doesn't cover the whole 64Ko address space.
If I read the address map on the Toyota wiki (thanks to Greg Kunyavsky for this), it tells us about the D151801 memory map that there's 12ko of ROM memory.

I dissasembled the file using the Perl program (written by Greg Kunyavsky again).
Seeing the addresses started at 0x0000, I decided to make it start at 0xE000, which is the starting address of the ROM inside the CPU.
This file is attached to this post.

If we take a look at the memory map again, we can see that the reset vector is stored at 0xFFFE.
The reset vector is used when the chip is powered on or reset to lead the CPU to the beginning of the program.
This 16bit address leads us to 0xF053

I have to get used to this processor mnemonics but if read the first instructions at 0xF053 while looking at the memory map at the same time:

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


I still don't know the exact purpose of these inits, but looking at this, we can see that these instructions are matching correctly and that this looks like what the begining of a program in assembly often looks like.
By the way, if we try to take a look at the instructions before 0xF053, we see no logic at all from one instruction to another, which leads me into thinking this is some data space that is used for ignition, fuel map or whatever.

3p141592654, if you still have one of these TCCS reader PCB, I would be glad to buy one (or even better, two of them since my soldering skills are average, to say the least).
 

Attachments

Last edited:

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#5
Good work Brutus, nice to know I'm not the only one with some disassembler skills. A much delayed tapeout for a IC amplifier project I am working on plus last week spent in Atlanta at the IEEE microwave symposium is keeping me from pursuing this project lately, but I will pick it back up in a few weeks.

I have slightly different interpretation of the start code, using some of the data I know about the lower bytes of the CPU (my addressing is off, as you noted, but easily fixed-up).

Note that #0x07 means load immediate, so for the first instruction $_OMODE=0x07 rather than a memory reference i.e. it is not $_OMODE=[0x07]

Also note, that for no good reason the operands are swapped for immediate loads. All other "load" instructions are op.1=op.2, so that is probably why you got confused. This inconsistency is a quirk carried over from the Motorola 6800 assembler, proving bad ideas never die I guess!

; reset vector
002053 33071f ld #0x07, $_OMODE ; run internal mode
002056 05 di ; disable interrupts
002057 330d20 ld #0x0d, $_PORTA ; set port A o/p bits
00205a 330f00 ld #0x0f, $_DDRA ; configure i/p bits Port A
00205d 334022 ld #0x40, $_PORTB ; set port B o/p bits
002060 33ff01 ld #0xff, $_DDRB ; configure i/p bits Port B


I'm still struggling to get IDA running right, but that will help alot compared to trying to do this with a simple disassembler. I also need to better understand the mapping of the ports, timers, edge sensors, and so on to the actual engine sensors/actuators. That takes a lot of circuit tracing on the ECU board, and is very painful.

I have extra boards, and I think I have extra parts as well if you want to buy a kit.
 
Last edited:

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#7
Ian, as it stands we are just pulling apart the code and learning how things work. We need to isolate the maps and figure out the algorithms they use before we can move to the next step of plotting the maps and deciding what to change.

I have a very simple board made that can be used to run new code stored in an EEPROM, and bypass the stuff burned into the factory ECU. That would allow changes to be made, but its not very practical to tune this way since you have to physically swap the EEPROM each time. I also want to get access to the ECU real time data so that we can start doing logging. The logging software is all still there, just need to add the interface to a laptop like others have done fro the MR2.

Longer term I want to be able to run the code in RAM so that changes to the maps can be done via lap top interface. That's still way off in the future for now.

Shaeff, thanks for the offer. Right now I'm more time limited than $ limited, but I appreciate your offer and those from a few others as well. This is a great community.
 

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#10
Note that #0x07 means load immediate, so for the first instruction $_OMODE=0x07 rather than a memory reference i.e. it is not $_OMODE=[0x07]

Also note, that for no good reason the operands are swapped for immediate loads. All other "load" instructions are op.1=op.2, so that is probably why you got confused. This inconsistency is a quirk carried over from the Motorola 6800 assembler, proving bad ideas never die I guess!
Thanks for correcting about this opcode (I think you meant #0x33), the code looks muuuuuuuuuuch more logic now! :icon_bigg

I'm still struggling to get IDA running right, but that will help alot compared to trying to do this with a simple disassembler.
I've never used IDA before. I will try to use it if understanding the program gets too tough.

I also need to better understand the mapping of the ports, timers, edge sensors, and so on to the actual engine sensors/actuators. That takes a lot of circuit tracing on the ECU board, and is very painful.
I've done a lot of work on 42pins D151801 ECUs regarding circuit tracing, including the decoding of the AD converter signals that are sent to the main processor. I have also had run these ECUs running out of the car.
I confirm circuit tracing is a painful job, almost impossible without removing all the components of the ECU.
I'm sure I can be of good help regarding this, since I can now recognize some components and figure out their use in many old style Toyota ECUs quite fast.

All analog sensors go to the ADC, and are sent to the CPU via two lines.
Digital sensors go to the CPU via a voltage converter/protecting (vertical) IC.
The actuators (all digital), are sent from the CPU to an amplifying IC (set of Darlington Transistors).
The injectors have their own triggering IC, which is fed by the CPU via less lines than injectors.

I don't know really for the ignition, as the ECU I worked on used only one ignition coil.

I will bring home a 7MGTE ECU next week-end to look at this.

I have extra boards, and I think I have extra parts as well if you want to buy a kit.
Great!
If you get the hand on those parts, this will save me the time to buy them.
Just PM me your paypal account if you have one and the price you want for this, keeping in mind the postage price to France.

I will post my findings when I get some.
 
Last edited:

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#11
JJ: Intel Microcomputer Development System?

Brutus: Check your PM.

We are some ways out from a tunable factory ECU, but there is precedent over in the MR2 world. The stock ECU is pretty impressive for something that was developed about the same time as the IBM AT personal computer. More to come, stay tuned.
 

jetjock

creepy-ass cracka
Contributor
Joined
Jul 11, 2005
Messages
9,439
Likes
0
Location
Redacted per Title 18 USC Section 798
#12
3P: Yes but the only Intel MDS I worked with back in those hey-days of MPU development was the Series II that ran ISIS. It's emulation capabilities didn't support this device. There were others that did however. A logic anaylzer was also used.
 

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#13
Hello everybody,

I'm working on the code at the moment (Identifying interrupt vectors, locate the main part of the program...).

Of course, as 3P said this is going to be far easier to decrypt the code after having located the sensors and actuators pins.

I will bring back a 7MGTE ECU with me this week-end, but I will also bring back a Celica ST165 ECU, since I believe its closer to the 7MGE ECU (single board, 64 pins CPU, only one ignition transistor) we will work with at first.

Unfortunately, I can't destroy it tearing appart all the components as I only have one of these.

If anybody has a unused 7MGE ECU for sale, I would be interested to get it.

It would also be of great help if anyone can post very high resolution pictures (both sides) of a 7MGE ECU for comparison.

I will post the disassembled file in the beginning of next week, as I will hopefully find interesting stuffs in the code by then.
 

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#14
st165-3sgte-ECU.jpg

OK, found this picture of a ST165 ECU. Please let me know if it's close to the 7MGE ECU or not, because I will work on it until I get a 7MGE ECU.
I believe the 7MGE must have only 4 transistors (at the bottom of picture, attached to the frame of the ECU) instead of five because injectors opening are grouped by two injectors, instead of being independant from one another on the ST165.

Here's what I know about the chips at the moment:

D151801-6430: CPU, what's interesting us.
TC40508P: Injector driver, should be linked with the CPU by four lines.
D151801-6470: Knock sensor CPU
D949577-2100: Analog Digital Converter, communicates using a PWM protocol with the Main CPU through pin 3 of this IC. I think it's linked to some ASR pin of the CPU.
HC150: Voltage converter (12V/5V, digital sensors go through this)
MF168 ?
SE022: Not sure about that one, but seems to be some kind of timer.

Please let me know about the 7MGE ECU
 

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#15
Henri, it's very close, but from memory looks a little different. I'll post up a picture of the 7MGE board that I pulled the CPU out of for the assembly code posted above.

Your ECU reader stuff is boxed up, need to get it mailed out today.
 

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#16
Henri, it's very close, but from memory looks a little different. I'll post up a picture of the 7MGE board that I pulled the CPU out of for the assembly code posted above.

Your ECU reader stuff is boxed up, need to get it mailed out today.
Thank you for your time Jon,

I'm trying to find the same ECU as yours on ebay. In fact, the most difficult is to find somebody accepting to send something to Europe (These ECUs are hardly ever found here). I will let you know as soon as I can put a hand on one.

Here's the little I have found now (more to come this week).
The main ADC output (pin 3) goes to ASR0 (This can be checked with a multimeter. Resistance should be close to 0 Ohms).
Injector driver is linked to C3.
PB3 and PB2 goes to the knock detection IC.

I'm struggling with the instruction set now, I have googled everywhere to find some litterature about unusual instructions like TBBS, TBBC, BGEA, BLTA... etc to check their effect on the processor, but couldn't find anything except this decrypted version of Kashi's Datasheet:
http://members.shaw.ca/tibiivan/mk2/Toshiba_8x - Decrypted.pdf

As you can see, the instruction set is described, but with some japanese inside. Does anybody read japanese or knows someone who could translate this?
 

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#17
TBBS and TBBC are a bit confusing to me too. Here is what I know.

TBBS: Branch if bit set ( bit.(op.1) of M[op.2]) = 1 then PC=PC+op.3

opcode: 0x35
operand 1: first 3 bits specify bit to test (0 through 7), remaining 5 bits specify memory location (limited to first 32 bytes of RAM)
operand 2: 8 bit relative shift like the other branch functions

TBBC: Branch if bit clear ( bit.(op.1) of M[op.2]) = 0 then PC=PC+op.3

BGEA: Branch if arithmetic >= (N ∀ V = 0)
Branches if the result of an arithmetic compare was greater than or equal to
operand 1: 8 bit relative shift (all branch instructions use 8 bit relative for the branch so can only access +/- 127 bytes from the instruction location)

Here N (negative) and V (overflow) are two bits in the ECU CCR register

BLTA: Branch if arithmetic < (N ∀ V = 1)
Branches if the result of an arithmetic compare was less than

and so on for the other branches. These closely follow the instructions you can find in the MOT 65xx and MOS6502 processors.

I have decoded the Kashi document. Will need to figure out where to post it.
 

GrimJack

Administrator
Staff member
Administrator
Authorized Seller
Joined
Dec 31, 1969
Messages
12,377
Likes
0
Location
Richmond, BC, Canada
#18
Good work, folks. This was on my list of things to do for years, but it keeps getting pushed off by real life (tm) concerns.

I've got high res pics of the GTE ecu floating around somewhere from the HAC sensor mod for the MAFT Pro setup, if you get to the point that you need them, let me know. I wouldn't be much use on the code end of things without some serious reading, I haven't done any machine code for nearly 20 years! All my EEPROM gear has been in storage nearly that long, too.
 

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#20
TBBS and TBBC are a bit confusing to me too. Here is what I know.

TBBS: Branch if bit set ( bit.(op.1) of M[op.2]) = 1 then PC=PC+op.3

opcode: 0x35
operand 1: first 3 bits specify bit to test (0 through 7), remaining 5 bits specify memory location (limited to first 32 bytes of RAM)
operand 2: 8 bit relative shift like the other branch functions

TBBC: Branch if bit clear ( bit.(op.1) of M[op.2]) = 0 then PC=PC+op.3

BGEA: Branch if arithmetic >= (N ∀ V = 0)
Branches if the result of an arithmetic compare was greater than or equal to
operand 1: 8 bit relative shift (all branch instructions use 8 bit relative for the branch so can only access +/- 127 bytes from the instruction location)

Here N (negative) and V (overflow) are two bits in the ECU CCR register

BLTA: Branch if arithmetic < (N ∀ V = 1)
Branches if the result of an arithmetic compare was less than

and so on for the other branches. These closely follow the instructions you can find in the MOT 65xx and MOS6502 processors.

I have decoded the Kashi document. Will need to figure out where to post it.
Thanks for the help again. :drink1:
I need to re-read some Motorola litterature. :)

I've started working on putting absolute adresses on the relative branch instructions since yesterday to make the code clearer.
When branch offset is less than 128 this is a forward branch, and when it's equal or greater, this is a 256-Offset reverse branch, if I remember well.
This is a pretty long job to do (I don't feel like modifying the disassembler now), so this will require two or three days (not a lot of spare time).

I should be able to get a 7MGE ECU next week, hopefully.
I will then be able to send voltage to the digital sensors inputs on the ECU plug to see which pin of the processor is concerned.
The same way, I will be able to apply 5 volts or ground to the pins of the processor (I/O pins, of course) to check which actuator is concerned on the ECU plug pin.
This won't work for the injectors, but this will be faster than route tracing at the beginning.
 
Last edited:

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#21
Good work, folks. This was on my list of things to do for years, but it keeps getting pushed off by real life (tm) concerns.

I've got high res pics of the GTE ecu floating around somewhere from the HAC sensor mod for the MAFT Pro setup, if you get to the point that you need them, let me know. I wouldn't be much use on the code end of things without some serious reading, I haven't done any machine code for nearly 20 years! All my EEPROM gear has been in storage nearly that long, too.
Thank you for offer for the 7MGTE ECU pics, but we will try to understand the 7MGE ECU first (the 7MGTE will certainly be next :x:).

20 years is quite a long time for sure but if you have some remarks to make when we will start to interpret the code, this will be helpful too. :icon_bigg
 

GrimJack

Administrator
Staff member
Administrator
Authorized Seller
Joined
Dec 31, 1969
Messages
12,377
Likes
0
Location
Richmond, BC, Canada
#22
I also have access to essentially unlimited storage and bandwidth, so if you want to store information on the 'net, let me know.
 

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#23
Photos of the 7MGE M/T ECU (p/n 89661-14092) whose code is posted above.
Sorry for the bad lighting. The ECU has been removed in these photos.



 

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#24
Photos of the 7MGE M/T ECU (p/n 89661-14092) whose code is posted above.
Many thanks for the Pictures, 3P. It's now quite clear that this ECU is quite far from the ST165 ECU I have (Knock sensor CPU package, ICs locations).
I've missed two 7MGE ECUs on ebay.
Please somebody on SM having this kind of ECU (7MGE M/T pre 88) and being ready to send it to f$*#_&g france for a descent price (paid through paypal) contact me.

Assembly file last version attached.
 

Attachments

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#25
Henri, thanks for the update.

I added a little more info. There is a map from 0xf0b2 to 0xf0f6 that is in the format of [addr, data] that gets loaded to ram at startup using the subroutine starting at 0xfc96.

These are presumable the defaults for learned values that you get with an ECU reset.

I've updated the file with this info. Disassembly is addictive, I really should be doing something else right now!
 
Last edited:

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#26
Maybe I've found the ignition maps.

There's a selection between two maps at 0xeb55. Each of these maps are 136 bytes long.

According to Jeremy Ross in this post, the MR2 AW11 ECU has two main ignition maps (one for Idle, the other for normal running) with 17 timing points across the rpm range.


Dividing 136 by 17 makes 8, so each timing point (for one dimension) would have 8 bytes to code the others dimensions (maybe TPS, AFM and rpm) and the timing advance value in 16 bits for each of them. I will try to look further in the code on this subject when I'll have a little more time.
 

Attachments

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#27
... Looked a little further and this might be only 2D maps (ignition advance/RPM).

In that case, ASR2L being a edge counter might have something to do with RPM. Checking on bit 1 seems to be looking at low values however...

Almost two o'clock in the morning... time to go to sleep... will dig the subject later.
 

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#28
I found a lot of maps.

The small four bytes map located at eb86 looks typically like a logarithmic correction (to linear) sensor (small) table.
The only logarithmic sensors I know on these cars are Intake temperature sensor and water temperature sensor (if someone owning a 7MGE can confirm).
Since it looks like it's used for correction at 0xeb6c, just after the suspected ignition map reading, it's more likely to be the intake temp sensor in my opinion.
 

Attachments

Joined
Oct 4, 2007
Messages
2
Likes
0
Location
belgium
#29
Is there no rom emulator you can use on your board?
I doubt the ecu has checksums that need correcting for the ecu to operate, so you can probably just change while driving the car.


Great work btw.
 

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#30
The ROM is in the chip and so the processor runs in internal mode. Forcing the chip to run in external mode means that ports A and B no longer exist, as those pins are now required to be used for address and data lines to the external memory.

Ports A and B are vital to interface the processor to the sensors/actuators, so external logic is then needed to replace the missing port registers and buffers. The accepted practice is to use a PLD to do this, although Mines did it with discrete chips.

Given the above, I'm not sure a ROM emulator can offer much help.

According to a number of sources, there is a checksum performed in the code. I have yet to localize where this occurs.
 

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#31
Figgie: x86 is more complicated than this stuff. Our ECU is just an ancient 8 bit processor.

Henri, the interrupt vector1 is clearly an automatic reboot. Most likely comes from the watch dog timer interrupt. I need to do some experiments to figure out the other interrupts.
 

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#32
Figgie: x86 is more complicated than this stuff. Our ECU is just an ancient 8 bit processor.

Henri, the interrupt vector1 is clearly an automatic reboot. Most likely comes from the watch dog timer interrupt. I need to do some experiments to figure out the other interrupts.
Yes, it really looks like this! :icon_bigg

Also, thr only interesting place port B (4 least significant bits/pins) is written to is the interrupt vector 4 using 0xd7 RAM byte. Condition on bits 2, 3 and 4 of RAM byte 0xd- decides if 0xd7 must be cleared or not.

I'm trying to figure out what this is used for... a difficult task without having the hardware to check which signals are connected to port B.

But fortunately I should have a 7MGE ECU on its way from USA, and I'm looking forward to buy a second one, so I can rip it from its components to help route tracing when pin wiring will not be enough.
 

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#33
In order to keep the revisions organized, I've created a project and moved the posted data to a revision control system located at www.assembla.com

In order to checkout the project files to make changes, you will need to be invited to join the team. Anyone interested can send me a pm. Visitors can view the project files without an account by going to

http://svn.assembla.com/svn/7M_TCCS
 

Gunnar

New Member
Authorized Seller
Joined
Jul 11, 2008
Messages
116
Likes
0
Location
Belgium
#34
I ordered the board and components and im having a go at it too soon.

So far I imported the binfile into the demoversion of winols to look for maps and i compared to a denso volvo file and found some similar maps.

I will post my findings in the project later this week (bit bussy)
 

Nick M

Established 1994
Authorized Seller
Contributor
Joined
Sep 9, 2005
Messages
8,793
Likes
2
Location
U.S.
#35
Great work, and thanks. IJ already hit the main question. So question two is, what about the trans ECU?

I don't really want a piggy back. And I want to run a real mass airflow sensor.
 

3p141592654

90T
Authorized Seller
Contributor
Joined
Oct 11, 2005
Messages
3,890
Likes
12
Location
Thousand Oaks, CA
#36
Never looked in the trans ECU. Anyone have a photo? Wouldn't surprise me to find another 151801 processor in it. Supermonitor has one too.

We've got a long way to go still on the TCCS before we can move to the trans ECU, but it definitely something I would like to follow up on in the future.
 

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#37
I need your help not to fry my 7M ECU when I get it.

This is the pinout of the ECU: http://www.geocities.com/MotorCity/Pit/9975/enginepix/drawings/ToyTCCS_Pins_7M-GE_87.gif

Assuming the few things I know about Toyota ECUs:
-Analog sensors (AFM, TPS, ITS, WTS) voltage should be between 0 and 5V
-Except O2 sensor which must be somewhere between 0.3V and 1.2V
-Except Knock sensor (not really analog), whose voltage output is unknown to me.

What about igniter signals, Test socket input, RPM sensor, Speed sensor, stop light switch?

Which ones are 0-5V and which ones are 12V?
 

Brutus

New Member
Authorized Seller
Joined
Jun 16, 2008
Messages
32
Likes
0
Location
Vosgian mountains, France
#39
Gunnar,

If this is the way a fuel map must look, yes they are fuel maps! :icon_bigg

Attached are graph of maps at 0xdb26 and at 0xdbf8

The excel file requires to have the HEXDEC function enabled (tools, complementary macros).

OK, now obviously, the value going from 0 to 255 is the fuel enrichment.
One of the other value must be RPM (I think 16 value axis going by 400 rpm steps).
The other one must be air quantity measured by the AFM?
 

Attachments

Last edited: