How to disassemble MSS52 DME dump? help needed please

[alexics]

STT128E- Selling Leads,STT128E- Datasheet ,STT128E- PDF -TheICStock

Scroll all the way down to the bottom of the page past all the blank bit for a brief description of the chip. This site may also allow you to get this 'hidden' data on your other chips.

[alexics]

DPS326718 R7014A Selling Leads,DPS326718 R7014A Datasheet ,DPS326718 R7014A PDF -TheICStock

ATM38-2 Selling Leads,ATM38-2 Datasheet ,ATM38-2 PDF -TheICStock

[Katvis]

First we correct the bytes on a 16bit boundry to get the BIGENDIAN format for the Motorolla protocol.
We disassemble with Motorolla 68330 as CPU choice.
ROM:00000000 ; Processor: 68330
ROM:00000000 ; Target Assembler: 680x0 Assembler in MRI compatible mode
ROM:00000000 ; This file should be compiled with "as -M"
ROM:00000000
ROM:00000000 ; ================================================== =======================
ROM:00000000
ROM:00000000 ; Segment type: Pure code
ROM:00000000 ; segment "ROM"

Table 6-1 Exception Vector Assignments
Vector
Number
Vector Offset Assignment
Dec Hex Space
0 0 000 SP Reset: Initial Stack Pointer
1 4 004 SP Reset: Initial Program Counter
2 8 008 SD Bus Error
3 12 00C SD Address Error
etc etc

From the above documentation we can see that the Initial Stack Pointer is set to zero and that the Initial Program Counter shows to dc.l loc_200

ROM:00000000 dword_0: dc.l 0 ; CODE XREF: sub_362C+6j
ROM:00000000 ; sub_3E10E:loc_3E2AEj ...
ROM:00000000 ; INITIAL STACK POINTER
ROM:00000004 off_4: dc.l RESET_INITIAL_PROGRAM_COUNTER
ROM:00000004 off_4: dc.l loc_200 ; DATA XREF: sub_1056+90o
ROM:00000004 ; ROM:loc_172Co ...
ROM:00000004 ; START of program address
ROM:00000008 off_8: dc.l sub_5B0 ; DATA XREF: sub_966+88o
ROM:00000008 ; sub_CD6+68o ...
etc
etc

