The L8/P8 serial protocol for encrypted chips UPDATED 08/07/2009

[ECU Monitor Enthusiast]

As some of you know I have done some serious research into the weber ecu's as found on cossies. I have had many requests to divulge the following protocol information and to be fair to everyone, I have decided to make it public for all rather than give advantage to a few. This article will detail fully the serial communications protocol as used on the L8 and P8 ecu's as found on encrypted chips such as p.tel and others that use the same protocol. I will also publish later on, my PC software monitor and mapping examination tool along with all the source code. (as required by the site admin ) This article is highly technical so most reading it will not understand but then if that is the case, the information is useless to you ..lol ! I intend to update this artical over a short period of days as I would rather write it in sections so that discussion can commence straight away. (Actually most of it is on scribbled notes and in my head so its easier for me to write it this way) Many thanks for taking time to read. If you have any questions then feel free to ask ! This first post will contain these messages and the information itself aswell as any updates notices. This way, all info is in one place leaving the rest of the thread for questions and/or comments. (and no doubt piss takers..LOL) I will release the software a bit later on as I dont want to deflect away from this topic too soon. I offer this information and software completely free of charge but give no warranty or guarantee for accuracy or suitablility for any given application. Any information used from this article is totally at your own risk. The protocol is mainly a read only protocol but you are able to affect the ignition and fuel global adjustments in real time so it is possible you could damage your engine if used and abused without careful application. This information was gained totally by my own work and I offer it here on passionford for all to use as they see fit. I would ask that if you do use this information in any way, please add a minor credit back to me just so I can feel good about wasting years of my life for nothing ..LOL (This is only a request and not a condition) Finally, I would like to thank Passionford admin for allowing this article to go ahead. Cheers Simon INDEX SECTION 1: HOW TO CONNECT TO THE ECU SECTION 2: COMMUNICATIONS BYTE FORMAT SECTION 3: GENERAL NOTES SECTION 4: COMMAND STRUCTURE SECTION 5: SINGLE BYTE COMMAND DETAILS SECTION 6: EPROM CHIP ADRESSES AND DATA DECODING OF IMPORTANT DATA SECTION 7: ASSEMBLY LANGUAGE SOURCE CODE OF THE ECU COMMS ROUTINE (an example to show how the ecu does the comms) SECTION 8: READING AND INTERPRETING FAULT FLAGS SECTION 9: USING THE GLOBAL ADJUSTMENTS FEATURE SECTION 10: RECOMENDED METHOD OF COMMANDS FOR INITIALISATION SECTION 11: MY PC MONITOR/MAPPING SOFTWARE PROJECT {more to come !} NOTES AND ABREVIATIONS TX = Transmit RX = Receive All values with $ prefix are hex values. SECTION 1 - CONNECTION TO THE ECU *** TO BE COMPLETED *** I need to convert a drawing file to a .jpg file so that I can show how to build an interface. (By the weekend hopefully) Data is transmitted out of the ECU on pin 27 and data is received on pin 8. The interface to the ECU is at 12 volts - You cannot directly connect a PC RS232 serial port otherwise you may damage your ECU. You need a voltage translation circuit. This consists of a few transistor, resistors and diodes. The data idle state for both transmit and receive lines is 0 volts. The ECU transmit output on pin 27 is an open collector NPN transistor interface and needs an external pull up resistor to 12 volts. Similaly, the ECU receive input has an internal pull up resistor and needs to be driven by an external open collector NPN transistor. This interface is unlike the Fiat versions of these ecu's.. The circuit design is critical as the ECU ground can change voltage in relation to the vehicle chassis. If you are powering your laptop or monitor device from the car power, you may run into problems with data quality with other inferior designs ! (this is why the ignition amps have a seperate earth wire... ) SECTION 2 - COMMUNICATIONS BYTE FORMAT The data format is standard asyncronous serial data. This consists of a baud rate of 1953 baud (bits per second) which is actually the ECU CPU clock rate divided by 2048. ! This is why most USB to serial interfaces dont work as they only support standard rates like 9600 baud etc... Some work very well and I will list out a recomendation for those who want to use my software later. The baud rate can be switched up to a faster data rate by a byte change in the chip software but this isnt recomended as the protocol can consume valuable processing time making the engine operation eratic or slow to update. The data bit length is 8 bits (as opposed to 7) The parity system used is NONE and finally, 2 stop bits are implemented. So in summary, 1 data byte consists of a start bit, 8 data bits, 2 stop bits sent at a rate of 1953 bits per second. SECTION 3 - GENERAL NOTES When using this protocol, the best method is to use commands to read out the ECU configuration first before reading any sensor or fault data. This is because various types of throttle sensor, MAP sensor, ECU type, boost control types etc can be used. Differing configurations as listed above, change the scaling factors and in some cases the commands that can be used. An ident string that the mapper can set is also available to display to identify the chip but most tuners dont bother changing it. I will recomend a sequence of commands later on that works well for starting up. Once you have done that, you can read live data as you please or modify global map adjustments. The protocol is fairy dumb in that there is minimal error checking in some commands but no checking in most of them, this of course makes it easy to write code to do what we want. It should be noted that tuners can elect to switch off access to the protocol even if the chip is able to provide it. A single byte change in the chip is needed but you may need to consult your mapper to change it. I will give the address out of this byte later but it is the true address in the ECU memory map not the encrpted chip which may be different. SECTION 4 - COMMAND STRUCTURE The ECU does not "stream" data contrary to popular belief. The external equipment must send a request for data to which the ECU replies with data only once ! Some commands reply with data that can be out of date. For example, when the engine stops, the data freezes at the last running values. This is a design flaw in the ECU software but wont affect most people as it will only be noticable when you stall the engine ..! Commands may be sent to the ECU in any order but you must NOT send a new command for at least 80 milliseconds after receiving the reply of the previous command. If you do, you run the risk of stalling the engine as the CPU runs out of time to control the engine. If during a command sequence or waiting for data to be sent you detect a problem or timeout error, send $FF 3 times with 100 milliseonds between the bytes then try again. It is wise to do this the first time you go online after an ignition cycle. This allows the protocol to be reset to a known state. The commands fall into these catagories... 4.1 - SINGLE BYTE COMMAND These commands are the easiest to use and only allow data to be read from the ECU. A single byte is sent, and a single byte is returned from the ECU. Example .... To read the live battery voltage SEND TO ECU:..... $89 ECU REPLY:......... $C0 The reply byte is then scaled to represent the required value. In this case $C0 = 192 192 * 0.0625 = 12.0 volts (0.0625 is the scaling factor in this command) The ecu usually replies within 10 to 50 milliseconds. The complete list of these commands along with scaling information will be listed later on. 4.2 - READ RAM COMMAND (8 bit address code) This command is shown here but its use is very limited due to thae fact only a single byte is used to provide the address of the memory. The memory address has a fixed constant such as $1900 in the L8. I personally have not needed to use this command as others provide easier methods to get the data. The ram contents and use are mainly for internal ECU control and so they have no practical use for our intended requirements. I have listed the command here for information only. (Note: for those who dont know the RAM memory is NOT the chip data) The command is sent as 2 bytes interlaced with a command echo and the data. The whole transaction is 4 bytes in total. The second byte that is sent to the ECU can be transmitted as soon as the ECU replies with the command echo $34. SEND TO ECU:..... $04 (Fixed command value always the same) ECU REPLY:......... $34 (Fixed reply value always the same) SEND TO ECU:..... $12 (This is the required memory address) ECU REPLY:......... $08 (This is the data from the address byte supplied) Simple but effectively no use to us ! LOL So in the L8 ECU, we are reading the data from address $1912 and that data is $08 NOTE: $1900 data is located in the 2 kilobyte RAM chip on the encryption board ! 4.3 - READ MEMORY COMMAND (16 bit address code) This command allows access to the full ECU memory map which includes the chip EPROM, RAM and I/O registers. This command is very powerfull as in effect it could allow you to read out the entire chip contents bypassing all the encryption !! However, Depending on the version and tuner, there maybe restrictions placed in the software that prevent certain areas being read out and in fact the command will return garbage data in these cases. Tuners can not remove this command completeley as it is fundamental in the initialisation of any monitoring system that uses the this protocol. This command structure is similar to the one above in that byes are interlaced. There are 6 bytes total in the whole transaction. SEND TO ECU:..... $03 (Fixed command value always the same) ECU REPLY:......... $33 (Fixed reply value always the same) SEND TO ECU:..... $F6 (This is the required memory address high byte) ECU REPLY:......... $F6 (This is a echo of the above byte as a check) SEND TO ECU:..... $08 (This is the required memory address low byte) ECU REPLY:......... $45 (This is the data from the address byte supplied) So the above example shows a request for data to be read from $F608 and the byte in that location is $45 I will list later on, the addresses needed to read configuration data and other usefull stuff. This is where it gets interesting ..LOL! 4.4 - READ MULTIPLE LIVE DATA ITEMS This command allows access to 1 of 2 fixed format live data strings. The string returned depends on what the mapper has set in the configuration. There are only 2 possibilites, generally the longer version is the normal one used. You need to know which string is configured so you know how many bytes to expect. This is delt with later on in the article. A single command byte is sent $05 and multiple bytes are returned. This string data will return data at all times when requested but is only updated while the engine is running. (Data values shown are for illustration only) <<< SHORT VERSION - 5 ITEMS >>> SEND TO ECU:..... $05 (Fixed command value always the same) ECU REPLY:......... $35 (Fixed reply value always the same) ECU REPLY:......... $01 (Data byte 1 - RPM HIGH BYTE) ECU REPLY:......... $02 (Data byte 2 - RPM LOW BYTE) ECU REPLY:......... $03 (Data byte 3 - MAP SENSOR) ECU REPLY:......... $04 (Data byte 4 - CHARGE AIR SENSOR) ECU REPLY:......... $05 (Data byte 5 - COOLANT SENSOR) ECU REPLY:......... $06 (Data byte 6 - THROTTLE POSITION SENSOR) 1 byte is sent and 7 bytes are returned. <<< LONG VERSION - 7 ITEMS >>> SEND TO ECU:..... $05 (Fixed command value always the same) ECU REPLY:......... $35 (Fixed reply value always the same) ECU REPLY:......... $01 (Data byte 1 - RPM HIGH BYTE) ECU REPLY:......... $02 (Data byte 2 - RPM LOW BYTE) ECU REPLY:......... $03 (Data byte 3 - MAP SENSOR) ECU REPLY:......... $04 (Data byte 4 - CHARGE AIR SENSOR) ECU REPLY:......... $05 (Data byte 5 - COOLANT SENSOR) ECU REPLY:......... $06 (Data byte 6 - THROTTLE POSITION SENSOR) ECU REPLY:......... $07 (Data byte 7 - IGNITION TIMING VALUE) ECU REPLY:......... $08 (Data byte 8 - INJECTION PULSE HIGH BYTE) ECU REPLY:......... $09 (Data byte 9 - INJECTION PULSE LOW BYTE) 1 byte is sent and 10 bytes are returned. As you can see, the long version is the same as the short except it has fuel and ignition values added to the end. Raw data is returned that needs scaling/converting to real data depending on configuration. This is listed later in the article. *** TO BE CONTINUED TOMORROW ***

