ECU Diagnostics

ECU Diagnostics – part 9 : The Easimap Protocol Theory

Ok. so we’ve set ourselves up to be able to look at what is going on with a Caterham diagnostics port, we’ve talked a bit about the theory of what we might see from the port and we’ve also seen that Easimap talks to the ECU using a higher level protocol called ISO 15765-2 (ISOTP). We also saw how Easimap is asking the ECU for its model and serial number.

Easimap Data Request Protocol

At about this time, we also made a bit of a leap in our understanding of the communications between Easimap and the car.

We’d seen how Easimap sending 0x04000d to the car gave a response of the model and serial numbers (0xe4000d23394134626535333000). Notice how the first byte of the request is 0x04 and the first byte of the response is 0xe4. Seemed to me as though the response was echoing the 4 and setting some higher order bits creating a response code of 0xe4… Hmm…

If we look further down the communications that Easimap sends to the car (with the default gauges and pages set in Easimap) then we can also see some patterns.

It seemed to me that the first byte of the model/serial request was going to be a message type (0x04 means get some config data).

Looking through the next communications we see Easimap send:


and gets a response of:


If we think back to the 0x04 and 0xe4, request/response, of the model/serial exchange then this new exchange looks like a request/resonse of 0x01/0x81. That’s the same sort of pattern… a request of 0x01 and a response with the topmost bit set. That’s starting to make sense, but what of all the other data?

It was at about this time that James (Aerobod) had been looking at his car and had seen a pattern where there was an Lowest Significant Byte (LSB) and Most Significant Byte (MSB) being sent periodically that matched some of the data he was looking for.

It then dawned on me that my previous hunch about pages and addresses in the EC2 files was starting to make sense. If we look at our request to the car of:


then the first byte we know about (0x01) and then there are some more bytes of 0x00 with a 0x12 next, that could a page. Then there are sequences of similar numbers 0x66 followed by 0x67, then 0xa8 followed by 0xa9. They could be addresses.

I searched the EC2 file for 0x6667 and 0xa8a9 but there wasn’t anything that made sense.

It then occurred to me that perhaps the pages and addresses in the EC2 file weren’t being used exactly as written in the file. And if James’ thinking about LSB and MSB was right then perhaps the 0x6667 was the LSB of the address in the EC2 file followed by the same LSB+1.

With the data we have above that would mean we needed to look in the EC2 file for a variable with a page of 0x12 and address LSB of 0x66. A quick search in our EC2 file turns up:

Number of Dimensions = 0
Page = 12
Address = 6766
Bytes per Cell = 2

Some of the right data was present, the 12, 66 and 67 were there. And it seemed to indicate that this was related to Ignition Advance Bank1. Ok, that could be, our Caterhams could have something like that in them.

Next was to look at the response from the car:


We know that 0x81 is the response type for a request of 0x01. That leaves data of 0xaaaa1600. That’s probably 0xaaaa and 0x1600. Neither seemed to make much sense for an Ignition Advance Bank 1 response. It could be right, it could be wrong.

At this point I also started to pull apart the test.lsn file I’d found in the Easimap configuration directories on the PC. That file seemed to be the setup Easimap was using to say what gauges and displays to put on the screen for each “page” of the software display. It had a section like this:

RT_THROTTLESITE1, Throttle Position|Throttle Position Limits and Default Setup, Throttle Site 1
RT_BATTERYVOLTAGECOMP, Fuel|Voltage Fuel Compensation, Battery Voltage Comp
RT_ENGINESPEED, Engine Speed Setup & Limiter, Engine Speed
RT_IGNITIONADVANCEBANK1, Ignition, Ignition Advance
RT_TPSVSSPEEDIGN+TRIM1, Ignition, TPS vs Speed Ign + Trim
RT_INJECTIONTIMEA, Fuel, Final Injection Time
RT_COOLANTTEMP1(LIM), Sensors|Coolant Temperature, Coolant Temp
RT_AIRTEMP1(LIM), Sensors|Air Temperature, Air Temp
RT_MAPPINGPOT1LIM, Mapping Box|Mapping Pot 1, Mapping Pot 1
RT_MAPPINGPOT2LIM, Mapping Box|Mapping Pot 2, Mapping Pot 2
RT_COOLANTFUELFACTOR, Fuel|Coolant Temperature Compensation, Coolant Fuel Factor
RT_BATTERYVOLTAGE(LIM), Sensors|Battery Voltage, Battery Voltage
RT_AIRTEMPFUELFACTOR, Fuel|Air Temperature Compensation, Air Temp Fuel Factor
RT_DUTYCYCLEA, Fuel|Duty Cycle, Duty Cycle
RT_SOFTCUTTIME, Engine Speed Setup & Limiter, Soft Cut
RT_HARDCUTTIME, Engine Speed Setup & Limiter, Hard Cut
RT_THROTTLEANGLE1(RAW), Throttle Position|Throttle Position Limits and Default Setup, Throttle Angle 1 (Raw)
RT_ECUSTATUS, Fault Conditions, ECU Status
RT_BAROSCALEDLIM, Sensors|Barometric Pressure, Baro Pressure
RT_THROTTLEANGLEINCREASING, Throttle Position|Throttle Position Limits and Default Setup, Throttle Angle Increasing
RT_BAROFUELCOMP, Fuel|Barometric Pressure Fuel Compensation, Barometric Pressure Fuel Compensation
RT_CRANKCOUNT, Development, Crank Count

That was clearly a list of variables (in upper case) that Easimap was going to request data for from the car.

And an obvious candidate for a search in there was RT_ENGINESPEED, or Engine RPMs. I knew that I’d not had the car engine running when I did my packet captures, so there was a good chance that if I found the request for RPM then I could see a response of with zeros back from the car.

Looking in the EC2 file, you can find definition of RPM variable as:

Number of Dimensions = 0
Page = F8
Address = 237C
Bytes per Cell = 2

Ok. So, we’ll looking for a request with a page of 0xf8 and an address that’s either 0x237c or possibly 0x7c7d.

Looking through the CAN bus as ISOTP output again we find this request:


and this response:


In the request there’s the 0x01 at that start that is some kind of data request and the corresponding 0x81 in the response. We then see 0xf8 after the 4 x 0x00’s. Ok, that’s looking good, we’re looking for a page of 0xf8 for RT_ENGINESPEED.

We can also see that 3/4 of the way along the request we can see 0x7c7d. If we break the request down into the bit at the start (pre-amble) of 0x0100000000f8 and then the pairs that could be LSB/MSB combinations, then we get this:


That’s all looking good for the LSB/MSB theory of LSB/LSB+1 and shows us that 0x7c7d is 19 bytes into the data section. I also took note that some data being requested has only one byte of request information… I’ll need to remember that later.

Now if we look at the response from the car and break it down like the request data and slot in the request data on the left:

 Request         Response
 0100000000f8 =  81
 3031         =  4e39
 3637         =  094a
 4445         =  9c52
 4c4d         =  b886
 4e4f         =  e884
 5051         =  4e39
 5a5b         =  a80d
 5c5d         =  70a0
 64           =  00
 6a6b         =  b04f
[7c7d         =  0000]
 9e9f         =  5695
 a0a1         =  8009
 d8d9         =  0080
 dadb         =  0080

Then… low and behold… where I’ve put brackets around the line, we can see that our theory about RT_ENGINESPEED needing a request of 0x7c7d is returning 0x0000 in exactly the right spot in the response… showing that the car isn’t running.

That’s good enough for me… I think my theory is as good as I’m going to get, I need to write some code to test this out.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.