DSM/ECU/Pretty disassembly notes
Pretty disassembly 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]
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
Assembly binary verifications
The 2 binaries produced without any customization ("
enableCustom" definition is commented-out) have been verified to be identical to the
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
$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.
temp9 variables, the
inj2_offT variables, etc.
$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
$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.
Some comments use variable names quite loosly. For instance, multi-byte variables such as
[airCnt0:airCnt1:airCnt2] might be refered to as only
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.
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
Yindexing also implicitly modifies the
yregister. It seems that
yis 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
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
t2_outCmpWr to activate or deactivate the injectors at those time instants. Each time a value is written to
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
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
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
reset(0) bit 2 of
t3_csr0. At time
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, 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...
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
- 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 BTDCcas 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
masProc: airflow sensor interrupt, increases [airCntNew0:airCntNew1] | by airQuantum for every airflow sensor pulse received | | | |--> [airCntNew0:airCntNew1]: Increased by airQuantum for every airflow sensor pulse | Reset and used as input to [airCnt0:airCnt1:airCnt2] | on every cas falling edge, i.e. air is counted twice | per rotation, once for every cylinder cycle... It can | therefore be seen as the air count per cylinder. | |--> [airCnt0:airCnt1:airCnt2]: Filtered version of 256*[airCntNew0:airCntNew1] | exponential averaging is used. | | | |--> mafraw16: 16 bit airflow sensor pulse frequency (mafraw16/10.24)Hz | | mafraw16 = 8205*[airCnt0:airCnt1]/Tcas | | | | | |--> mafraw: 8 bit airflow sensor pulse frequency (6.25*mafraw)Hz | mafraw: = mafraw16/64 | | | |--> airVol16: Equals [airCnt0:airCnt1] * masScalar/65536 | | | | | | | |--> airVol : Equals airVol16/2 | |--> airVolT : Equals airVol16/2 * iatCompFact/128 | |--> airVolTB : Equals airVol16/2 * iatCompFact/128 * baroFact/128 | |--> airVolB : Equals airVol16/2 * baroFact/128 | | |--> injPw: Injector pulse width in "normal" operation, injPw = [airCnt0:airCnt1] * injFactor/256 + other corrections
Discussion on MAS compensation factors
Total airflow sensor compensation is made-up of:
totMasComp(freq,iat,baro) = masComp + t_masComp(freq) + t_masLin(freq,iat,baro)
maxComp is a fixed offset (
$64 for 1G and
$40 for 2G) and
t_masLin are table values interpolated from frequency, intake air temperature and barometric pressure.
t_masComp(freq) is basically compensation for the airflow sensor charcteristic curve as a function of frequency (to linearize the number of pulse per sec vs. the volume of air passing through the sensor) while
t_masLin(freq,iat,baro) is a smaller factor probably compensating for temperature drift (electronic) and airflow characteristic change as a function of air density???
Assuming the following:
* injComp = 100% (for 260cc injectors at 36psi) * workFtrim = 100% * o2FuelAdj = 100% * iatCompFact = 100% (at 25.6degC) * baroFact = 100% (~1 bar) * openLoopEnr = 100% * coldTempEnr = 100% * enrWarmup = 0%
Then the injector pulswidth is calculated by the ECU as (excluding deadtime)
injPw(usec/cylinder) = numPulsePerCasInterrupts * $9c * totMasComp * 16/256 = numPulsePerCasInterrupts * totMasComp * 9.75
If we also assume a
14.7 air to fuel ratio,
Dair=1.18 air density
Dgas=0.775 fuel density
(g/cc) then we would need
23900 usec of injection per litre of air using the same
260cc at 36psi, working that factor into the equation, we get
injPw(usec/cylinder) = numPulsePerCasInterrupts * totMasComp * 9.75 = numPulsePerCasInterrupts * totMasComp/2452 * 2452 * 9.75 = numPulsePerCasInterrupts * totMasComp/2452 * 23900usecOfInjection/litreOfAir
This means that under the above assumptions,
totMasComp/2452 has units of
2452 is similar to the one provided by J. Oberholtzer, I think.
The exact value must be somewhere in that range...
masScalar is also used for maf compensation (
$5e86,24198 for 1G,
$7A03,31235 for 2g) for controls other than fuel injection. It probably correspond to some metric of the
totMasComp curve (average or max under given conditions). From 1G and 2G numbers, It could correspond to the max of the
masComp + t_masComp(freq) curve multiplied by
0.808*128? It could also correspond to the
masComp + t_masComp(freq) curve sampled at around
69Hz and multiplied by
masScalar = maxTotMasComp*0.808*128 = totMasComp(69Hz)*128
We then have in the case of
masScalar = maxTotMasComp*0.808*128:
airVol16 = numPulsePerCasInterrupts * $9c * masScalar / 65536 = numPulsePerCasInterrupts * $9c * maxTotMasComp*0.808*128 / 65536 = numPulsePerCasInterrupts * maxTotMasComp * 0.2462 = numPulsePerCasInterrupts * maxTotMasComp/2452 * 2452*0.2462 = numPulsePerCasInterrupts * maxTotMasComp/2452 * 603.68
litreOfAirPerAirflowSensorPulse, we have
airVol16 = numPulsePerCasInterrupts * litreOfAirPerAirflowSensorPulse * 603.68
1.18g/litre air density we get
airVol16 = numPulsePerCasInterrupts * litreOfAirPerAirflowSensorPulse *1.18 * 603.68/1.18 = numPulsePerCasInterrupts * gramsOfAirPerAirflowSensorPulse * 512 = gramsOfAirPerCasInterrupts * 512
In that case,
airVol16/512 can be seen has having units of
gramsOfAirPerCasInterrupts (grams of air entering one cylinder). Note that the factor of
512 is not random, the factor
0.808 is used to get it in that case...
The load index values used to interpolate the fuel map is then
airVol16/2 <= 96 loadIndex = (airVol16/2-32)/16 = (gramsOfAirPerCasInterrupts*512/2 -32)/16 = gramsOfAirPerCasInterrupts*16-2 airVol16/2 >= 96 loadIndex = gramsOfAirPerCasInterrupts * 512/2 * 0.668/16 = gramsOfAirPerCasInterrupts*10.69
Which correspond to (
gramsOfAirPerCasInterrupts for each index value)
0 1 2 3 4 5 6 7 8 9 10 11 0.125 0.1875 0.25 0.3125 0.3750 0.4678 0.5614 0.6549 0.7485 0.8421 0.9356 1.0292
gramsOfAirPerRevolution would be twice those values. Notice that the max value of
1.0292 correspond to about
BSFC=0.55 which is in the range of the stock 1G 195HP...
Also notice that the 8 bit airflow
airVol = airVol16/2 will saturate to $ff when
airVol16/2 = 255 which correspond to
gramsOfAirPerCasInterrupts = 1 gram.
airVolT airVolTB and airVolB will also saturate in the same range...
We can now compare these results with the stock boost gauge. It has a max range of
1Kg per sq cm which equals
14.2 psi. The boost gauge duty cycle is given by
bGaugeODuty = t_bGauge(airVolT/32)/24
airVolT = 255 = iatCompFact*airVol16/2, bGaugeODuty = 20/24 = 0.83. At
25.6 degC, iatCompFact = 1.0 and therefore
airVol16=510 which translates to
1g of air. boost gauge duty of
0.83 correspond to approx.
10.9psi (by eye...).
Assuming a displacement of
0.5litre per cylinder and charge air density of
25degC, probably too low for that psi range, unless you have a perfect intercooler..) we would get
1.18*0.5*(10.9+14.5)/14.5 = 1.03g of air per cylinder (cas interrupt). This is quite close to the
1.0g we had earlier.
0psi point on the gauge correspond to a duty cycle of about
40.5% which correspond to
bGaugeODuty=9.75/24 which from
t_bGauge correspond to
airVolT/32=2.875 which means
airVolT = 92. with
iatCompFact = 1.0 @25degC, we get
airVol16 = 2*airVolT/iatCompFact = 184 which correspond to
0.36grams of air Assuming a displacement of
0.5litre per cylinder and charge air density of
[email protected] we would get
1.18*0.5 = 0.59g of air per cylinder (cas interrupt) at
0psi. Compared to
0.36g we had earlier this is a large error but then there are several factor not taken onto
account in the calculations, I suppose???.
Engine coolant and intake air temperature
Approximate sensor curves (temperature against ADC value, taken from MMCD). The control points in the service manual are quite close (0 to 2 degC off).