DSM/ECU/Pretty disassembly notes: Difference between revisions

From Jane Hacker Wiki
Jump to navigation Jump to search
Created page with "Test"
 
No edit summary
Line 1: Line 1:
Test
==Pretty disassembly notes==
 
===GENERAL NOTES===
Project started with the help of dsm-ecu Yahoo group, thanks for the great info.
Most disassembly comments in this file by Christian, [email protected]
 
===CPU===
The microcomputer chip used in the 1G DSM ECU seems to be a custom application built around the <code>6801</code> architecture, Check the <code>6801, 6803, 6301, 68HC11</code> at web sites such as alldatasheet.com, etc. 
 
CPU clock frequency is assumed to be <code>2MHz</code>, i.e. the instructions cycle time is <code>0.5us</code>.
 
===Assembly binary verifications===
The 2 binaries produced without any customization ("<code>enableCustom</code>" definition is commented-out) have been verified to be identical to the <code>E931</code> and <code>E932</code> eprom images at hand.
 
To check the validity of symbolic substitution, the entire code section and tables 
was offset by <code>$0200</code> using "<code>codeOffset</code>" and the corresponding binary was tested on
my car (<code>E932</code>) without any problems for weeks. Additional tests were conducted by
writing inline code in several part of the code and no adverse effect was ever noted.
 
To check the validity of symbolic substitution for ram addresses, every ram location
starting at <code>$0057</code> was offset by 1 (i.e. <code>temp1</code> was at memory address <code>$58</code> instead of <code>$57</code>, etc) and the corresponding binary was tested on my car (<code>E932</code>) without any problems during car startup and engine revving. No additional test performed.
 
This means that the code can be modified inline and in most cases, ram memories can 
be moved around by changing the label addresses. Note however that some groups of
ram memories have to be moved in blocks because the code assumes they are contiguous.
e.g. the <code>temp1</code> to <code>temp9</code> variables, the <code>inj1_offT</code>, <code>inj3_offT</code>, <code>inj4_offT</code> and <code>inj2_offT</code> variables, etc.
 
===Ram memory===
Memory from <code>$0040</code> to <code>$01bf</code> is backed-up by battery, meaning it is preserved when the ECU is powered-off as long as battery power is supplied. However, memory from <code>$0057</code> to <code>$0190</code> is cleared to <code>0</code> by the code every time the ECU is powered-on. That can be however changed by modifying the code... Battery backup was checked by disabling memory reset using the <code>"noRamReset"</code> and then check ram memory at <code>$018f</code> to see if it gets preserved after power off/on cycle, and it did. During the test, <code>$018f</code> was used as a distance counter using the reed switch.
 
===Comments===
Some comments use variable names quite loosly. For instance, multi-byte variables such as <code>[airCnt0:airCnt1:airCnt2]</code> might be refered to as only <code>airCnt0</code>. <code>airCnt0</code> might therefore refer to the single byte <code>airCnt0</code>, to the 16 bit value <code>[airCnt0:airCnt1]</code> or to the 24 bit complete variable, depending on the context.
 
Comments were added incrementally as my knowledge of code and variables increased. As new knowledge was learned, old comments were updated or corrected as much as possible but not necessarily all of them, so beware... In the end, the code is the only truth... Some small areas of the code were also never completly understood as a general understanding was reached and I did not care to go further e.g. airflow sensor active filter reset.
 
===Opcodes===
 
* <code>cmpd</code>: cmpd1 is used for some addressing modes instead of cmpd since TASM does not support unusual mitsubishi ECU cmpd opcodes..   
* <code>brclr</code>: branch if ALL the given bits are clear
* <code>brset</code>: branch if ANY of the given bits are set (as opposed to usual implementation of ALL bits set...)
* The addressing mode using <code>Y</code> indexing also implicitly modifies the <code>y</code> register. It seems that <code>y</code> is increased by 1 or 2 depending whether the instruction is a 8 bit or 16 bits operation... The following cases are confirmed:
 