If you were logged in, you wouldn't be seeing this ad! Register your free account today, or log in if you already have an account.

[GARETH T]

oh this is going to get intresting! thanks for posting simon!

[blacky.]

over my head but i will keep reading lol

[J1mbo]

really interesting

nice one simon

[digitalgraham]

Well I was nearly there with 1954 but 2 stop bits!!! Damn LOL

[ECU Monitor Enthusiast]

Originally Posted by digitalgraham

Well I was nearly there with 1954 but 2 stop bits!!! Damn LOL

Round down is the way forward (or ignore shitty fractions) ..PMSL


I will add more tomorrow night.

[digitalgraham]

Cheers ... good work, keep it coming

[miller3]

Nice one Si

[natehall]

nice work - i look forward to reading it!

[LINCOLN]

I am sure (hope) your hard work will be appreciated by all as it should be.

Cheers.

[yappstar]

Very interesting Simon, thanks

[RaZoR]

My Hats Off To You Simon!

Some years ago I started doing the same thing. Had the interface and software made and everything. I got feed up with it in the end, couldn’t get the communication working. And realised it's not really worth it, the ECU is so old and not worth the money and time. You can get way better and user friendly management today than the old weber has to offer. But it’s nice to see that someone kept at it.

Again hats off, I understand the time and work put in to this.