ROM:00000200 RESET_INITIAL_PROGRAM_COUNTER: ; CODE XREF: sub_5B0+10j
ROM:00000200 ; sub_3072+5Cj ...
ROM:00000200 StackPointer = sp ; store Adres registers on stack
ROM:00000200 StatusRegister = sr ;
ROM:00000200 VectorBaseRegister = vbr
ROM:00000200 movem.l a2-a3,-(StackPointer)
ROM:00000204 movea.l #$3FE0,a3
ROM:0000020A clr.l d0
ROM:0000020C movec d0,VectorBaseRegister ; clear vector base register
ROM:00000210 movea.l d0,StackPointer
ROM:00000212 movea.l #$4800,a2
ROM:00000218 tst.w (a2)
ROM:0000021A bne.w loc_24A
ROM:0000021E
ROM:0000021E loc_21E: ; CODE XREF: sub_3072-2E50j
ROM:0000021E addq.l #2,a2
ROM:00000220 tst.w (a2)
ROM:00000222 beq.s loc_21E
ROM:00000224 cmpi.w #$FFFF,(a2)
ROM:00000228 bne.s loc_230
ROM:0000022A jsr MAIN_LOOP? ;do some stuff and then jump to MAIN_LOOP
ROM:00000230
ROM:00000230 loc_230: ; CODE XREF: sub_3072-2E4Aj
ROM:00000230 cmpi.w #$F500,(a2)
ROM:00000234 beq.s loc_23E
ROM:00000236 cmpi.w #$F5,(a2) ; ')'
ROM:0000023A bne.w loc_24A
ROM:0000023E
ROM:0000023E loc_23E: ; CODE XREF: sub_3072-2E3Ej
ROM:0000023E lea ($4880).l,a0
ROM:00000244 movea.l dword_4884-dword_4880(a0),a0
ROM:00000248 jmp (a0)
ROM:0000024A ; ---------------------------------------------------------------------------
ROM:0000024A
ROM:0000024A loc_24A: ; CODE XREF: sub_3072-2E58j
ROM:0000024A ; sub_3072-2E38j
ROM:0000024A cmpi.l #$5AA556C9,(dword_FFFC).l
ROM:00000254 bne.s loc_25C
ROM:00000256 jsr (sub_1B78).l
ROM:0000025C
ROM:0000025C loc_25C: ; CODE XREF: sub_3072-2E1Ej
ROM:0000025C lea ($FFE500).l,a0
ROM:00000262 movea.l a0,StackPointer
ROM:00000264 move a0,usp
ROM:00000266 move.w #$C046,($FFFA00).l
ROM:0000026E move.w #$D200,($FFFA04).l
ROM:00000276 move.b #$BD,($FFFA21).l
ROM:0000027E move.b #$55,($FFFA27).l ; 'U'
ROM:00000286 move.b #$AA,($FFFA27).l
ROM:0000028E move.l #$FFE000,($FFFB44).l
ROM:00000298 clr.w ($FFFB40).l
ROM:0000029E move.w #$FFC1,($FFFA50).l
ROM:000002A6 move.w #$3830,($FFFA52).l
ROM:000002AE move.w #$FFC1,($FFFA54).l
ROM:000002B6 move.w #$5830,($FFFA56).l
ROM:000002BE jsr (sub_478).l
ROM:000002C4 jsr (sub_3CA).l
ROM:000002CA
ROM:000002CA loc_2CA: ; DATA XREF: sub_339AE+24o
ROM:000002CA ; sub_33AB0+5Co
ROM:000002CA btst #0,($FFE50C).l
ROM:000002D2 beq.s loc_2F8
ROM:000002D4 move.w #6,($FFFA48).l
ROM:000002DC clr.w ($FFFA5A).l
ROM:000002E2 clr.w ($FFFA5E).l
ROM:000002E8 move.w #$FFD0,($FFFB04).l
ROM:000002F0 move.w #$1000,($FFFB00).l
ROM:000002F8
ROM:000002F8 loc_2F8: ; CODE XREF: sub_3072-2DA0j
ROM:000002F8 cmpi.b #$4D,(a3) ; 'M'
ROM:000002FC bne.s loc_304
ROM:000002FE jsr (sub_55E).l
ROM:00000304
ROM:00000304 loc_304: ; CODE XREF: sub_3072-2D76j
ROM:00000304 jsr (sub_33A).l
ROM:0000030A
ROM:0000030A loc_30A: ; CODE XREF: sub_3072-2D56j
ROM:0000030A ; sub_3072-2D4Cj
ROM:0000030A jsr (sub_EB6).l
ROM:00000310 move.b #$55,($FFFA27).l ; 'U'
ROM:00000318 cmpi.b #$4D,(a3) ; 'M'
ROM:0000031C bne.s loc_30A
ROM:0000031E btst #5,($FFD15A).l
ROM:00000326 bne.s loc_30A
ROM:00000328 ori.b #1,($FFFA19).l
ROM:00000330
ROM:00000330 loc_330: ; CODE XREF: sub_3072-2D40j
ROM:00000330 nop
ROM:00000332 bra.s loc_330
ROM:00000332 ; END OF FUNCTION CHUNK FOR sub_3072
ROM:00000334 ; ---------------------------------------------------------------------------
ROM:00000334 movem.l (sp)+,a2-a3
ROM:00000338 rts


Then we land here:
In the start of this routine we can see that VBR gets loaded with loc 10000

ROM:00010C08 ; =============== S U B R O U T I N E ================
ROM:00010C08
ROM:00010C08
ROM:00010C08 MAIN_LOOP?: ; CODE XREF: sub_3072-2E48p
ROM:00010C08 ; sub_11068+40j
ROM:00010C08 lea (dword_10000).l,a0
ROM:00010C0E movec a0,vbr