<pre>
cmpa $00,y  -> y = y + 1 
cmpb $00,y  -> y = y + 1 
ldaa $00,y  -> y = y + 1
suba $00,y  -> y = y + 1
ldx  $00,y  -> y = y + 2
std  $00,y  -> y = y + 2
</pre>
 
===Telemark assembler===
This assembler does not provide warning messages when code assembles to the same memory space, e.g. you insert code in the middle of the file which result in the rest of the code to be offset by <code>N bytes</code>. This results in the interrupt vector table to be overwritten. No warning is given. The only way to know about it is to manually check the listing file produced by the assembler. Check that the buffer space between sections is all <code>"$ff"</code>. Check that there is no code spilage over <code>.org</code> statements. Check that the address space does not exceed <code>$ffff</code>. Use the <code>"codeOffset"</code> at the beginnng of the file to correct the problem.
 
===Fuel injector and coil power transistor control===
Although the 4 fuel injectors and the 2 coil power transistors are mapped to regular ports (<code>port1, port2 and port5</code>) which can be read to know the current state of these outputs, they are also mapped in hardware to output compare registers in order to activate or deactivate them at specific time instants. Writing to the ports might therefore not work unless the output compare configuration registers are changed to disable harware control of these outputs. This might not be possible unless an <code>"output enable"</code> bit exists, which I haven't found at this point...
Another way to activate or deactivate them would be to use the <code>output compare registers</code> (as currently done by the ECU code) and provoke an immediat output change.
 
Here is my current understanding of how injector scheduling works, not everything is clear to me so don't take this as gospel...:
 
The output compare registers for the fuel injectors seem to be at least double buffered and maybe triple buffered (see <code>schedInjSim</code> routine). That means that up to 3 different output compare values can be written to <code>t1_outCmpWr</code> and <code>t2_outCmpWr</code> to activate or deactivate the injectors at those time instants. Each time a value is written to <code>t1_outCmpWr</code> or <code>t2_outCmpWr</code>, the corresponding injector state is also internally stored. That means that to activate injector #1 at time <code>X</code>, you would first reset bit 0 of t1_csr, corresponding to injector #1 and then write <code>X</code> to <code>t1_outCmpWr</code>. You could then immediately schedule the deactivation of injector #1 by setting bit 0 of <code>t1_csr</code> to 1 and then write the deactivation time to <code>t1_outCmpWr</code>. When one of the output compare register stored value matches the clock at <code>t1t2_clk</code>, the injector is activated/deactivated and the corresponding interrupt routine is called (if the interrupt mask is clear...) at <code>outCompInt1</code> or <code>outCompInt2</code>.
 
Here is my current understanding of how the coil power transistor scheduling works, not everything is clear to me so don't take this as gospel...:
 
<code>t3_outCmpWr</code> is the output compare register used to activate or deactivate the coil power transistors (energize the coil and provoke ignition at the specified time instants) To energize the coil for cylinder 1 and 4 at time <code>X</code> you would write <code>X</code> to <code>t3_outCmpWr</code> and <code>reset(0)</code> bit 2 of <code>t3_csr0</code>. At time <code>X</code>, <code>t3_csr0.2</code> would be loaded into <code>port5.1</code> which would energize the coil. <code>t3_csr0.2</code> should not be changed until that happens.
In the code, most of the time 2 successive values (the same one) are written to <code>t3_outCmpWr</code> but there are some instances where only 1 value is written. My impression is that the first value serves to activate/deactivate the coil power transistor at the specified instant while the second one only serves to generate an interrupt in order to call the <code>outCompInt3</code> routine. Hence when only the coil need to be activated/deactivated without calling <code>outCompInt3</code>, you would only write one value. If in addition you want to have outCompInt3 called when the coil is energized/ignited, you would write two successive values (corresponding to the same time...). This is all speculation of course... As for the 2 clocks at <code>t3_clock1</code> and <code>t3_clock1</code>, I assume they are connected to the same internal clock at <code>250KHz</code> but might be input capture registers latched when one of the two output compare at <code>t3_outCmpWr</code> is triggered??????? Again speculation, this is the part of the code I understand the least...
 