[ECU Monitor Enthusiast]

Razor,

Thanks for the comments. It was a load of work and i am glad someone appreciates it..lol

More to come tonight

[PeterD]

Great project Simon, really looking forward to reading the rest of it.

Is there pages and pages of source to read?

[stu21t]

I'm looking forward to playing with this
eventually lol

[saph4be]

interesting stuff mate

[Stu @ M Developments]

I have been looking forward to this. Glad you have got round to it.

[ECU Monitor Enthusiast]

BTTT ..... Updates

[biggiejody]

totaly over my head i dunno what 99% of it is lol. but gotta say fairplay for working so hard on it and then sharing it for everyone to use. big respect for that

[Neil S]

Thank you Simon, very interesting reading. I'm looking forward to the next installment

[DazC]

i find a lot of it interesting. I re-read it a couple of times.

[Fudgey]

do you give lessons in binary and hex simon?

most of that is way over my head

[yappstar]

Originally Posted by Flux Capacitor

Data is transmitted out of the ECU on pin 27 and data is received on pin 8.
The interface to the ECU is at 12 volts - You cannot directly connect a PC RS232 serial port otherwise you may damage your ECU.
You need a voltage translation circuit.
This consists of a few transistor, resistors and diodes.
The data idle state for both transmit and receive lines is 0 volts.
The ECU transmit output on pin 27 is an open collector NPN transistor interface and needs an external pull up resistor to 12 volts.
Similaly, the ECU receive input has an internal pull up resistor and needs to be driven by an external open collector NPN transistor.
This interface is unlike the Fiat versions of these ecu's

