Some ECUs have a 'DTC offset' of some kind

[rnd-ash]

So whilst playing with some CBFs, we found that certain ECUs seem to apply an 'offset' when reading DTC information, which Caesar knows about from CBF and subtracts the offset from the DTC.

Good example of this is SBC (EHB_ASG.CBF) where reading DTCs provides the following Trace:

[58, 06, 66, 6F, 60, 64, 2F, 60, 61, 31, 60, 64, 0F, 60, 64, 4F, 60, 66, EC, 60]

This response from the ECU would typically indicate the following DTCs according to the KWP2000 specification:

666F, 642F, 6131, 640F, 644F, 66EC

However in actual fact, the errors as reported by Vediamo (And are contained in the CBF) are

266F, 242F, 2131, 240F, 244F, 26EC

So it seems that (On these DTCs at least), there seems to be an offset of -0x400 applied to each DTC

[jglim]

Hi! Thanks for taking time to create this issue.

Without reading the KWP spec, I am not sure if the input DTC IDs require a mask (I have not implemented DTCs for KWP). For UDS, I had to apply a mask of 0x3FFFFF to take the 22 effective bits for a usable ID.

https://github.com/jglim/CaesarSuite/blob/27369e939a5ecfd10875df268ef02be86b27b47f/Caesar/Diogenes/DiagnosticProtocol/UDS.cs#L227

Perhaps a similar style of masking is required, e.g. taking the lower 14 bits in the received KWP DTC? Unfortunately I do not have KWP devices to test this on, so I might need your help on this.

[rnd-ash]

No there isn't a mask. The KWP Specification states that a DTC can be anything from 0x0000 to 0xFFFF. KWP only supports 16bit DTCs.

Depending on which value the DTC has denotes which category it falls under:

0x0001-0x3FFF - Powertrain(P)
0x4001-0x7FFF - Chassis(C)
0x8001-0xBFFF - Body(B)
0xC001-0xFEFF - Network (N)

[jglim]

I'll have another guess at this:

Take the above table/address mapping and discard (right shift) the first 14 bits to get this table

0x0001-0x3FFF - Powertrain(P) : 0 0x4001-0x7FFF - Chassis(C) : 1 0x8001-0xBFFF - Body(B) : 2 0xC001-0xFEFF - Network (N) : 3

Using this DTC as an example:

C266F : Pedalwegsensoren: Leitungsabriß Kanal 2; Kanal 1 bereits ausgefallen

By swapping the "C" prefix into the value 0x266F, we can get the value 0x666F:

(prefix << 14) | id → (1 << 14) | 0x266F → 0x666F