===Timing diagram===
* <code>4 cylinders = 2 rotations = 2 * 360degrees = 720 degrees</code>
* For sequential injection, fuel injection starts on the cas falling edge 
** i.e. cylinder #1 injection starts at <code>-5 BTDC</code> of <code>#3 TDC</code>
* Simultaneous injection of all 4 injectors is performed when starting to crank or starting a cold engine or during acceleration, check the tech manual and code for more details. Simultaneous injection starts on the <code>5deg BTDC</code> cas signal except in the case of acceleration where it starts when an injector is deactivated and no other injector is active (i.e. at the beginning of the time period where no injector is active)
* Coil energization is usually scheduled (the energization time is loaded into the output compare register, energization will occur at the specified time) from the cas rising edge. Coil ignition can be scheduled when energization occurs (output compare interrupt) or on the cas falling edge depending on  the desired timing. Note however that coil energization can also be scheduled when ignition occurs on the preceeding cylinder. This would correspond to scheduling ignition before the cas rising edge (at high rpm I assume). Coil energization can also be scheduled on the cas falling edge when the desired timing is high (e.g. <code>10deg ATDC</code>). As this shows, there are several combinations and the complexity of the code to handle the coil reflects that fact.
 
<pre style="white-space: pre;">   
                        No 1 TDC         No 3 TDC          No 4 TDC          No 2 TDC
                           :                 :                 :                 :
                  ___________                         _____ 
TDC sensor       |           |                       |     |
signal           |         : |               :       |     |   :                 :
             ____|___________|_______________________|_____|________________________
degrees         85           55                      85   15
(BTDC/ATDC)                :                 :                 :                 :
                   ______            ______            ______            ______ 
CAS sensor        |      |          |      |          |      |          |      |
signal            |      | :        |      | :        |      | :        |      | :
             _____|______|__________|______|__________|______|__________|______|____
degrees           75     5 :       75      5 :       75      5 :        75     5 :
(BTDC)                     :                 :                 :                 :          
                           :                 :                 :                 : 
No 1 cyl.      compression :   combustion    :    exhaust      :     intake      : compression
No 3 cyl.        intake    :   compression   :   combustion    :     exhaust     :  intake     
No 4 cyl.        exhaust   :     intake      :   compression   :    combustion   :  exhaust    
No 2 cyl.      combustion  :     exhaust     :    intake       :    compression  : combustion
</pre>
 
===Airflow calculations dependencies, more details in code===

Revision as of 16:56, 1 May 2021

Pretty disassembly notes

GENERAL NOTES

Project started with the help of dsm-ecu Yahoo group, thanks for the great info. Most disassembly comments in this file by Christian, [email protected]

CPU

The microcomputer chip used in the 1G DSM ECU seems to be a custom application built around the 6801 architecture, Check the 6801, 6803, 6301, 68HC11 at web sites such as alldatasheet.com, etc. 

CPU clock frequency is assumed to be 2MHz, i.e. the instructions cycle time is 0.5us.

Assembly binary verifications

The 2 binaries produced without any customization ("enableCustom" definition is commented-out) have been verified to be identical to the E931 and E932 eprom images at hand.

To check the validity of symbolic substitution, the entire code section and tables  was offset by $0200 using "codeOffset" and the corresponding binary was tested on my car (E932) without any problems for weeks. Additional tests were conducted by writing inline code in several part of the code and no adverse effect was ever noted.

To check the validity of symbolic substitution for ram addresses, every ram location starting at $0057 was offset by 1 (i.e. temp1 was at memory address $58 instead of $57, etc) and the corresponding binary was tested on my car (E932) without any problems during car startup and engine revving. No additional test performed.

