3P's TCCS Disassembly/Analysis

[3.0 GT]

It is not practical to rewrite the assembly language code to use old-fashioned speed-density D-type engine management. With the availability of high-capacity MAF sensors and a MAF translator all that really should be needed is to scale the input signal accordingly in the factory code. That is something that I am looking at doing short term as it will help those using the Lexus AFM mod as well.

---------- Post added at 10:00 AM ---------- Previous post was at 09:48 AM ----------



... and then they can send it to me so I can take a look at how it compares to a standard ECU.

are you able to change things like idles speed?

 

[3p141592654]

In principle, except that I don't understand the idle control code very well.

 

[supra90turbo]

It is not practical to rewrite the assembly language code to use old-fashioned speed-density D-type engine management. With the availability of high-capacity MAF sensors and a MAF translator all that really should be needed is to scale the input signal accordingly in the factory code. That is something that I am looking at doing short term as it will help those using the Lexus AFM mod as well.

---------- Post added at 10:00 AM ---------- Previous post was at 09:48 AM ----------



... and then they can send it to me so I can take a look at how it compares to a standard ECU.

Makes sense. I was more curious than anything

 

[cybspi]

Hey 3P-

I'd like to help you out with the fuel map part of the problem. I have a lot of experience with c# programming, and happen to own an 87 supra with the 7MGTE engine and a spare ecu. Is it possible to replicate what you've demo'd in that video?

thanks!

 

[Nick M]

If it were, I suspect that by now our friend Π would be rich beyond his wildest dreams right now, and Supra engine management would be 20 years ahead of it's time.

I might not have moved over to a 5.0. Well, yes I would have.

It is not practical to rewrite the assembly language code to use old-fashioned speed-density D-type engine management. With the availability of high-capacity MAF sensors and a MAF translator all that really should be needed is to scale the input signal accordingly in the factory code. That is something that I am looking at doing short term as it will help those using the Lexus AFM mod as well.

I don't like the GM sensor. From a technician point of view. I asked Pro-M back in 2002 or 2003 if they would build a MAF off the vane air flow meter, and they said "hell ye$". I agree, it is a much better route than speed density.

 

[Heavy D]

wow havent seen this in a while but good work on doing this, hope things goes good, im sure theres some one with a group A ecu

 

[bk_]

Hi JonS. I noticed a few updates just then

Just wondering if you figured out anything more about the tables format stored in the ECU.

If not, I will be able to make some minor progress in 2 weeks time once I have some items delivered to me from Japan.

Will reveal more details once I test and verify the results. And no, it's not mightymap software or hardware, heh.

 

[3p141592654]

I have been working quite hard on the ECU code. Here is some useful info if you are reversing tables.

Temps are given by the following formula: coolant temp = THW - 40 (degC). air temp = THA - 40 (degC)
The computed speed is in km/h. The computed rpm is RPM*5.12. The inputs to these equations are the values computed and stored in RAM for those parameters. Quite a bit of work is done to linearize the sensors to get temp and speed from the raw sensor data.

Those are the typical inputs to tables, along with the load, which is clamped to B800h, unless you have a Techtom ECU where they allow FF00h.

Here is an interesting nugget if you can run the ECU out of the car. With a combination of inputs as follows: diagnostic mode on, IGN switch off, and starter on (now you can see why it needs to be on the bench), the ECU will enter a self test mode and check RAM, ROM, knock sensor communications, and run some port tests depending on the status of the idle, neutral start switch, and oil pressure inputs. The mil light will blink with different rates if things fail, and outputs of port B and a serially linked port on the TD2335 chip will be exercised as a sequential strobe across all bits.

 

[Nick M]

I would add to reputation if the forum was set up to do so.

 

[bk_]

Looks like the LOAD number is based on the ADC value of the MAP sensor in 16 bits.

Here's the calculations for two different Toyota MAP sensors:

Stock MAP sensor for 1JZ / 2JZ:
PIM = 5246*V - 3785

At BAP, I know my 1JZ reports 2.626 V (based on the reading from the PowerFC using stock sensors)
So:
PIM = 5246*2.626 - 3785
PIM = 9991 kg/m^2

For stock SW20 MAP sensor (according to PowerFC) @ BAP:
PIM = 6986*V - 5592 (PowerFC calculation)
10000 = 6986*V - 5592
15592 = 6986*V
V = 2.232 V

0xb8 is 184 in decimal. 184/255 is the ratio for 5.000 V

So stock max load for SW20 would be:
PIM = (6986*5*184/255) - 5592
PIM = 19612 kg/m^2 ( 13.67 psi )

I do know the OBD output of the stock ECUs do report pressure as kPa, if it is D-jetro (MAP sensor) based.

 

[JonS]

Hi JonS. I noticed a few updates just then

Just wondering if you figured out anything more about the tables format stored in the ECU.

I haven't figured out much beyond what's in the IDA projects for the 3S ECU. I'm currently trying to figure out the scaling of the maps but it's made tricky by the way the code modifies the inputs to the map interpolation routine.
One example of how 'RPM' is manipulated to give *lower* resolution above 2850RPM:

ROM:CC5C                     ld  d, var_rpm                ; Load D with RPM
ROM:CC5E                     cmp a, #38h                   ; Check if D < 0x38FF (2850 RPM)...
ROM:CC60                     bcs loc_CC66                  ; ...jump forward if not
ROM:CC60
ROM:CC62                     add a, #38h                   ; Add 0x3800 to D
ROM:CC64                     rorc a
ROM:CC65                     rorc b                        ; Divide D by 2
ROM:CC66 loc_CC66:                                         ; CODE XREF: sub_D2E2-682j
ROM:CC66                     jsr map_interpolate_3d_div_4  ; Divide by 4 and perform map interpolation

 

