3P's TCCS Disassembly/Analysis

[Brutus]

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]

I also have access to essentially unlimited storage and bandwidth, so if you want to store information on the 'net, let me know.

 

[3p141592654]

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]

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.

 

[3p141592654]

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!

 

[Brutus]

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.

 

[Brutus]

... 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]

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.

 

[Chippedtuner]

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]

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]

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]

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]

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]

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]

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]

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]

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?

 

[Gunnar]

I took a look at the binfile, and compared it to a more recent denso file and i think it has these maps:

(barely had time, but once i get all the parts for my board i'll spend more time on it)

 

[Brutus]

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?

 

[Brutus]

While we're at it Gunnar, does the attached maps look like ignition maps?