If we go to 10000 we find another vector table shown below:

ROM:00010000 dword_10000: dc.l 0 ; DATA XREF: ROM:00002058o
ROM:00010000 ; ROM:00002658o ...
ROM:00010004 dc.l RESET_INITIAL_PROGRAM_COUNTER
; SAME AS FIRST VECTOR TABLE loc 200
ROM:00010004 ;
ROM:00010008 dc.l $11068
ROM:0001000C dc.l $11068
ROM:00010010 dc.l $11068
ROM:00010014 dc.l $11068
ROM:00010018 dc.l $11068
ROM:0001001C dc.l $11068
ROM:00010020 dc.l $11068
ROM:00010024 dc.l $11068
ROM:00010028 dc.l $11068
ROM:0001002C dc.l $11068
ROM:00010030 dc.l $11068
ROM:00010034 dc.l $11068
ROM:00010038 dc.l $11068
ROM:0001003C dc.l $11068
ROM:00010040 dc.l $11068
ROM:00010044 dc.l sub_1161C
ROM:00010048 dc.l sub_1196E
ROM:0001004C dc.l sub_11940
ROM:00010050 dc.l $11068
ROM:00010054 dc.l $11068
ROM:00010058 dc.l $11068
ROM:0001005C dc.l $11068
ROM:00010060 dc.l SPURIOUS_INTERRUPT
;interesting interrupts from CPU32 and 68376documentation
ROM:00010064 dc.l LEVEL1_INTERRUPT
ROM:00010068 dc.l LEVEL2_INTERRUPT
ROM:0001006C dc.l $11068
ROM:00010070 dc.l $11068
ROM:00010074 dc.l LEVEL5_INTERRUPT
ROM:00010078 dc.l $11068
ROM:0001007C dc.l LEVEL7_INTERRUPT
ROM:00010080 dc.l $11068
ROM:00010084 dc.l $11068
ROM:00010088 dc.l $11068
ROM:0001008C dc.l $11068
ROM:00010090 dc.l $11068
ROM:00010094 dc.l $11068
ROM:00010098 dc.l $11068
ROM:0001009C dc.l $11068
ROM:000100A0 dc.l $11068
ROM:000100A4 dc.l $11068
ROM:000100A8 dc.l $11068
ROM:000100AC dc.l $11068
ROM:000100B0 dc.l $11068
ROM:000100B4 dc.l $11068
ROM:000100B8 dc.l $11068
ROM:000100BC dc.l $11068
ROM:000100C0 dc.l sub_11690
ROM:000100C4 dc.l sub_11662
ROM:000100C8 dc.l sub_116BE
ROM:000100CC dc.l sub_116EC
ROM:000100D0 dc.l sub_1171A
ROM:000100D4 dc.l sub_11748
ROM:000100D8 dc.l sub_11776
ROM:000100DC dc.l sub_117A4
ROM:000100E0 dc.l sub_117D2
ROM:000100E4 dc.l sub_11800
ROM:000100E8 dc.l $11068
ROM:000100EC dc.l $11068
ROM:000100F0 dc.l sub_1182E
ROM:000100F4 dc.l $11068
ROM:000100F8 dc.l loc_118E4
ROM:000100FC dc.l loc_11912
ROM:00010100 dc.l $11068
ROM:00010104 dc.l $11068
ROM:00010108 dc.l $11068
ROM:0001010C dc.l $11068
ROM:00010110 dc.l $11068
ROM:00010114 dc.l sub_1185C
ROM:00010118 dc.l sub_1187E ; DATA XREF: ROMff_2FD7Co
ROM:0001011C dc.l sub_118A0
ROM:00010120 dc.l sub_118C2
ROM:00010124 dc.l $11068
ROM:00010128 dc.l $11068
ROM:0001012C dc.l $11068 ; DATA XREF: ROMff_2FD52o
ROM:00010130 dc.l $11068
ROM:00010134 dc.l $11068
ROM:00010138 dc.l $11068
ROM:0001013C dc.l $11068
ROM:00010140 dc.l $11068
ROM:00010144 dc.l $11068
ROM:00010148 dc.l $11068
ROM:0001014C dc.l $11068
ROM:00010150 dc.l $11068
ROM:00010154 dc.l $11068
ROM:00010158 dc.l $11068
ROM:0001015C dc.l $11068
ROM:00010160 dc.l $11068
ROM:00010164 dc.l $11068
ROM:00010168 dc.l $11068
ROM:0001016C dc.l $11068
ROM:00010170 dc.l $11068
ROM:00010174 dc.l $11068
ROM:00010178 dc.l $11068
ROM:0001017C dc.l $11068
ROM:00010180 dc.l $11068
ROM:00010184 dc.l $11068
ROM:00010188 dc.l $11068
ROM:0001018C dc.l $11068
ROM:00010190 dc.l $11068
ROM:00010194 dc.l $11068
ROM:00010198 dc.l $11068
ROM:0001019C dc.l $11068
ROM:000101A0 dc.l $11068
ROM:000101A4 dc.l $11068
ROM:000101A8 dc.l $11068
ROM:000101AC dc.l $11068
ROM:000101B0 dc.l $11068
ROM:000101B4 dc.l $11068
ROM:000101B8 dc.l $11068
ROM:000101BC dc.l $11068
ROM:000101C0 dc.l $11068
ROM:000101C4 dc.l $11068
ROM:000101C8 dc.l $11068
ROM:000101CC dc.l $11068
ROM:000101D0 dc.l $11068
ROM:000101D4 dc.l $11068
ROM:000101D8 dc.l $11068
ROM:000101DC dc.l $11068
ROM:000101E0 dc.l $11068
ROM:000101E4 dc.l $11068
ROM:000101E8 dc.l $11068
ROM:000101EC dc.l $11068
ROM:000101F0 dc.l $11068
ROM:000101F4 dc.l $11068
ROM:000101F8 dc.l $11068
ROM:000101FC dc.l $11068

