1996 EJ20 Legacy ECU "T8"

[b3lha]

This thread is to discuss the "T8" ECU from Daniel's car.
Forked from thread "Another hex dump interpretation" http://www.subiesmart.com/forum/index.php/topic,43.0.html

This is a JECS ECU from a 1996 EUDM Legacy EJ20 BD5 Manual NA. The ROMID is 742FA1.

So far, we have a hex dump and some disassembled code.

[mrdjc]

Phil,
Thanks for the new Split.exe file.

I have removed all the old sub-####.txt files and redone them with your new file.

I just downloaded Free Hex Editor Neo from http://www.hhdsoftware.com/Products/home/hex-editor-free.html

Just started reading the stuff you posted back on Brett's thread.. Bajezus what have I started!

I've read it 3x, and am sure I will be reading it a lot more.. I just need to get my head round everything, especially values of addresses, and the whole 0 1 2 3 4 5 6 7 8 9 A B C D E F business.

I'll try to understand it, if I cant I'm afraid I'll have to ask for explanations.

It all looks oh so simple logically thinking in theory, but all the random letters and numbers in front of my eyes don't make much sense to me or compute upstairs just yet.

I guess I have a major advantage (I hope) knowing that the JDM Impreza '96 adresses used in evoscan largely cover my vehicle, so could be used for cross reference.

Ok, off to read it again...

Cheers,
Daniel.

[mrdjc]

Ok here goes (First attempt at trying to copy/paste code from the editor onto a forum!)
(Jeeez, took a while to find how to export it.. Had to start a 14 day trial..)

Using what you described in the other thread:

Code:

0000ffd0: 0b 0a 00 ff 80 97 80 97 80 97 80 97 80 97 a1 da ................
0000ffe0: 80 97 3f ca 80 97 f0 c9 80 97 67 ca 80 97 de c9 ..?.......g.....
0000fff0: 80 97 a7 c7 80 97 a6 fe 80 97 80 97 80 97 80 ...............

Presuming I understood you correctly, the Interupt Vector Table is based on the CPU Datasheet and so the addresses are the same for mine as the ones you used, only the values are different.

So my version would be:

Code:

FFD4: A/D Interrupt control - 9780
FFD6: UART0 tx interrupt - 9780
FFD8: UART0 rx interrupt - 9780
FFDA: UART1 tx interrupt - 9780
FFDC: UART1 rx interrupt - 9780
FFDE: Timer D interrupt - DAA1
FFE0: PWM1 interrupt - 9780
FFE2: Timer B1 interrupt - CA3F
FFE4: TG2 interrupt - 9780
FFE6: TG1 interrupt - C9F0
FFE8: Timer B4 interrupt - 9780
FFEA: Timer B3 interrupt - CA67
FFEC: Timer C2 overflow - 9780
FFEE: Timer C1 overflow - C9DE
FFF0: Timer C2 strobe interrupt - 9780
FFF2: Timer C1 strobe interrupt - CA3F
FFF4: External INT interrupt - 9780
FFF6: Watchdog timer - FEA6
FFF8: Debug - 9780
FFFA: BRK instruction - 9780
FFFC: Divide by zero - 9780
FFFE: Reset vector - 9780

So my "Reboot" is 9780.

I now have the following files put in a seperate folder called "IVT".
Sub-9780-Reset-Vector.txt
Sub-C7A7-TimerC1Strobe-Vector.txt
Sub-C9DE-TimerC1Overflow-Vector.txt
Sub-C9F0-TG1-Vector.txt
Sub-CA67-TimerB3-Vector.txt
Sub-DAA1-TimerD-Vector.txt
Sub-FEA6-Watchdog-Vector.txt
Sub-CA3F-TimerB1-Vector.txt

These are all covered by the Sub-9780-Reset-Vector.txt file:
FFD4: A/D Interrupt control - 9780
FFD6: UART0 tx interrupt - 9780
FFD8: UART0 rx interrupt - 9780
FFDA: UART1 tx interrupt - 9780
FFDC: UART1 rx interrupt - 9780
FFFA: BRK instruction - 9780
FFFC: Divide by zero - 9780
FFF4: External INT interrupt - 9780
FFF0: Timer C2 strobe interrupt - 9780
FFF8: Debug - 9780
FFE0: PWM1 interrupt - 9780
FFE8: Timer B4 interrupt - 9780
FFE4: TG2 interrupt - 9780
FFEC: Timer C2 overflow - 9780