[JonS]

For stock SW20 MAP sensor (according to PowerFC) @ BAP:
PIM = 6986*V - 5592 (PowerFC calculation)
10000 = 6986*V - 5592
15592 = 6986*V
V = 2.232 V

I've been using the measurements from http://gtfour.supras.org.nz/mapsensor.htm, BAP give a voltage of 2.3293v on the MAP sensor.
Fuel cut on the Rev 3 MR2 is ~18psi. In the ECU code this is represented by the value 0xDA00.

From the above web page, the voltage on the MAP sensor at 18psi is:

v = 0.1025 x 18 + 2.3293 = 4.174v

Assuming the ADC gives a reading of 0xFFFF for 5v, at 18psi the ADC reading would be:

65535 / 5.0 * 4.174 = 0xD5B4

Which isn't that far off the 0xDA00 in the ROM code.

 

[bk_]

The tables could be divided into two sections. I know it's done in some aftermarket ECUs (eg: HKS). so between 0-2850 it could be every 250 RPM, then after that it could be 500 RPM.

I will be able to obtain the scale of the ignition table, aswell as the real ignition values, hopefully by next weekend. I will also verify the logged RPM and the OBD values

A few more things I discovered while I reverse-engineered the OBD-like output 4 years ago:

INJ is multiplied by 10. eg: a value of 23 dec is 2.3 mS
IGN is offset by 90 (I think). eg: 110 dec is 20 degrees BTDC.
RPM is multiplied by 25. eg: 56 dec is 1400 RPM (max is 6450 RPM??? could be *25 up to 2850 RPM)
ISCV (fully open) is 125 dec.
OBD-like cycle for one bit of data is 8.192 mS +/- 0.100 mS. so around 122 bits per second.

The order of the OBD data is as follows:
0) UNKNOWN 8 bits
1) INJ
2) IGN
3) IAC / ISCV (steps?)
4) RPM (*25 if under 2850 RPM?)
5) MAP (kPa)
6) ECT (V, 8 bits ADC)
7) TPS (%, /2?)
8) SPD (kph)
9) UNKNOWN 8 bits
10) UNKNOWN 8 bits
11) FLAGS #1
12) FLAGS #2

Hope that helps.

 

[JonS]

Thanks, that's very useful info. I can get the ECU generating the OBD like output and then probe with an oscilloscope to determine which pin on the MCUs is generating the signal. From that it should be possible to work backwards to find the code that generates the OBD bitstream.

I've just figured out the scaling of the RPM signal for the main maps on the 3S ECU. The first entry is for 400RPM, then every 200RPM until 2800RPM, then after that it's every 400RPM. The stock maps go up to to 7600 RPM (last entry is 7200 to 7600RPM) which ties up with the stock rev limit of 7400rpm.

 

[bk_]

Some more information on the format of the OBD-like stream.

It's 8N2. So 1 start bit, 8 bits of data, 2 stop bits. data is pushed out LSB first.

The beginning of the OBD stream is 16 bits of high state. then 4 unknown bits (0100 for 1JZ) then 13 frames (8N2) containing data.

Also for the FLAGS (1=ON):

Data #11, Flags #1:
bit 0: Cold Start UP (ECT is less than 71C?)
bit 1: Warm (ECT is 71C+?) UP

Daa #12, Flags #2:
bit 0: Start SW
bit 1: Idle (throttle closed) SW
bit 2: A/C SW
bit 3: Neutral SW (manual gearbox)
bit 7: DIAG condition (1=GOOD)

Some of the above information could be slightly wrong. But it's a very good starting point

 

[3p141592654]

There are three main 2D maps in the v1332 code used on 90+ 7MGTEs. They all go up to 6400 rpm, after that the last number in the table is clamped. Resolution is 400 rpm and C00h load units. In-between values are linearly interpolated in 2 dimensions. No extrapolation is allowed for values above or below the table edges.

Address Rows Cols x units y units x-origin y-origin x-var y-var
D49Fh 14 14 400rpm C00h 800rpm C00h RPM VE(THA)
DDC8h 7 13 400rpm C00h 1200rpm 4800h RPM VE(THA)
D358h 10 11 400rpm C00h 2000rpm 3000h RPM VE

I'm still working out what each one does, the code is complex.

 

[3p141592654]

The CAD files for the ECU read board are on Assembla.com in the 7M_TCCS project space. I don't have any plans to make more of these boards, so I thought I would make the files available in case anyone decides they want to make their own boards.

 

[bk_]

I've made an assembly auto-commenter script in Perl. You can download it from http://trap.mtview.ca.us/~xk/pics/supramania/toshiba-8x-comment.pl

It creates very basic C-like (or logic-like) statements as comments. It removes human error from creating these statements by hand.

It's 50%'ish done. There's probably a couple of mistakes. I'm happy to accept bug reports or patches (diff -u).

Here's an example of the output:

::: DEBUG: 		    xor	a, x + 00h                  ; a = a ^ x + 00h  ( a ^= x + 00h )
::: DEBUG: 		    and	a, y + 00h                  ; a = a & y + 00h  ( a &= y + 00h )
::: DEBUG: 		    st	b, y + 00h                   ; y + 00h = b
::: DEBUG: 		    and	b, x + 00h                  ; b = b & x + 00h  ( b &= x + 00h )
::: DEBUG: 		    add	a, b                        ; a = a + b
::: DEBUG: 		    st	a, x + 00h                   ; x + 00h = a

 

[bk_]

Script updated to v0.002.

All but 2 instructions have been done. They are div and blea.

Several auto-generated comments may need to be refined.

Please find any bugs or issues

Enjoy!

 

[Nick M]

If this were SF, I would say this thread is full of win.