DSM/ECU

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

DSM/ECU

Contents

General

ECU numbers

EPROM images

Editing notes

E931 disassembly with comments

More decompile

Processor info

Board parts

Chips

ISC drivers

MH6111 Processor

Standalones

AEM

Megasquirt

Speeduino

Link ECU (VR4LINK)

Haltech

Pretty disassembly notes

GENERAL NOTES

CPU

Assembly binary verifications

Ram memory

Comments

Opcodes

Telemark assembler

Fuel injector and coil power transistor control

Timing diagram

Navigation menu

DSM/ECU

General

ECU numbers

EPROM images

Editing notes

E931 disassembly with comments

More decompile

Processor info

Board parts

Chips

ISC drivers

MH6111 Processor

Standalones

AEM

Megasquirt

Speeduino

Link ECU (VR4LINK)

Haltech

Pretty disassembly notes

GENERAL NOTES

CPU

Assembly binary verifications

Ram memory

Comments

Opcodes

Telemark assembler

Fuel injector and coil power transistor control

Timing diagram

Navigation menu

Search