Now if you are curious like me you will count the vector addresses and get 128, exactly halve of what it should be? I do not know why yet because the documentation clearly state we should have 256 vector addresses?

Rest of main loop:

ROM:00010C12 move.w #$4046,($FFFA00).l
ROM:00010C1A move.w #$D200,($FFFA04).l
ROM:00010C22 move.b #$BD,($FFFA21).l
ROM:00010C2A move.b #$55,($FFFA27).l ; 'U'
ROM:00010C32 move.b #$AA,($FFFA27).l
ROM:00010C3A jsr sub_10ECA
ROM:00010C40 lea ($FFE400).l,a0
ROM:00010C46 movea.l a0,sp
ROM:00010C48 move a0,usp
ROM:00010C4A move.b #$40,($FFFA41).l ; '@'
ROM:00010C52 move.w #$2FFF,($FFFA44).l
ROM:00010C5A move.w #$20A,($FFFA46).l
ROM:00010C62 move.w #$FFC1,($FFFA50).l
ROM:00010C6A move.w #$3830,($FFFA52).l
ROM:00010C72 move.w #$FFC1,($FFFA54).l
ROM:00010C7A move.w #$5830,($FFFA56).l
ROM:00010C82 jsr sub_120B4
ROM:00010C88 jsr sub_10CFA
ROM:00010C8E btst #1,($FFE50C).l
ROM:00010C96 beq.s loc_10CA4
ROM:00010C98 jsr sub_3E000
ROM:00010C9E jsr sub_3E0DA
ROM:00010CA4
ROM:00010CA4 loc_10CA4: ; CODE XREF: MAIN_LOOP?+8Ej
ROM:00010CA4 jsr sub_10F6C
ROM:00010CAA jsr sub_10FD2
ROM:00010CB0 jsr sub_11EAE
ROM:00010CB6 jsr sub_10FF6
ROM:00010CBC jsr sub_11FD6
ROM:00010CC2 jsr sub_11FAA
ROM:00010CC8 jsr sub_11F78
ROM:00010CCE moveq #$FFFFFFFF,d0
ROM:00010CD0 move.l d0,d1
ROM:00010CD2 move.l d0,d2
ROM:00010CD4 move.l d0,d3
ROM:00010CD6 move.l d0,d4
ROM:00010CD8 move.l d0,d5
ROM:00010CDA move.l d0,d6
ROM:00010CDC move.l d0,d7
ROM:00010CDE movea.l d0,a0
ROM:00010CE0 movea.l d0,a1
ROM:00010CE2 movea.l d0,a2
ROM:00010CE4 movea.l d0,a3
ROM:00010CE6 movea.l d0,a4
ROM:00010CE8 movea.l d0,a5
ROM:00010CEA movea.l d0,a6
ROM:00010CEC jsr sub_1332C
ROM:00010CF2 jsr sub_135DA
ROM:00010CF8 rts
ROM:00010CF8 ; End of function MAIN_LOOP?

