Another hex dump interpretation

[log1call]

Hello Phil, Daniel,
                      I have worked my way through your instructions up to the point where it gets, "interesting".

  I relabeled all the txt files as suggested. I checked where you said and assured myself that the vector interupt hex/files matched as you said, before I renamed them. I will have to get the chip's instruction sheet and have a read of that still. I hadn't realised they had addresses set aside for specific purposes. I know they did it on computer memory but hadn't realised the chips were like that. I think I tried to get the sheet off your site Phil but it wouldn't work for me. I downloaded a pdf but it wouldn't open... said it was corrupted.
 Just now I have attempted to search for the 11 12 13 14 and have run aground. I tried it backwards and forwards and still nothing. I can see them there at the address you suggest but I seem unable to manage a search succesfully! I am getting square eyes now though so think I will have a coffee and another look later.

 Reading to the bottom of that "interesting" bit Phil, I'd have to mention that my ecu is sitting on bench with nothing connected but power and earth so I would expect a lot of fault codes to be stored, not zeros. Hmmm. I bet it is my reading of your posts... I better reread.


 I was also wondering about where you said,

 "Then, open the the Sub-970E-Reset-Vector.txt subroutine, reading through it, you can see that it sets the stack pointer to 47FF. This is most certainly the top of the RAM.

Code:00971A    A2FF47        ldx     #0x47ff
00971D    9A            txs "

 How did you know that? It didn't say it in the dissassemblers notes on the side, I see there is another A2 ldx two rows down; so why is 47ff the beguining?
   
That's been very interesting anyway Phil so thanks for the great step by step instructions and for sharing your knowledge. I'll be back to it later.
                                         Cheers. Brett.

[mrdjc]

Brett, if you look through the "Sta" command and the locations it returns, you will see (in Phils example):
It starts somewhere very close to 0x4000,
and it will more than likely continue up to 0x46## somewhere.
In his Reset-vector file he can find a value 0x47FF, so I think we can safely presume this is the top end of the ram in use for storage.

in my case:
It starts somewhere very close to 0x1000 (0x1008 in fact)
and it continues up to 0x137C as far as I can see.
In my Reset-Vector file I can find a value of 0x14FF, also strangely close to the highest figure I can find.

The second A2 Value you refer to in my case is:

Code:

00978C    A2FF14        ldx     #0x14ff
00978F    9A            txs    
009790    A2FFFF        ldx     #0xffff

