DSM/ECU/Pretty disassembly notes: Difference between revisions
Created page with "Test" |
No edit summary |
||
Line 1: | Line 1: | ||
==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 clearbrset
: 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 they
register. It seems thaty
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
- i.e. cylinder #1 injection starts at
- 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