[Katvis]

thank you again Alexics for your time and advise, I really appreciate it. The information is not enough and I think I will try and get a second DME and remove the components and see if I can find more data on the underside of the chips. I really need the pin outs that I can trace it back to the CPU and know which pin does what pin for pin

An update of where I am at the moment..

I have connected the Wiggler BDM interface to the ECU and at first I used the for free OCD commander supplied on Macraigor site. The debugger works perfectly but I found that I needed more information, I guess I am still spoiled by the windows debuggers.. Next I searched for software that could work with the wiggler interface, it seems like there are not many options, the one I chose to use at the moment is the ICD32Z debugger program. This program shows all the registers, one can monitor the memory area and single step or step till a given address. The program lacks a few functions which would be nice to have but for the price I am happy for now, again, if I need more I have to pay more.



The code seen in the debugger is exactly what I expected to see because this is the code that IDA showed as well. This code in the debugger also ties in with my explanations of the vector tables and entry point in the program posted earlier in this thread.

I have bought a digital oscilloscope to monitor the sensors on the engine. My ultimate goal still is to simulate the sensors to have a bench setup of a "running engine". Here are two pics of the crankshaft sensor and the exhaust camshaft position sensor. One can see on the crankshaft that the pulse train is 60 pulses per rotation with a position pulse missing at 60 to indicate TDC.





Where I am at the moment is as follows. I have setup the DME on the bench with a power supply connected and also a switch to simulate the ignition switch. I also have connected a LED to show the fuel pump request. I have done this as I know the fuel pump comes on briefly when you switch the ignition on and this is a good starting point for me to trace code and get familiar with the code and debugging. At the moment when I switch the power on to the DME my fuel pump LED lit for two seconds and then switch off. If I switch the ignition switch to start the fuel pump LED lit as well but as soon as I switch the ignition "start" off the fuel pump LED goes off. This is because the fuel pump does not operate if the engine is not running. When I looked at the crankshaft signal I saw that the frequency matched the revolutions of the engine, that is 800 RPM = 800Hz, 2000RPM = 2kHz etc etc. I then bought a cheap signal generator kit and tried to simulate the engine speed to the DME. With the signal generator switched on with a frequency of for example 800Hz and the "ignition start switch in the off position" the fuel pump LED stays lit. This was a positive sign for me but when I tried to see the RPM with INPA it did not show any RPM's? I think this is because the blank pulse is not present in my signal generators pulse train?

Last night I traced the code and tried to establish where the fuel pump LED get its signal and tried to see how the output of the CPU works. This proofed to be not as easy as I though even when I studied the trace code when the LED lit up. This led me back to the 68376CPU documentation and found the part where it gets described how the CPU manipulates the outputs of in this case the TPU outputs. This is a very steep learning curve and I am still trying to get my head around the exact method but I will study the papers tonight and try my luck again tomorrow..

I am still waiting for my small package BDM connectors and will post pics as soon as the connectors are soldered on the pc board.

Cheers
C

[alexics]

You said

I think this is because the blank pulse is not present in my signal generators pulse train?