Which IF it was the top of the ram. It would basicly be the whole complete memory from 0x1000 onwards! (Cant' get any higher than FFFF!) Looking at it "logically" you hardly see any reference to any location used with "sta" exceed 0x14FF. (I know there are one or two, but the bulk are within the range.) So I'm fairly certain you can draw some sort of conclusion.

Its raining quite hard here and we are expecting Galeforce 9-10's tonight
Cheers,
Daniel.

[b3lha]

Brett, if you look through the "Sta" command and the locations it returns, you will see (in Phils example):
It starts somewhere very close to 0x4000,
and it will more than likely continue up to 0x46## somewhere.
In his Reset-vector file he can find a value 0x47FF, so I think we can safely presume this is the top end of the ram in use for storage.

in my case:
It starts somewhere very close to 0x1000 (0x1008 in fact)
and it continues up to 0x137C as far as I can see.
In my Reset-Vector file I can find a value of 0x14FF, also strangely close to the highest figure I can find.

The second A2 Value you refer to in my case is:

Code:

00978C    A2FF14        ldx     #0x14ff
00978F    9A            txs     
009790    A2FFFF        ldx     #0xffff

Which IF it was the top of the ram. It would basicly be the whole complete memory from 0x1000 onwards! (Cant' get any higher than FFFF!) Looking at it "logically" you hardly see any reference to any location used with "sta" exceed 0x14FF. (I know there are one or two, but the bulk are within the range.) So I'm fairly certain you can draw some sort of conclusion.

Its raining quite hard here and we are expecting Galeforce 9-10's tonight
Cheers,
Daniel.

You are on the right track. But I was in a hurry and didn't explain well. The important instruction here is "TXS". It means transfer "X" to the Stack Pointer. The program says "Load X with 14FF" and then "Transfer X to the Stack Pointer".

Just to explain, the stack is an area of memory where the CPU stores the return address when it calls a subroutine. When it executes a JSR (Jump to Subroutine) instruction, it puts the address of the next instruction at the memory location pointed to by the stack pointer. Then it subtracts 2 from the stack pointer. Then it jumps to the subroutine. At the end of the subroutine, the RTS (return to subroutine) instruction adds 2 to the stack pointer, picks up the return address and jumps to it. So execution resumes from the point following the initial JSR.

Because the stack pointer moves downwards (gets decremented at every call), the normal convention is to place it at the top  of the RAM. By finding the TXS instruction in the reset vector (it must obviously be set before the first JSR occurs), we can find the top of the RAM.

[b3lha]

You guys are doing really well. Assember code is hard to understand even for experienced programmers. Make sure you ask about anything you don't understand because otherwise I won't know what needs to be explained better.

I expect you already figured this out. If so then forgive me for stating the obvious. In the disassembler listing, the first column is the address of the instruction. The second column is the machine code that is being disassembled. Rarely worth looking at. The third column is the instruction and the 4th column is the operands.

Code:

00978C    A2FF14        ldx     #0x14ff

The instruction at 978C is "Load the X register with the value 0x14FF". The "0x" indicates that the following number is hexadecimal. The hash sign indicates to use the value 0x14FF for the operation. This is known as "immediate addressing". If the hash sign was not there (ie. ldx 0x14ff) then it would mean "Load the X register with the data stored at address 0x14FF". This is known as "absolute addressing".

Code:

00978C    A2FF14        ldx     #0x14ff
00978F    9A            txs     
009790    A2FFFF        ldx     #0xffff

[log1call]

Hi Daniel,
             Phils away I think. I have just managed to manage the search in the hex editor... my problem was trying to search from the top upwards. I had to choose to search down.

 I saw you were not sure which addresses it was that Phil was refering to as check code addresses. It is all the more or less concectutive numbers from 00 to about 45 or so, it probably varies from model to model.
 I also found that there is a index light up above the data, when you choose a byte in the hex editor. It helps to count the hex addresses. It's along the top of the actual data and lights up white. It, with the row number are the address. I can't figure how to post a sample from the editor sorry.

[mrdjc]

Brett,
In the editor, hit the "copy as" button (its the clipboard with the Astrix and a blue arrow)
The window should load on the right. If it doesnt, hit "View" at the top and "Reset Configuration"
Then Try again.

In that window you will see:
"Export"
"Raw Text"
"Formatted Values"
"Encoded Data"

Click on the "Formatted Values" one.

Leave elements on "Default"
Columns on "Default"
Type on "Space-seperated Text"
Byte order on "Default"
Tick the box "Addresses"
Leave "Text pane" unticked.

Then hit copy.. and try paste it in here

Cheers,
Daniel.

[log1call]

Hi Phil, you are here.
                           Yes there is progress.
 So Daniel,
               like this... 0000a90b: 11
 
Ha, no, I'll try for more. One moment...
               This then...
0000a8e0: 05 ad d4 41 35 00 f0 a9 ad d3 41 d8 29 ff 00 18
0000a8f0: 69 fb a8 aa f8 b5 00 8d d1 41 60 41 42 43 44 45
0000a90f: 49 51 52 21 22 23 24 31 32 33 35 15 16 17 00 a9
0000a91f: 00 2c 4a 80 01 09 3a 3a 3c 52 80
     No again...
0000a8f0: 69 fb a8 aa f8 b5 00 8d d1 41 60 41 42 43 44 45
0000a900: 49 51 52 21 22 23 24 31 32 33 35 11 12 13 14 15
0000a910: 16 17 00 a9 00 2c 4a 80 01 09 3a 3a 3c 52 80 01
0000a920: 02
 Yes, at last. I think Phil said the codes were from second 41 in the top  row to the first 00 which are(if I am getting it), a8fb to a912.
 

[log1call]

Hi Daniel,
            Did that hex editor copy have what you wanted to see?

   I finaly got the instruction file downloaded so have spent a bit of time today reading through that  and trying to follow Phil's train of thought through this process.
  As with most diagnostic work, the trick seems to be to devise the test that will find or test what you want to know. If we can break it down into the smallest peices possible we are trying to find, then find them one at a time, it's not so hard. Well not when Phil's leading you to them and telling you what to look for anyway.
 
 Phil, in line with this new way of finding addresses you have been showing me, I have been trying to devise the test or thing we should be looking for to find the other few items of data you are still trying to trace for Alex. So far it has not struck me what that would be. I did however find a pdf file which you may like to read, about diagnosis, it had a bit about what criteria must be met for certain trouble codes and data readings with specific figures that we should be reading if using a genuine subaru select monitor. It confirms that the A/F and knock correction should both be zero most of the time.

I can send you the pdf if you would like to have a look. It's about one-hundred and fifty Mbs though!

[seport]

I can send you the pdf if you would like to have a look. It's about one-hundred and fifty Mbs though!

I am interested in having a copy of this file, but I don't know how you are going to send 150MB!
The first option is to tell us from where did you download this file, or may be we can try the Teamviewer remote desktop. You can download it from here http://www.teamviewer.com/index.aspx
I use this very regularly but never to transfer files.

[log1call]

Hi,
    Alex.
    I have just sent you a copy of the manual. It was "only" 8.5Mbs after all. I hope it gets through your e-mail server but if it doesn't let me know and I will see what else we can devise.
    Are you making more sense of those data logs with the, "drive to test a symptom style logs"? They made more sense to me and the readings were more stable after a few seconds of steady speed or throttle.
 Hope it all helps anyway.
                                  Regards, Brett                                                                       

[b3lha]

Right. I think you guys have both found the Check Engine codes now and learned a lot in the process.

Just to recap, here is a snippet of hex from Brett's ECU

Code:

0000A8F0   69 FB A8 AA F8 B5 00 8D D1 41 60 41 42 43 44 45   i........A`ABCDE
0000A900   49 51 52 21 22 23 24 31 32 33 35 11 12 13 14 15   IQR!"#$1235.....
0000A910   16 17 00 A9 00 2C 4A 80 01 09 3A 3A 3C 52 80 01   .....,J...::<R..

The bytes from A8F0 to A8FA are the end of Sub-A891.txt (look at the 2nd column and match it above)

Code:

00A8F0    69FBA8        adc     ax, #0xa8fb
00A8F3    AA            tax
00A8F4    F8            sem                                     ; m:1 x:0
00A8F5    B500          lda     al, dp + 0x00 + ix
00A8F7    8DD141        sta     al, 0x41d1
00A8FA    60            rts

Following the "60" rts instruction at A8FA, we have the CE codes from A8FB up to A912.

Code:

41 42 43 44 45 49 51 52 21 22 23 24 31 32 33 35 11 12 13 14 15 16 17 00

Then we have the next subroutine starting from A913 onwards.

Code:

00A913    A900          lda     al, #0x00                       ; Call target fr00A915    2C4A800109    bbs     #0x01, 0x804a, 0xa923
00A91A    3A            inc     al
00A91B    3A            inc     al
00A91C    3C52800102    bbc     #0x01, 0x8052, 0xa923

[b3lha]

Just for reference, here are a list of the trouble codes I downloaded from the net. It's a generic Subaru list and there are sometimes slight variations. Always best to check against the proper technical manual for the car if possible.

11     Crank angle sensor
12    Starter switch
13    Cam position sensor
14    Fuel injector no. 1
15    Fuel injector no. 2
16    Fuel injector no. 3
17    Fuel injector no. 4
21    Coolant temperature sensor
22    Knock sensor
23    Air flow meter
24    Idle Solenoid
31    Throttle position sensor
32    Oxygen sensor
33    Vehicle speed sensor
35    Canister purge solenoid
38    Engine torque control
41    Air/fuel adaptive control
42    Idle switch
43    Throttle switch
44    Wastegate duty solenoid (turbo)
45    Atmospheric pressure sensor (non-turbo) or Pressure duty solenoid (turbo)
49    CO Resistor
51    Neutral switch
52    Parking brake switch

[b3lha]

So the next step is to see how the ECU's internal error handling maps to these trouble codes. First we find the subroutine that references this error table.

We use the findstr program to search the subroutines for the address A8FB, and it finds Sub-A891.txt.

findstr a8fb sub-*

Sub-A891.txt:00A8F0    69FBA8        adc     ax, #0xa8fb

No surpise. It is the subroutine immediately before the error table. As I said before, Sub-A891 is an error code lookup subroutine. I'm going over this step again because I glossed over it a bit before.

There are two types of errors in the Subaru ECU. Current Errors and Stored Errors. When you do the diagnostics, the ECU flashes one set or the other on the CE light. Which set gets flashed depends on how you connect the diagnosic plugs. Sub-A891 is used for both of these diagnostic procedures, but it is called differently for each.

Lets have a look at how Sub-A891 is called:

findstr a891 Sub-*

Sub-A747.txt:00A7A7    2091A8        jsr     0xa891
Sub-A747.txt:00A803    2091A8        jsr     0xa891
Sub-A747.txt:00A83E    2091A8        jsr     0xa891
Sub-A891.txt:00A8E6    F0A9          beq     0xa891

So Subroutine A891 is called 3 times by Subroutine A747. Open Sub-A747 in notepad and you should find the following.

Code:

00A7A4    A24140        ldx     #0x4041
00A7A7    2091A8        jsr     0xa891

blah blah blah

Code:

00A800    A23944        ldx     #0x4439
00A803    2091A8        jsr     0xa891

blah blah blah

Code:

00A83B    A24140        ldx     #0x4041
00A83E    2091A8        jsr     0xa891

The way this works is that the program sets the X register to point at the location of the internal error flags before it calls Sub-A891. So, to lookup the current error codes, it sets X to the location of the current error flags. To lookup the stored error codes, it sets X to the location of the stored error flags. I don't know why there are two calls with X set to 4041, but it doesn't really matter for what we are doing so I'm not going to investigate that now.

The important thing to realise is that we have found the internal error flags at 4041 and 4439. One set is for current errors and one for stored errors. We can figure out which is which quite simply:

findstr 4041 Sub-*
this produces lots of matches (probably the current errors)
findstr 4439 Sub-*
this produces only a few matches (probably the stored errors)

Now we have to figure out the size of the error flags. In both of the ECUs that we are looking at, there are 24 error codes (including the unused ones set to 00). That's 3x8 so probably there are three bytes of error flags.

This is confirmed by at what Sub-A891 does with the X value passed in;

Code:

00A8AA    B500          lda     al, dp + 0x00 + ix
...
00A8B2    B501          lda     al, dp + 0x01 + ix
...
00A8BA    B502          lda     al, dp + 0x02 + ix

These three lines mean
Load the al register with the value at (address stored in the X register)+0   (ie. load al with the value at 4041)
Load the al register with the value at (address stored in the X register)+1   (ie. load al with the value at 4042)
Load the al register with the value at (address stored in the X register)+2   (ie. load al with the value at 4043)

So that's another indication that the address flags are three bytes long 4041-4043 for the current errors and 4439-443B for the stored errors.

[b3lha]

Reverse engineering Sub-A891 to find the relationship between the internal and external flags is probably too complex for you guys at this stage. (I don't mean that as a insult ). We can go through it later when you understand a bit more about assember code.

The easiest way to figure out the relationship is by unplugging the various sensors one at a time and watching how the values of the internal error flags in 4041 through 4043 change as you do it. But Brett's ECU is on the bench, not in the car, so that option is not possible.

I've run the subroutine in a simulator a few times and posted the results below. The values in 4041-4043 are binary with hex in brackets. You should be able to see that the CE code table follows the bit order. The lowest bit in 4041 represents the first entry in the table and the highest bit in 4043 represents the last entry in the table.

Code:

0000A8F0   .................................41 42 43 44 45
0000A900   49 51 52 21 22 23 24 31 32 33 35 11 12 13 14 15
0000A910   16 17 00 ......................................

4041 4042 4043 CE Code Error 00000001 (01) 00000000 (00) 00000000 (00) 41 AF Control 00000010 (02) 00000000 (00) 00000000 (00) 42 Idle Switch 00000100 (04) 00000000 (00) 00000000 (00) 43 Throttle Switch 00001000 (08) 00000000 (00) 00000000 (00) 44 Wastegate Duty Sol 00010000 (10) 00000000 (00) 00000000 (00) 45 Atmos Presure/Pressure Sol 00100000 (20) 00000000 (00) 00000000 (00) 49 CO Resistor 01000000 (40) 00000000 (00) 00000000 (00) 51 Neutral Switch 10000000 (80) 00000000 (00) 00000000 (00) 52 Parking Switch 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

[mrdjc]

Very interesting... but I'm sure it will take a few reads for me to actually understand it.

You mention unplugging sensors and seeing what happens, how do you go about logging the data "live"?
What program would you use to query 4041 4042 and 4043?

The bit I don't quite understand.. Why are there three different addresses? Do they all three need to have values in them before the error is shown? Or is this so up to three codes can be shown at one given time?

So for example if I had:

Code:

   4041               4042             4043         
00000001 (01) 00001000 (08)     00000010 (02)

Would that mean I have the following CURRENT errors?:
AF Control 41
Idle Solenoid 24
Starter Motor 12

I don't quite see the relationship between the three addresses and the error codes.
Why can't it store all the current codes only in 4041?
Making use of the full hex range rather than 1,2,4,8,10,20,40,80? Is there some kind of logic I'm not seeing?

Cheers,
Daniel.