Another hex dump interpretation

[b3lha]

Now lets look for the code that sets an error. We'll start with an easy one, the TPS.

From the table in the previous post, you can see that the TPS error flag is bit 4 of 4042. We count bit numbers from right to left, starting at zero.

00000000 (00)   00010000 (10)   00000000 (00)   31   Throttle Sensor

To find the subroutine that sets this flag do the following:

findstr 4042 Sub-*

This gives a list of all the subroutines that access address 4042. Somewhere in the list you will find:

Sub-9E69.txt:009E8A    0C424010      seb     #0x10, 0x4042
Sub-9E69.txt:009E93    1C424010      clb     #0x10, 0x4042

The "seb" instruction means SEt Bits (to 1). the "clb" instruction means CLear Bits (to 0). The #0x10 is the hex code for the TPS error bit in the table. So we have found that subroutine 9E69 turns the TPS error flag on and off. The location for the TPS parameter will probably be somewhere in that subroutine.

Code:

009E69    D8            clm                                     ; m:0 x:0, Calltarget from 9CF9
009E6A    A90004        lda     ax, #0x0400
009E6D    38            sec
009E6E    ED5140        sbc     ax, 0x4051
009E71    AA            tax
009E72    F8            sem                                     ; m:1 x:0

This says:
- load the AX register with the value 400 hex
- subtract the 16bit value stored at 4051 from the AX register
- transfer the AX register to the X register.

This is probably the TPS signal. The A/D converter in the ECU probably reads the TPS voltage as a number between 0 (being 0 volts) and 0x400 (being 5 volts). I remember you saying that your TPS works backwards to normal, so that is probably why it is subtracting from 0x400.

Code:

009E73    EC9C8C        cpx     0x8c9c
009E76    F007          beq     0x9e7f
009E78    9005          bcc     0x9e7f

- Compare the X register to the value at 8C9C (using the hex editor you can see this is 0x2889)
- If "equal" then branch to 9E7F
- if "less than" then branch to 9E7F

Code:

009E7A    EC9E8C        cpx     0x8c9e
009E7D    9010          bcc     0x9e8f

- Compare the X register to the value at 8C9E (using the hex editor you can see this is 0x8578)
- If "less then" then branch to 9E7D

The TPS signal is being compared against a lower and upper limit. If it falls inside these limits, then the program branches to 9E8F.

Code:

009E8F    9CB24100      ldm     #0x00, 0x41b2                   ; Branch targetfrom 9E7D
009E93    1C424010      clb     #0x10, 0x4042
009E97    60            rts

This clears the error flag and exits.

However, if the signal falls outside the limits then the following happens:

Code:

009E7F    A2B241        ldx     #0x41b2                         ; Branch targetfrom 9E76, Branch target from 9E78
009E82    20DFA3        jsr     0xa3df
009E85    CDA08C        cmp     al, 0x8ca0
009E88    9004          bcc     0x9e8e
009E8A    0C424010      seb     #0x10, 0x4042
009E8E    60            rts                                     ; Branch targetfrom 9E88

I have decoded the subroutine at A3DF. It basically says "add 1 to the memory address pointed at by the X register and load it into the al register". So the variable at 41B2 is an error counter. Every time the TPS signal falls outside the limits, it adds one to the counter. When the counter is less than the value at 8CA0 (this is 04) it branches to 9E8E and exits. But when the counter exceeds 4, the TPS error bit gets set.

To summarize, the TPS signal is a 16bit value stored at 4051. The TPS check engine code will be set when the TPS signal falls outside the valid range for more than 4 consecutive cycles of the program.

In this case, we didn't get lucky. We know the TPS signal is at 4051, but this is a 16bit value and the select monitor values are all 8bit. So now we need to look where the value in 4051 comes from.

findstr 4051 Sub-*
Sub-EFAE.txt:00EFE6    EC5140        cpx     0x4051
Sub-A06A.txt:00A094    ED5140        sbc     ax, 0x4051
Sub-F170.txt:00F175    AE5140        ldx     0x4051
Sub-9E69.txt:009E6E    ED5140        sbc     ax, 0x4051
Sub-DFEA.txt:00DFEA    AE5140        ldx     0x4051
Sub-DFEA.txt:00E042    8D5140        sta     ax, 0x4051
Sub-DFEA.txt:00E0EC    8E5140        stx     0x4051