I think you are right there and a proper simulation is going to be difficult. I am very interested in how you get on with this so keep me posted. If I can help further let me know.

[Katvis]

Hi guys
I have used the CrankWheelPulser utility to create the pulse train and boosted the voltage level through a normal desktop speaker system to 9Volts. I still cannot see the RPM values in INPA. I have connected a temperature sensor on the bench DME and can see the ambient temperature in INPA. I do not know yet why the RPM does not show in INPA. I have tried to modify the pulse signal as follows but still no luck.

Zero pulse as created by crankwheelpulser:



Pulse modified with audacity:



The DME does see the pulse train because as soon as I switch the pulse train on the fuel pump switch on and stays on until I switch the pulse train off.



I have also received my BDM connector and soldered it on CPU1 side.





I have traced the code until I found the place where the fuel pump gets switched on.


000276F0 RTS
000276EC MOVEM.L (A7)+,A2-A5
000276E6 MOVE.W (A3),(0FFE7D6).L
000276E2 LEA (24,A7),A7
00012F1A RTS
00012F18 MOVE.L (A7)+,D2
00012F12 MOVE.L D0,(0FFFE1C).L ;When this line executes the fuel pump switch on
00012F10 OR.L D2,D0
00012F0A AND.L (0FFFE1C).L,D0
00011660 RTE
0001165C MOVEM.L (A7)+,D0-D1/A0-A1
00011654 BNE.B 1165C
0001164E SUBQ.B #1,(0FFE50A).L
0001164A MOVE.W #2700,SR


In the above code I have commented where the fuel pump switch on. The problem I had when tracing the code was that while tracing the code there were exceptions happening. At first I thought this exceptions had something to do with the fuel pump code but when I traced the code for the exceptions I realized that it was exceptions from the CTM4 circuit. The fact that exceptions occur when one trace the code does make life more difficult as one has to trace through a lot of unnecessary code.

I do not know yet how the exceptions are raised. When I read the documentation there are descriptions and one can see the vector table entries addresses but I do not know yet exactly how and if I can read and trace the disassembled code and see the event that trigger an exception or if the exception is purely raised by timer events, or external requests. I would really appreciate if somebody with embedded CPU32 programming experience can give me some advise?

I really find that the software that I use has its limitations for tracing through code but the next level of software are really expensive, might be an option if I feel I can not manage with the current software.

Furthermore I have bought software that can read the software of the memory chip through the BDM interface. This helps a lot as I have the software that is on the DME that I play with now and it makes it much easier to follow the code addresses. Only problem was that the software was read as a S19 file, fortunately IDA recognise S19 files and the disassembly was perfect.

The next week or so I will spend studying some more reference manuals and try and get a clearer understanding of exactly how for instance the PWM pins are controlled. I have found the place in the software where for instance one of the Vanos solenoids are controlled but I need to trace through the code and see exactly how and where the values for Pulse width and period are created and set:


seg000:00028000 PWM5_load_registers: ; CODE XREF: sub_277B4+1ACp
seg000:00028000 ; sub_277B4+1C4p ...
seg000:00028000
seg000:00028000 arg_2 = 6
seg000:00028000 arg_6 = $A
seg000:00028000
seg000:00028000 move.w arg_2(sp),($FFF42C).l ; PWM Pulse width register
seg000:00028000 ;
seg000:00028008 move.w arg_6(sp),($FFF42A).l ; PWM Pulse Period register
seg000:00028008 ;
seg000:00028010 btst #3,($FFEBAE).l
seg000:00028018 bne.s locret_28036
seg000:0002801A btst #6,($FF81D5).l
seg000:00028022 bne.s locret_28036
seg000:00028024 btst #6,($FF81D7).l
seg000:0002802C bne.s locret_28036
seg000:0002802E ori.w #%100000,($FFF428).l ; enable load of pulse width and period registors in PWM output wave

seg000:00028036 rts
seg000:00028036 ; End of function PWM5_load_registers


Not suprisingly thought this subroutine gets traced back to a exception that gets raised to get here.