[mrdjc]

Gosh, I'm a bit baffeled now..

I've just done the "Findstr sta sub-*" thing.
Did you mean in the newly renamed txt files or the whole lot?

Its come back with a rather varied result..
What number exactly am I looking at?

Here is a bit I typed out manually... I take it its the "8D####" one I should be looking at? Which part of it should I ignore as the adresses you refer to in the other thread are only 4 digits long.
(4000 up to 47FF)

Code:

Sub-EE22.txt:00EE43     428D0910    sta     bl, 0x1009
Sub-EE22.txt:00EE47     8D0810       sta     al, 0x1008
Sub-EE22.txt:00EE56     8DEF12       sta     al, 0x12ef
...... (bit further down)
Sub-FCED.txt:00FD8F     8D5F11       sta     al, 0x115f
Sub-FCED.txt:00FD95     8D5E11       sta     al, 0x115e
Sub-FCED.txt :00FD9D    8D6011       sta     al, 0x1160

Cheers,
Daniel.

[b3lha]

I noticed these ones aren't within the range of adresses I have text files of for some reason:
FFE0: PWM1 interrupt - 0A0B (Not in range of text files.)
FFE2: Timer B1 interrupt - FF00

You have done it right, but you are reading the wrong line. ffe0 is 9780 and ffe2 is ca3f.

[b3lha]

Gosh, I'm a bit baffeled now..

I've just done the "Findstr sta sub-*" thing.
Did you mean in the newly renamed txt files or the whole lot?

Its come back with a rather varied result..
What number exactly am I looking at?

Here is a bit I typed out manually... I take it its the "8D####" one I should be looking at? Which part of it should I ignore as the adresses you refer to in the other thread are only 4 digits long.
(4000 up to 47FF)

Code:

Sub-EE22.txt:00EE43     428D0910    sta     bl, 0x1009
Sub-EE22.txt:00EE47     8D0810       sta     al, 0x1008
Sub-EE22.txt:00EE56     8DEF12       sta     al, 0x12ef
...... (bit further down)
Sub-FCED.txt:00FD8F     8D5F11       sta     al, 0x115f
Sub-FCED.txt:00FD95     8D5E11       sta     al, 0x115e
Sub-FCED.txt :00FD9D    8D6011       sta     al, 0x1160

Cheers,
Daniel.

the addresses are the bit at the end.
sta al,0x1160 means store the content of the al register at address 1160. The "0x" is just a notation to indicate that the address is in hex.
Your RAM appears to be in the 1000-? address space. This means that your ecu hardware is different to Brett's. It might be similar to mine. See if you can find where is sets the stack pointer near the start of the reset vector.

[mrdjc]

Doh!  Feel even more like an idiot now.. For some reason I was reading Value "0" as "B" I think

Code:

My brain was working like this for some vague Reason:
0 1 2 3 4 5 6 7 8  9 A B C D E F

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

It SHOULD off course be:

0 1 2 3 4 5 6 7 8 9 A B C D E F

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Right so now I'm going to try and find out the address space over ALL the text files, so the lowest to the highest.

The example you used had 4000 to 47FF so maybe draw a conclusion that mine starts at 1000 and will probably end at 17FF? (If the size is identical on each ECU?)

Ok, highest I can find is 0x137C lowest 0x1008
So safe to say 0x1000 - 0x13FF, but stack pointer says 0x14FF

Code:

From the Sub-9780-Reset-Vector.txt file:
00978C    A2FF14        ldx     #0x14ff
00978F    9A            txs     

Back to Edit Previous Post so anyone coming in can see how its laid out.

[b3lha]