The interesting one here is Sub-DFEA because it contains "store" commands: sta,stx

Code:

00DFF0    342008FC      bbc     #0x08, dp + 0x20, 0xdff0        ; Read from A/D control register
00DFF4    A622          ldx     dp + 0x22                       ; Read from A/D successive approximation register
00DFF6    8EC142        stx     0x42c1
00DFF9    642004        ldm     #0x04, dp + 0x20         ; Write to A/D control register
00DFFC    8622          stx     dp + 0x22                       ; Write to A/D successive approximation register
00DFFE    342008FC      bbc     #0x08, dp + 0x20, 0xdffe        ; Read from A/D control register
00E002    D8            clm                                     ; m:0 x:0
00E003    A522          lda     ax, dp + 0x22                   ; Read from A/Dsuccessive approximation register
blah blah blah

From the disassembler comments we can see that this subroutine is reading from an A/D converter. We don't need to worry too much about how it works.

Code:

00E031    48            pha
00E032    4A            lsr     ax
00E033    4A            lsr     ax
00E034    F8            sem                                     ; m:1 x:0
00E035    8D8447        sta     al, 0x4784
00E038    D8            clm                                     ; m:0 x:0

The value from the A/D converter gets shifted right by 2 digits. In binary terms, that means divided by 4. So instead of a number from 0 to 400. We get a value from 0 to 100, that fits nicely into a single byte and gets stored at 4784.

Code:

00E039    68            pla
00E03A    38            sec
00E03B    E90004        sbc     ax, #0x0400
00E03E    49FFFF        eor     ax, #0xffff
00E041    3A            inc     ax
00E042    8D5140        sta     ax, 0x4051

The same original value gets processed in some way and written to 4051. At this stage it is not important to understand what math is done on it. The important thing to see is that 4784 and 4051 are both derived from the A/D converter that reads the TPS signal.

4784 is an 8 bit value and is probably the one that the select monitor uses.

We found our first parameter.

[b3lha]

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

Yes. That is correct. Each of the 24 bits represents a specific error code.

You can also have several bits set in the same byte, for example

4041                 4042                      4043
00000000 (00)    00001010 (0A)        00000000 (00)

That would indicate Idle Solenoid (08) and knock sensor (02).

The 24 bits contain all the errors detected, even though the ECU only flashes three errors on the CE light. You could in theory have all 24 errors set at the same time: 11111111 (FF)     11111111 (FF)      11111111 (FF)

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?