Thats it for now, as always, any advise and help will be appreciated..
Cheers

[alexics]

Have you identified the main program loop. I would start from that point. I would guess that there would be subroutine tables and flags to switch execution of handler routines on dependant upon certain conditions. Flags set in these routines will trigger the exceptions. Usually if external signals are missing you will get an exception. If you can't simulate all the inputs the system expects then repeated exceptions will occur. These may be caused also by the fuel pump activation when some other critical engine specific input is missing.

Can you trace through and document the exception vectors? Are they system or user defined?

[Katvis]

Hi Alexics
As always you give good advise..
I have found the main routine, there are a lot of JSR routines and from which I can follow there are a few subroutines for setting up the different modules of the 68376 CPU.

I have commented a few lines as follows:

ROM:00010C08 MAIN_LOOP: ; CODE XREF: sub_3072-2E48p
ROM:00010C08 ; sub_11068+40j
ROM:00010C08 lea (dword_10000).l,a0
ROM:00010C0E movec a0,vbr
ROM:00010C12 move.w #$4046,($FFFA00).l ; If bit no 6 in SIMCR - Module Configuration Register = 1,
; Internal modules are addressed from $FFF000 to $FFFFFF
; 0100 0000 0100 0110
ROM:00010C1A move.w #$D200,($FFFA04).l ; The SYNCR determines system clock operating frequency
; SYNCR - Clock Synthesizer Control Register
; page 51 SIMRM
; 1101 0010 0000 0000
; == 11534kHz
ROM:00010C22 move.b #$BD,($FFFA21).l
ROM:00010C2A move.b #$55,($FFFA27).l ; 'U'
ROM:00010C32 move.b #$AA,($FFFA27).l
ROM:00010C3A jsr sub_10ECA
ROM:00010C40 lea ($FFE400).l,a0
ROM:00010C46 movea.l a0,sp ; set supervisor stack pointer and
; user stack pointer to FFE400
ROM:00010C48 move a0,usp
ROM:00010C4A move.b #$40,($FFFA41).l ; '@'
ROM:00010C52 move.w #$2FFF,($FFFA44).l ; 10 11 11 11 11 11 11
ROM:00010C5A move.w #$20A,($FFFA46).l ; 10 0000 1010
ROM:00010C62 move.w #$FFC1,($FFFA50).l
ROM:00010C6A move.w #$3830,($FFFA52).l
ROM:00010C72 move.w #$FFC1,($FFFA54).l
ROM:00010C7A move.w #$5830,($FFFA56).l
ROM:00010C82 jsr sub_120B4
ROM:00010C88 jsr sub_10CFA ; SIM....
ROM:00010C8E btst #1,($FFE50C).l
ROM:00010C96 beq.s loc_10CA4
ROM:00010C98 jsr sub_3E000
ROM:00010C9E jsr sub_3E0DA
ROM:00010CA4
ROM:00010CA4 loc_10CA4: ; CODE XREF: MAIN_LOOP+8Ej
ROM:00010CA4 jsr sub_10F6C
ROM:00010CAA jsr sub_10FD2
ROM:00010CB0 jsr sub_11EAE ; QADC...
ROM:00010CB6 jsr TPU_INIT ; TPU init?
ROM:00010CBC jsr CTM4_Init ; CTM (PWM) init
ROM:00010CC2 jsr sub_11FAA ; QSM....
ROM:00010CC8 jsr sub_11F78 ; QSM.....


The fuel pump is switched on/off by the TPU module, I know this because the output pin used for the fuel pump is in the TPU module. The TPU configuration register shows to address 100C0 as the first vector for the TPU, I have assumed that the next 15 vectors are for the TPU as well? This I do not know for sure, the reason why I doubt is that three of the vectors shows to the reset routine...? Unless that three vector addresses never get used in the code. The thing about the vector address is that it only shows twice in the IDA disassembly, once in the vector table and once in the routine that shows to the vector table entry. So I guess what I am asking is how and where does the exception for a specific address gets raised if the vector number never gets addressed anywhere in the code?