On a sidenote, Phil, Could you please post a snippet of code from the Hex editor so I can see exactly what values and addresses you are using or are working out?
I can clearly see 11 12 13 14 15 etc in my values but I have no idea what is the actual START of the code, is it 11? Or before that? There's way to many numbers in there to see clearly and I have no idea where the rest are hidden, there are so many random numbers in there I dont know if they represent CEL codes or not.

I think I made a mistake somewhere. The 742fA1.bin file I have is 65869 bytes rather than 65536 bytes, so the address in my hex editor is off. The bytes are at A880 in this file but they should be at A827. Assuming you have the right file, you should find this at A827:

00 00 38 00 00 49 51 00
21 22 23 24 31 32 33 35
11 12 13 14 15 16 17 00

These correspond to the Subaru check engine codes.

[mrdjc]

Phil, it appears your an all nighter like me too! Great being unemployed..  :

Just checked my file, its 65536 like you say, I'll email you a new one.

This is what I have:

Code:

0000a820: f8 b5 00 8d a2 11 60 00 00 38 00 00 49 51 00 21
0000a830: 22 23 24 31 32 33 35 11 12 13 14 15 16 17 00

so "00" is the start of the code?  How do you know which is the first value of the CEL code?

Phil, I just tried emailing you the bin, but my webmail is acting up, i tried twice, so either you have 2 identical emails, or none at all, I'll try tomorrow again.

Cheers,
Daniel.

[log1call]

Daniel,
        hi, just got my hex editor search figured. It all worked a Phil said it would, once I searched in the right direction.
 I was wondering whether you had noticed that across the top of the data in hex editor there are white squares that light up to indicate which byte you have selected. It helps to learn the numbering.
 Hope it helps, Brett.                                         

[b3lha]

Phil, it appears your an all nighter like me too! Great being unemployed..  :

Just checked my file, its 65536 like you say, I'll email you a new one.

This is what I have:

Code:

0000a820: f8 b5 00 8d a2 11 60 00 00 38 00 00 49 51 00 21
0000a830: 22 23 24 31 32 33 35 11 12 13 14 15 16 17 00

so "00" is the start of the code?  How do you know which is the first value of the CEL code?

Phil, I just tried emailing you the bin, but my webmail is acting up, i tried twice, so either you have 2 identical emails, or none at all, I'll try tomorrow again.

Cheers,
Daniel.

I didn't get any email from you. It looks like the original hexdump742FA1.hex that you sent me is 33101 bytes instead of 32768. So, when I added the 32K of zeros at the front I ended up with 65869. The file seems to be corrupted with some DOS carriage-return/line-feed characters (0D 0A). Did you try to open it in some kind of text editor?

[b3lha]

This is what you should have found:

Here is the hex from A820, I have decoded it below:

Code:

0000A820   F8 B5 00 8D A2 11 60 00 00 38 00 00 49 51 00 21
0000A830   22 23 24  31 32 33 35 11 12 13 14 15 16 17 00 AD
0000A840   A2 11 2C 01 10 20 17 29 FF D0 01 60 C9 10 90 05

This matches up with the end of Sub-A7BD.txt (look at the 2nd column)

Code:

00A820    F8            sem                                     ; m:1 x:0
00A821    B500          lda     al, dp + 0x00 + ix
00A823    8DA211        sta     al, 0x11a2
00A826    60            rts

Then come the CE codes at A827.

Code:

00 00 38 00 00 49 51 00 21 22 23 24  31 32 33 35 11 12 13 14 15 16 17 00

and then the code continues with Sub-A83F.txt

Code:

00A83F    ADA211        lda     al, 0x11a2                      ; Call target from A746, Call target from A77B
00A842    2C01102017    bbs     #0x20, 0x1001, 0xa85e
00A847    29FF          and     al, #0xff
00A849    D001          bne     0xa84c
00A84B    60            rts
00A84C    C910          cmp     al, #0x10                       ; Branch targetfrom A849
00A84E    9005          bcc     0xa855

[b3lha]

Daniel,

Following the same principle as described in the other thread. Your current error flags are at 102D and your stored error flags are at 1359.

I can't run your ECU code in the simulator because of my faulty bin file. But from examining the code, it looks exactly the same as Brett's (apart from the addresses). Presumably the decoding is as follows:

102D 102E 102F CE Code Error 00000001 (01) 00000000 (00) 00000000 (00) 00 n/a 00000010 (02) 00000000 (00) 00000000 (00) 00 n/a 00000100 (04) 00000000 (00) 00000000 (00) 38 Engine Torque Control 00001000 (08) 00000000 (00) 00000000 (00) 00 n/a 00010000 (10) 00000000 (00) 00000000 (00) 00 n/a 00100000 (20) 00000000 (00) 00000000 (00) 49 CO Resistor 01000000 (40) 00000000 (00) 00000000 (00) 51 Neutral Switch 10000000 (80) 00000000 (00) 00000000 (00) 00 n/a 00000000 (00) 00000001 (01) 00000000 (00) 21 Temperature Sensor 00000000 (00) 00000010 (02) 00000000 (00) 22 Knock Sensor 00000000 (00) 00000100 (04) 00000000 (00) 23 MAF Sensor 00000000 (00) 00001000 (08) 00000000 (00) 24 Idle Solenoid 00000000 (00) 00010000 (10) 00000000 (00) 31 Throttle Sensor 00000000 (00) 00100000 (20) 00000000 (00) 32 O2 Sensor 00000000 (00) 01000000 (40) 00000000 (00) 33 Speed Sensor 00000000 (00) 10000000 (80) 00000000 (00) 35 Purge Solenoid 00000000 (00) 00000000 (00) 00000001 (01) 11 Crank Sensor 00000000 (00) 00000000 (00) 00000010 (02) 12 Starter Motor 00000000 (00) 00000000 (00) 00000100 (04) 13 Cam Sensor 00000000 (00) 00000000 (00) 00001000 (08) 14 Injector 1 00000000 (00) 00000000 (00) 00010000 (10) 15 Injector 2 00000000 (00) 00000000 (00) 00100000 (20) 16 Injector 3 00000000 (00) 00000000 (00) 01000000 (40) 17 Injector 4 00000000 (00) 00000000 (00) 10000000 (80) 00 n/a

[log1call]

Yup,
      that's the bit that has got me confused Phil... How we get the code numbers from the binary.
 I will study what you have said here and in my thread.

[b3lha]

Daniel,
Now we know that your Current Error flags are at 102D-102F. Lets try and find the TPS parameter.

The TPS error flags is bit 4 of 102E (0x10). So we look for subroutines that set (seb) or clear (clb) that bit.

The command below finds all subroutines containing "102e" then sends the output to a second findstr command which filters through it looking for "seb". This gives us a little less output to read.

findstr 102e Sub-* | findstr seb
Sub-9FC8.txt:009FE5    0C2E1010      seb     #0x10, 0x102e
Sub-9FF7.txt:00A07D    0C2E1020      seb     #0x20, 0x102e
Sub-A42A.txt:00A4E9    0C2E1080      seb     #0x80, 0x102e
Sub-A3BD.txt:00A419    0C2E1008      seb     #0x08, 0x102e
Sub-A082.txt:00A0A6    0C2E1002      seb     #0x02, 0x102e
Sub-A0AB.txt:00A126    0C2E1040      seb     #0x40, 0x102e
Sub-9F0F.txt:009F4C    0C2E1004      seb     #0x04, 0x102e
Sub-9F5A.txt:009FBE    0C2E1001      seb     #0x01, 0x102e

somewhere in the list we see:
Sub-9FC8.txt:009FE5    0C2E1010      seb     #0x10, 0x102e

So the TPS test subroutine is Sub-9FC8. I've added some comments to help you understand what it is doing. It's easier than Brett's because it doesn't have that bizarre "subtract from 400" thing.

Code:

009FC8    AE3C10        ldx     0x103c                          ; Load X with TPS reading
009FCB    E01400        cpx     #0x0014                        ; Compare X to TPS lower limit
009FCE    F007          beq     0x9fd7                            ; If equal goto 9fd7
009FD0    9005          bcc     0x9fd7                             ; If less goto 9fd7
009FD2    E0D803        cpx     #0x03d8                        ; Compare X to TPS upper limit
009FD5    9013          bcc     0x9fea                             ; If less goto 9fea