You can use the hex com tool. Send 78404100 to log address 4041. (Obviously you need to change the address for your ECU. 4041 is the address from Brett's ECU)

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?

Each byte only has 8 bits. So for 23 possible error codes, we need three bytes. 4041 to 4043.
4041 represents codes 41,42,43,44,45,49,51,52
4042 represents codes 21,22,23,24,31,32,33,35
4043 represents codes 11,12,13,14,15,16,17

Does that make sense?

[mrdjc]

Ok it makes sense now!

The other thing I was going to ask..

See how we added 32K of data to the start of our bin file, doesn't that mean we have moved all the addresses in the bin file up?

Or did it always start at 00008001? and Ignore the 32K of blanks which don't even exist?
I was going to say, if we removed the 32K, wouldn't that move the current 00008001 and shift it to 00000001?

I'm just a bit confused...  Especially now you mentioned SSM is 8 bit and not 16!
Does that mean the program is written in 16bit, as well as requiring 16 bit space, but only utilizing 8bits for monitoring purposes?

I'm guessing It will take me a fair old while to actually come to grasp with what you are saying.. I think some flow charts are in order  

Cheers,
Daniel.

Oh! I was also going to ask, where can I find a list with all the instructions commands? cpx, clm, sta, sec, inc etc etc etc. Trying to come to terms with what the lines of code actually do. I think I'd print a list out and stick it next to my monitor for reference.

[b3lha]

Ok it makes sense now!

Good.

The other thing I was going to ask..

See how we added 32K of data to the start of our bin file, doesn't that mean we have moved all the addresses in the bin file up?

Or did it always start at 00008001? and Ignore the 32K of blanks which don't even exist?
I was going to say, if we removed the 32K, wouldn't that move the current 00008001 and shift it to 00000001?

Yes. The rom is from address 8000-FFFF in the ecu memory. The polaris software downloads it to a 32K file. In the file the addresses are 0000-7FFF. So we add the 32K of junk at the start to shunt the rom data up to its correct position.

I'm just a bit confused...  Especially now you mentioned SSM is 8 bit and not 16!
Does that mean the program is written in 16bit, as well as requiring 16 bit space, but only utilizing 8bits for monitoring purposes?

The program uses some 16 bit values and some 8 bit values depending on what it needs. The SSM protocol can only query 8 bit values for monitoring. In some cases, the program will use 16 bit values for calculations, but keep an 8 bit copy for the select monitor.

Oh! I was also going to ask, where can I find a list with all the instructions commands? cpx, clm, sta, sec, inc etc etc etc. Trying to come to terms with what the lines of code actually do. I think I'd print a list out and stick it next to my monitor for reference.

Go to my website, click on "Description" under ECU is the blue column on the left. Scroll down to the bottom of the page and download "7700 family software manual".

[b3lha]

The A/D converter in the ECU probably reads the TPS voltage as a number between 0 (being 0 volts) and 0x400 (being 5 volts). I remember you saying that your TPS works backwards to normal, so that is probably why it is subtracting from 0x400.
...
Compare the X register to the value at 8C9C (using the hex editor you can see this is 0x2889)
...
Compare the X register to the value at 8C9E (using the hex editor you can see this is 0x8578)

I just realised this doesn't make sense: Subtracting a number from 0x400 and then checking the result is between 0x2889 and 0x8578. Unless of course the value at 4051 is stored as a negative number. I don't quite understand the code at E03A where this number is calculated. I mean I understand what it does but I don't understand why it does it.

I am sure that 4051 contains the TPS voltage, encoded somehow. The program is comparing the TPS signal to an upper and lower limit and setting the error flag if it is out of range for 5 consecutive cycles.

It doesn't really matter how the voltage is encoded into the value at 4051, I am confident that we have found the TPS parameter at 4784.

[log1call]

Whoo,
         that's going to take some time to digest Phil.
  I am struggling with the binary to hex conversions and understanding how the error codes fit into the binary numbers. I will reread it again... and again.
 
Then there is the bigger picture of how you decide/know which command is doing what... and why. I have got the instruction set and have done as Daniel suggests and have them next to me with all the abbreviated codes showing on four pieces of paper.
 
 There are more trouble codes Phil, they jump some but they can go up to ninety-odd. There are also other things that the ssm can read which set leds going, like the idle switch on the TPS for instance. I guess they are what you call flags, or is it switches?

 I was wondering if the extra registers of trouble codes are because some codes get logged at the first instance and some not till a few faults have occured? So they would keep a tally of any trouble codes stored until they reach the trigger level? Then they might set the trouble light and just keep one copy of the code? Just guessing.
 
 Another thing that has been puzzling me Phil is how you are calculating A/F and load and perhaps Ign Correction if the car has it. I had always understood that the A/F is a correction to the base fuel map. If the A/F gets too large then the base map gets adjusted to bring the A/F back to zero. That's the mechanism by which they "learn" and  compensate for wear and bad adjustments of valves etc. This is a common practice for most modern cars. I saw in a diagnostic manual the other day that subarus use this mechanism too.
 I know that the A/F correction in my ecu behaves correctly(after taking away 128), when read from 43ce. I found that address by studying it's behaviour. Who knows what it really is. Could we trace that backwards and see if it is the place you would expect the A/F correction to be from the software?
  I am going back to reading and following through the previous postings. If I can aunderstand it I will attempt to find everything that writes to 43ce and then work backwards ticking them all off a list if there are not too many. I'll look in each of them and see if I can find the place where they post to the 43ce address and then try to see what it is they are writing. To do that I have to start thinking like a programmer. Hmmm. I suppose I could try and sift the first search for subs that access the areas where the maps are? Hmmm.
  I better go read and learn to think Bin/hex.
                                                  Cheers, Brett.

[log1call]

Oh, Phil...
              4784 is correct for tpi.
 Sorry, forgot to mention that. Shoud also mention that the 703315 ecu is a spare for a car of mine, if you want to test anything on a running vehicle I can do that.
                                                                        Cheers, Brett.

[b3lha]

Whoo,
         that's going to take some time to digest Phil.
  I am struggling with the binary to hex conversions and understanding how the error codes fit into the binary numbers. I will reread it again... and again.
 
Then there is the bigger picture of how you decide/know which command is doing what... and why. I have got the instruction set and have done as Daniel suggests and have them next to me with all the abbreviated codes showing on four pieces of paper.

I've been looking for an assember tutorial to post here, but all of the ones on the net seem to deal with PC assember (intel 8086) and they assume that you are assembling code, not disassembling it. The principles are the same but the CPU chip is quite different to what we are working with here and I think it might confuse matters. I'll try and type up some introductory stuff for you guys.

There are more trouble codes Phil, they jump some but they can go up to ninety-odd. There are also other things that the ssm can read which set leds going, like the idle switch on the TPS for instance. I guess they are what you call flags, or is it switches?

Yes, there are more codes. But your ECU only supports the ones that you found in the table at A8FB. You will never get any other code out of it. You are right about the select monitor being able to read things that are not related to trouble codes, but they are harder to find. I thought we should do the easy stuff first. Flags and switches are the same thing. Usually, the ECU uses a single bit to represent a switch being "on" or "off" (programmers normally say "true" or "false"). That way they can store 8 switches in 1 byte of memory. That's what these internal error flags are. Each of the 24 bits is a switch representing a specific error code. The switch is on to signal the error, otherwise it is off.

I was wondering if the extra registers of trouble codes are because some codes get logged at the first instance and some not till a few faults have occured? So they would keep a tally of any trouble codes stored until they reach the trigger level? Then they might set the trouble light and just keep one copy of the code? Just guessing.
 

All of the trouble codes have their own counter and a trigger level, like in the TPS subroutine we looked at. The error flag gets set when the number of consecutive errors exceeds the trigger level. In the TPS subroutine, every time it gets a bad result it adds one to the TPS error counter. When the number of bad results exceeds the trigger it sets the TPS error flag. If it gets a good result, it sets the TPS error counter back to zero and clears the TPS error flag.

Another thing that has been puzzling me Phil is how you are calculating A/F and load and perhaps Ign Correction if the car has it. I had always understood that the A/F is a correction to the base fuel map. If the A/F gets too large then the base map gets adjusted to bring the A/F back to zero. That's the mechanism by which they "learn" and  compensate for wear and bad adjustments of valves etc. This is a common practice for most modern cars. I saw in a diagnostic manual the other day that subarus use this mechanism too.
 I know that the A/F correction in my ecu behaves correctly(after taking away 128), when read from 43ce. I found that address by studying it's behaviour. Who knows what it really is. Could we trace that backwards and see if it is the place you would expect the A/F correction to be from the software?
  I am going back to reading and following through the previous postings. If I can aunderstand it I will attempt to find everything that writes to 43ce and then work backwards ticking them all off a list if there are not too many. I'll look in each of them and see if I can find the place where they post to the 43ce address and then try to see what it is they are writing. To do that I have to start thinking like a programmer. Hmmm. I suppose I could try and sift the first search for subs that access the areas where the maps are? Hmmm.

We can have a look at that but we need to do easy stuff first. The more parameters we find, the more the code will make sense. If you see a hex address being used in a calculation, it doesn't mean much. If you know that the address holds the "coolant temperature" or "rpm" for example, then it might mean a little more.

[b3lha]

              4784 is correct for tpi.

[b3lha]

Another thing that has been puzzling me Phil is how you are calculating A/F and load and perhaps Ign Correction if the car has it. I had always understood that the A/F is a correction to the base fuel map. If the A/F gets too large then the base map gets adjusted to bring the A/F back to zero. That's the mechanism by which they "learn" and  compensate for wear and bad adjustments of valves etc. This is a common practice for most modern cars. I saw in a diagnostic manual the other day that subarus use this mechanism too.

Sorry to say that I haven't yet figured out the exact mechanism by which the A/F and IGN correction works. However, the "base maps" do not get adjusted. They are in ROM. It is only possible to read them, not change them.

For the A/F, the ECU keeps a table in ram, indexed by rpm and load. The table holds adjustments that get applied to the values read from the base map. The adjustments are calculated using feedback from the O2 sensor.

For the ignition timing, I know that there is a base map and a maximum advance map. From what I have read on the net, there is an "ignition advance multiplier" that holds the percentage of the maximum advance to add on top of the base. This multiplier gets adjusted by the ECU in response to the knock sensor. But they may have been talking about the later Denso ECUs. The mechanism may be different for the JECS units.

[log1call]

Hi Phil,
         that's a fantastic amount of effort you are putting in on behalf of Daniel and myself. Thank you so much!
 
  I have just popped in before starting in the workshop but have got caught up again(as we do).
 I haven't read the refresher course on hex/binary but from rereading here I think I know where I was going wrong... I thought the trouble codes were the binary numbers, now I see that it's just the position of the binary and whether it's set to a one or a zero that matters. And I pressume Phil, that if the trouble code numbers were different they would still just get allocated a space in the bytes nominated, in accordance with relative size, ie, the smallest codes first going up to biggest?

[log1call]

Phil wrote,
[Sorry to say that I haven't yet figured out the exact mechanism by which the A/F and IGN correction works. However, the "base maps" do not get adjusted. They are in ROM. It is only possible to read them, not change them.

For the A/F, the ECU keeps a table in ram, indexed by rpm and load. The table holds adjustments that get applied to the values read from the base map. The adjustments are calculated using feedback from the O2 sensor.
][/quote]   

(Sorry to say I haven't figured out how to do the highlighted quotes yet.)

That would explain how the learnt fuel adjustment gets wiped then when we pull the ecu fuse.
 To form a map though, they would have to do a series of calculations of each point in the map, so they would probably have the entire map in some thrid location would they, where they update it before posting it back in the adjustment factor map? This calculation they do, and the changes to the adjustment map, are only made permanant if the temporary A/F correction is beyond a certain limit... a limit of from -7.5 to +7.5 perhaps?
 

[log1call]

Just read through Daniel's thread too which reminded me of another question Phil.
 
Wouldn't the A/D conversion turn the analouge voltage into a number between zero and two-hundred and fifty-five(I think it is)? This is the throttle position sensor voltage I am talking about.

  Ok, I am late starting work now so must go. Have a good day everybody. Brett.

[b3lha]

Just read through Daniel's thread too which reminded me of another question Phil.
 
Wouldn't the A/D conversion turn the analouge voltage into a number between zero and two-hundred and fifty-five(I think it is)? This is the throttle position sensor voltage I am talking about.

  Ok, I am late starting work now so must go. Have a good day everybody. Brett.

I'm fairly sure the M37791 chip has a 10-bit ADC. So the raw number is between 0 and 1023. But then the program divides it by 4 to get an 8-bit number between 0 and 255 for the select monitor to use.

I like to think of the TPS signal as being a percentage rather than a voltage.

[b3lha]

Hi Phil,
         that's a fantastic amount of effort you are putting in on behalf of Daniel and myself. Thank you so much!
 
  I have just popped in before starting in the workshop but have got caught up again(as we do).
 I haven't read the refresher course on hex/binary but from rereading here I think I know where I was going wrong... I thought the trouble codes were the binary numbers, now I see that it's just the position of the binary and whether it's set to a one or a zero that matters. And I pressume Phil, that if the trouble code numbers were different they would still just get allocated a space in the bytes nominated, in accordance with relative size, ie, the smallest codes first going up to biggest?

Yes. You've got it now. That's how it works.

The codes themselves don't have to be in any particular order (smallest to biggest). The bit position in the bytes at 4041 to 4043 relates to the position in the code table. In other words, 00000001 in 4041 will always return the first code of the table, regardless of what the code number is. Likewise, 10000000 in 4043 will always return the last code in the table.