This means that the code can be modified inline and in most cases, ram memories can  be moved around by changing the label addresses. Note however that some groups of ram memories have to be moved in blocks because the code assumes they are contiguous. e.g. the temp1 to temp9 variables, the inj1_offT, inj3_offT, inj4_offT and inj2_offT variables, etc.

Ram memory

Memory from $0040 to $01bf is backed-up by battery, meaning it is preserved when the ECU is powered-off as long as battery power is supplied. However, memory from $0057 to $0190 is cleared to 0 by the code every time the ECU is powered-on. That can be however changed by modifying the code... Battery backup was checked by disabling memory reset using the "noRamReset" and then check ram memory at $018f to see if it gets preserved after power off/on cycle, and it did. During the test, $018f was used as a distance counter using the reed switch.

Comments

Some comments use variable names quite loosly. For instance, multi-byte variables such as [airCnt0:airCnt1:airCnt2] might be refered to as only airCnt0. airCnt0 might therefore refer to the single byte airCnt0, to the 16 bit value [airCnt0:airCnt1] or to the 24 bit complete variable, depending on the context.

Comments were added incrementally as my knowledge of code and variables increased. As new knowledge was learned, old comments were updated or corrected as much as possible but not necessarily all of them, so beware... In the end, the code is the only truth... Some small areas of the code were also never completly understood as a general understanding was reached and I did not care to go further e.g. airflow sensor active filter reset.

Opcodes

  • cmpd: cmpd1 is used for some addressing modes instead of cmpd since TASM does not support unusual mitsubishi ECU cmpd opcodes..   
  • brclr: branch if ALL the given bits are clear
  • brset: branch if ANY of the given bits are set (as opposed to usual implementation of ALL bits set...)
  • The addressing mode using Y indexing also implicitly modifies the y register. It seems that y is increased by 1 or 2 depending whether the instruction is a 8 bit or 16 bits operation... The following cases are confirmed:
cmpa $00,y  -> y = y + 1 
cmpb $00,y  -> y = y + 1 
ldaa $00,y  -> y = y + 1
suba $00,y  -> y = y + 1
ldx  $00,y  -> y = y + 2
std  $00,y  -> y = y + 2

Telemark assembler

This assembler does not provide warning messages when code assembles to the same memory space, e.g. you insert code in the middle of the file which result in the rest of the code to be offset by N bytes. This results in the interrupt vector table to be overwritten. No warning is given. The only way to know about it is to manually check the listing file produced by the assembler. Check that the buffer space between sections is all "$ff". Check that there is no code spilage over .org statements. Check that the address space does not exceed $ffff. Use the "codeOffset" at the beginnng of the file to correct the problem.

Fuel injector and coil power transistor control

Although the 4 fuel injectors and the 2 coil power transistors are mapped to regular ports (port1, port2 and port5) which can be read to know the current state of these outputs, they are also mapped in hardware to output compare registers in order to activate or deactivate them at specific time instants. Writing to the ports might therefore not work unless the output compare configuration registers are changed to disable harware control of these outputs. This might not be possible unless an "output enable" bit exists, which I haven't found at this point... Another way to activate or deactivate them would be to use the output compare registers (as currently done by the ECU code) and provoke an immediat output change.

Here is my current understanding of how injector scheduling works, not everything is clear to me so don't take this as gospel...:

The output compare registers for the fuel injectors seem to be at least double buffered and maybe triple buffered (see schedInjSim routine). That means that up to 3 different output compare values can be written to t1_outCmpWr and t2_outCmpWr to activate or deactivate the injectors at those time instants. Each time a value is written to t1_outCmpWr or t2_outCmpWr, the corresponding injector state is also internally stored. That means that to activate injector #1 at time X, you would first reset bit 0 of t1_csr, corresponding to injector #1 and then write X to t1_outCmpWr. You could then immediately schedule the deactivation of injector #1 by setting bit 0 of t1_csr to 1 and then write the deactivation time to t1_outCmpWr. When one of the output compare register stored value matches the clock at t1t2_clk, the injector is activated/deactivated and the corresponding interrupt routine is called (if the interrupt mask is clear...) at outCompInt1 or outCompInt2.