009FD7    0C381120      seb     #0x20, 0x1138             
009FDB    A28711        ldx     #0x1187                         ; Load X with address of TPS error counter
009FDE    206296        jsr     0x9662                            ; Add 1 to value at address in X
009FE1    C904          cmp     al, #0x04                        ; Compare to TPS error trigger level
009FE3    9004          bcc     0x9fe9                             ; If less goto 9fe9
009FE5    0C2E1010      seb     #0x10, 0x102e              ; Set TPS error flag
009FE9    60            rts                                               ; exit

009FEA    9C871100      ldm     #0x00, 0x1187               ; Set TPS error counter to zero
009FEE    1C2E1010      clb     #0x10, 0x102e               ; Clear TPS error flag
009FF2    1C381120      clb     #0x20, 0x1138
009FF6    60            rts                                                ; exit

So we have found the TPS reading at 103C but it is a 16bit value so we need to find an 8bit equivalent.

findstr 103c Sub-*
Sub-9FC8.txt:009FC8    AE3C10        ldx     0x103c
Sub-EFE4.txt:00F01E    42AD3C10      lda     bx, 0x103c
Sub-9662.txt:0098C7    8D3C10        sta     ax, 0x103c
Sub-DF66.txt:00DF66    AE3C10        ldx     0x103c
Sub-DF66.txt:00DFB9    8D3C10        sta     ax, 0x103c
Sub-DF66.txt:00E055    8E3C10        stx     0x103c
Sub-F228.txt:00F251    AE3C10        ldx     0x103c

Subroutine DF66 looks promising:

Code:

00DF6C    342008FC      bbc     #0x08, dp + 0x20, 0xdf6c        ; Read from A/D control register
00DF70    A622          ldx     dp + 0x22                       ; Read from A/D successive approximation register
00DF72    8E6412        stx     0x1264
00DF75    642004        ldm     #0x04, dp + 0x20                ; Write to A/D control register
00DF78    8622          stx     dp + 0x22                       ; Write to A/D successive approximation register
00DF7A    342008FC      bbc     #0x08, dp + 0x20, 0xdf7a        ; Read from A/D control register
00DF7E    D8            clm                                     ; m:0 x:0
00DF7F    A522          lda     ax, dp + 0x22                   ; Read from A/D successive approximation register
00DF81    8D6612        sta     ax, 0x1266
.....
00DFAD    48            pha                                     ; Push value of AX register onto the stack
00DFAE    4A            lsr     ax                              ; Divide AX by 2
00DFAF    4A            lsr     ax                              ; Divide AX by 2
00DFB0    F8            sem                                     
00DFB1    8D2913        sta     al, 0x1329               ; Store low 8 bits of AX at address 0x1329
00DFB4    8D0202        sta     al, 0x0202               ; Store low 8 bits of AX at address 0x0202
00DFB7    D8            clm                                     
00DFB8    68            pla                                       ; Pull value from stack to AX
00DFB9    8D3C10        sta     ax, 0x103c             ; Store 16 bits of AX at address 0x103C

We can see that it does something with an A/D converter. An A/D converter is a hardware device that reads a voltage and converts it to a number. So there is a good chance that the program is reading the TPS voltage.

It pushes the raw number from the A/D converter onto the stack. The stack is an area of memory where the CPU keeps the return addresses when it calls a subroutine. However, the stack can also be used within a subroutine as a sort of scratch pad, provided you remove whatever you put on it before the end of the subroutine.

The number in AX gets divided by 2 twice (ie. divided by 4) and then written as an 8 bit value to addresses 1329 and 0202. We know the RAM runs from address 1000 to 14FF, so I don't know what the 0202 is for. But we have found the address 1329 for the select monitor to use for datalogging.

Next, the program pulls the raw number back from the stack where it stuck it earlier. It writes this number as 16bits to 103C. Our 16bit TPS reading.

I hope you can see that 1329 and 103C are both derived from the A/D converter that reads the TPS voltage and that 1329 is effectively 103C divided by 4.