I am working on disassembly of M2.8.1 code (you can find stock file
here). It is used in X30XE powered Opel Omega (V6 engine, MAF based, sequential injection organized in 2 banks, wasted spark ignition, 2 narrowband oxygen sensors, EGR and SAI). I am not sure but I suppose also Cadillac Catera uses same ECU (maybe running different software). This ECU (like other MLx.y/M1.x/M4.x Motronics) uses microcontroller derived from original Intel 8051 design. I believe it is Siemens/Infineon 80C517A. Unfortunately my disassembly skills are poor but after many hours I properly labelled at least map lookup and mathematical functions. I hope I will understand and label other functions but in the mean time I would like to add some functionality. The most important thing for me is custom logging routine as OEM protocol is just too slow (9600bps and 68 parameters to send, it seems ECU is to busy to send any data around 3800 RPM at WOT so it is really hard to get meaningful data). I am quite confident I will be able to write logging routine on my own but I faced another problem. It have taken me nearly a week to find a way to communicate with ECU over serial connection through K-Line. For now it is rather dirty way as I have just replaced stock serial communication interrupt routine (located @0x0410) with my own function. For now I just would like to be able to send to ECU a command and receive requested data in response (RAM dump, XRAM dump, current data from all 12 ADC channels in full 10 bit resolution). I have to admit it is sort of working as I am able to get response from the ECU (to simplify my tests I set it so it just acknowledge receiving a command but I have full routine ready) but I have to send at least 2 bytes to the ECU to get any response. Is it because first received byte just triggers serial interrupt? Is there any way not to loose this data?
For the tests I am using such a code:
Code: Select all
PUSH ACC
SETB BD ; use dedicated serial0 baud rate generator
MOV S0CON, #0x50 ; mode1 <=> 8bit UART, receive enabled
MOV S0RELH, #0x3
MOV SORELL, #0xE6
ORL PCON, #0x80 ; use 19200bps data rate, also tested 9600bps and 38400bps to
be working over MAX232 based RS-232 KKL cable, 62500bps
tested to be working over genuine Ross-Tech VCDS HEX-USB KKL
cable, unfortunately 125000bps is not working
JNB RI0, $
CLR RI0
MOV A, S0BUF
CLR REN0 ; K-Line is half duplex line
CLR TI0
MOV S0BUF, #0x41 ; letter A
FD JNB TI0, $
CLR TI0
MOV S0BUF, #0x43 ; letter C
JNB TI0, $
CLR TI0
MOV S0BUF, #0x4B ; letter K
JNB TI0, $
CLR TI0
MOV S0BUF, #0x20 ; space
JNB TI0, $
CLR TI0
MOV S0BUF, A ; data send by user
FD JNB TI0, $
CLR TI0
SETB REN0 ; reenable receive
POP ACC
RETI ; this routine replaced normal serial communication interrupt routine
I believe there are people with much better 8051 assembly skills here at PCMHacking forum so perhaps someone could help me with those small issues I am facing. Most important questions (at least for now) are already asked above. Next biggest problem is where should I insert lcall to my code so it would be executed at every ECU loop (I already tried "a few" places but were unable to communicate with ECU - I am not sure if my code was ever run or if it was a problem with OEM serial code interference as I do not understand how is serial communication working in stock form - Bosch/GM serial interrupt routine does more or less nothing related to communication - it kicks in if RAM_29.2 bit is set (otherwise it just disables serial interrupt) and just moves some data to and from XRAM, including received byte. I hoped it should be sufficient to CLR RAM_29.2 together with 4th bit of IEN0 not to get any issues with normal communication routines (which still might be true as I am not sure if my code had been run at least once despite trying to lcall it from different places). I am going to use a routine (based on idea and code from M4.4 enhancement described
here) which will let you switch between OEM diagnostics and my custom logging routines.
For now my logging routine would be quite poor as I have not located many parameters which are stored in XRAM so I hope I will be able to extend it when my disassembly will get further.