Here is my current understanding of how the coil power transistor scheduling works, not everything is clear to me so don't take this as gospel...:

t3_outCmpWr is the output compare register used to activate or deactivate the coil power transistors (energize the coil and provoke ignition at the specified time instants) To energize the coil for cylinder 1 and 4 at time X you would write X to t3_outCmpWr and reset(0) bit 2 of t3_csr0. At time X, t3_csr0.2 would be loaded into port5.1 which would energize the coil. t3_csr0.2 should not be changed until that happens. In the code, most of the time 2 successive values (the same one) are written to t3_outCmpWr but there are some instances where only 1 value is written. My impression is that the first value serves to activate/deactivate the coil power transistor at the specified instant while the second one only serves to generate an interrupt in order to call the outCompInt3 routine. Hence when only the coil need to be activated/deactivated without calling outCompInt3, you would only write one value. If in addition you want to have outCompInt3 called when the coil is energized/ignited, you would write two successive values (corresponding to the same time...). This is all speculation of course... As for the 2 clocks at t3_clock1 and t3_clock1, I assume they are connected to the same internal clock at 250KHz but might be input capture registers latched when one of the two output compare at t3_outCmpWr is triggered??????? Again speculation, this is the part of the code I understand the least...

Timing diagram

  • 4 cylinders = 2 rotations = 2 * 360degrees = 720 degrees
  • For sequential injection, fuel injection starts on the cas falling edge 
    • i.e. cylinder #1 injection starts at -5 BTDC of #3 TDC
  • Simultaneous injection of all 4 injectors is performed when starting to crank or starting a cold engine or during acceleration, check the tech manual and code for more details. Simultaneous injection starts on the 5deg BTDC cas signal except in the case of acceleration where it starts when an injector is deactivated and no other injector is active (i.e. at the beginning of the time period where no injector is active)
  • Coil energization is usually scheduled (the energization time is loaded into the output compare register, energization will occur at the specified time) from the cas rising edge. Coil ignition can be scheduled when energization occurs (output compare interrupt) or on the cas falling edge depending on  the desired timing. Note however that coil energization can also be scheduled when ignition occurs on the preceeding cylinder. This would correspond to scheduling ignition before the cas rising edge (at high rpm I assume). Coil energization can also be scheduled on the cas falling edge when the desired timing is high (e.g. 10deg ATDC). As this shows, there are several combinations and the complexity of the code to handle the coil reflects that fact.
   
                        No 1 TDC         No 3 TDC          No 4 TDC          No 2 TDC
                           :                 :                 :                 :
                  ___________                         _____ 
TDC sensor       |           |                       |     |
signal           |         : |               :       |     |   :                 :
             ____|___________|_______________________|_____|________________________
degrees         85           55                      85   15
(BTDC/ATDC)                :                 :                 :                 :
                   ______            ______            ______            ______ 
CAS sensor        |      |          |      |          |      |          |      |
signal            |      | :        |      | :        |      | :        |      | :
             _____|______|__________|______|__________|______|__________|______|____
degrees           75     5 :       75      5 :       75      5 :        75     5 :
(BTDC)                     :                 :                 :                 :          
                           :                 :                 :                 : 
No 1 cyl.      compression :   combustion    :    exhaust      :     intake      : compression
No 3 cyl.        intake    :   compression   :   combustion    :     exhaust     :  intake     
No 4 cyl.        exhaust   :     intake      :   compression   :    combustion   :  exhaust    
No 2 cyl.      combustion  :     exhaust     :    intake       :    compression  : combustion

Airflow calculations dependencies, more details in code