Don't all RS232 ports interface at 12V via a MAX232 chip (the industry standard for a PC)?

Not knocking you Simon, just wanting to clarify so I have these things in my head straight

Interesting update too

[digitalgraham]

Simon, theres some serious work there so far! One thing I have noted tho, damn ECU is seriously slow on the Tx/Rx, having to wait for 80ms before next command!

What about programming the ECU to stream data, that should be possible?

[foreigneRS]

[ECU Monitor Enthusiast]

Originally Posted by yappstar

Don't all RS232 ports interface at 12V via a MAX232 chip (the industry standard for a PC)?

Not knocking you Simon, just wanting to clarify so I have these things in my head straight

Interesting update too

RS232 is NOT just 12 volts it is +/- 12 volts (actually a range from +/-5 volts to +/- 15 volts now)

I.E. there is a negative content to the voltage levels !

The data is either at +12 volts or at -12 volts (not to be confused with 0 volts griound)
Where as the ECU works at +12 volts and 0v only.

View the MAX232 data sheet here ... http://www.datasheetcatalog.org/data...nts/max232.pdf

Originally Posted by digitalgraham

Simon, theres some serious work there so far! One thing I have noted tho, damn ECU is seriously slow on the Tx/Rx, having to wait for 80ms before next command!

What about programming the ECU to stream data, that should be possible?

It is slow ! LOL

You can go a bit quicker but I wouldnt recomend it as it could impact on the engine tracking software.

There is a multibyte string read command I havent shown yet which helps greatly.... Thats in tonights update
That allows upto 7 of the most common items to be read out in one quick go !

Yes it is very possible to reprogram or add extra code in the ecu to do more.
I will show the example routine that is actually in the ecu that does the comms then you will see just how easy it could be !
Dont forget though, we have limited memory and spare performance to do this as the CPU is steam powered..LOL

[yappstar]

Originally Posted by Flux Capacitor.

RS232 is NOT just 12 volts it is +/- 12 volts (actually a range from +/-5 volts to +/- 15 volts now)

I.E. there is a negative content to the voltage levels !

The data is either at +12 volts or at -12 volts (not to be confused with 0 volts griound)
Where as the ECU works at +12 volts and 0v only.

View the MAX232 data sheet here ... http://www.datasheetcatalog.org/data...nts/max232.pdf

Thanks

[CossieRich]

Simon,

you are such a knowledgeable bloke. I wont even understand 1/4 of what you have written but i shall read it anyway. Well done

[ECU Monitor Enthusiast]

Cheers Rich


Only a small update tonight showing the live data multiple data string.
I am on holiday after tomorrow so will have more time to complete this

[stu21t]

better hope you get to the post office tomorow then.

can it read the CO screw position aswell?
That's quite useful.

[ECU Monitor Enthusiast]

Yes mate

[Rick]

Very interesting Simon. I'm kind of dissapointed i've had an RS turbo and not a cossie all these years, as I would have have attempted some reverse engineering of the ECU. Not really much you can do with KE jet.
Rick.

[ECU Monitor Enthusiast]

Rick,

With the right adaptor, you can read out the single chip cpu rom file of the ignition module into a eprom programmer..

In fact I did this some years ago and may do another artical on it after this one

[Sonic Boom]

Is it possible to upgrade the ECU itself to run more memory?
Cheers Rich

[ECU Monitor Enthusiast]

Originally Posted by Sonic Boom

Is it possible to upgrade the ECU itself to run more memory?
Cheers Rich

Yes it is but not really needed unless you want to mod the software to do true live mapping.
RP Labs did this exact thing but it isnt cheap...LOL

[DazC]

getting interesting!interesting! I'd be interested in the rs turbo stuff too if you get round to it.

[ossie cossie]

thank you for this it is completely over my head but i am sure someone here in OZ will be able to understand it if i need to get mine looked at. Thanks again.
TONY.

[ECU Monitor Enthusiast]

Sorry people, I didnt manage to update last night will do loads tonight

This was due to tha fact my Focus ST alternator is playing up and I got stranded in the middle of no where when my battery went flat .. LOL

Big thanks to cossiedave for coming to the rescue as I am too tight to be an AA member LOL

[DazC]

i look forwards to reading it later simon.

[stu21t]

Update?