On page 68 of the 68376 Reference Manual it shows the vector table used by the CPU, so I guess it is system generated but addressed through code?

Below is the vector address that gets pointed to by the TPU control register:

seg000:000100C0 dc.l loc_11690 ; TPU 0 Interupt Vector
seg000:000100C4 dc.l sub_11662
seg000:000100C8 dc.l sub_116BE
seg000:000100CC dc.l sub_116EC
seg000:000100D0 dc.l sub_1171A
seg000:000100D4 dc.l sub_11748
seg000:000100D8 dc.l sub_11776
seg000:000100DC dc.l sub_117A4
seg000:000100E0 dc.l sub_117D2
seg000:000100E4 dc.l sub_11800
seg000:000100E8 dc.l $11068 ;reset?
seg000:000100EC dc.l $11068 ;reset?
seg000:000100F0 dc.l sub_1182E
seg000:000100F4 dc.l $11068 ;reset?
seg000:000100F8 dc.l loc_118E4 ; possible PWM vector routine...?
seg000:000100FC dc.l loc_11912 ; TPU 15 Interupt Vector


I can definitely see some flags that gets used throughout all the sub routines, my next quest will be to try and identify the flags and try and see how they get used. I guess if I can identify some of the flags the code will read easier as well...

I have ordered a few books on CPU32 programming but they have not arrived yet, I hope to find some more information in the books.

Cheers

[alexics]

Have you got a listing of 11690? Also have you a full assembly listing with your comments so far? I may be able to put together a quick search and replace with comments so you could map port names and give meaningful names to flag setting values.

For instance if a register or port is ored with 01 you may want to change these to say start_fuel_pump instead of just 01. Only for reference to that port. Then add an associated comment to document that start_fuel_pump value is 01. This could allow entry of port value to search for, flag value to replace, name of value and comment to append. One operation could replace all instances and save an awful lot of time.

You will make mistakes but this function can also be used to correct them later.

[alexics]

Just so I am clear which way round are source and destination in the listing?

I see immediate values so source first, destination second?

[alexics]

On page 68 of the 68376 Reference Manual it shows the vector table used by the CPU, so I guess it is system generated but addressed through code?

It depends, for illegal instruction exception it will be microcode in the processor. Watchdog timers trigger on timeout. Other exceptions may depend upon data being present or absent on a port. Some exceptions will be the result of problems and be used to set fault codes that diagnostics will pick up.

What protocol does the unit use? Canbus, k-line or other?

[MMichael]

The ecu is connected by canbus to the ABS/DSC unit and some other units. Afaik the engine wont start or operate in safe mode if the is no canbus present. It uses k-line for external diagnosis tools.

[Katvis]

very interesting, thank you for this, I will unplug my cars canbus and see if the engine still starts, thanks for the tip
cheers
k

[MMichael]

I would like to help. I have some experience with assembler but only with microchip asm so far. After reading some of the mc68337 doc i slowly know whats going on.

ROM:00010C2A move.b #$55,($FFFA27).l ; 'U'
ROM:00010C32 move.b #$AA,($FFFA27).

This resets the watchdog timer , right ?

Are there subroutine(s) witch addresses the can interface ($FFF080-$FFF0A6)? Can you post the disassembled listing of that?

[alexics]

I would like to help. I have some experience with assembler but only with microchip asm so far. After reading some of the mc68337 doc i slowly know whats going on.

This resets the watchdog timer , right ?

Are there subroutine(s) witch addresses the can interface ($FFF080-$FFF0A6)? Can you post the disassembled listing of that?

To simulate the canbus you will need a can interface. I have a contact for these. Also is it 11 bit or 29 bit ids. I think volvo are 29 bit others 11 bit.

The k-line will either have a slow or fast init but not both IIRC. Could be either 5 baud or 200 baud for slow and 10400 for fast so find the baud rate registers first for this. You should find k-line interface schematics through a search on DK. The l-line is not normally used but may be in this case be check for both.