Diagnostic communication: reading fault codes and updating with UDS
UDS, the standard by which a workshop tester talks to an ECU. Service IDs, fault codes (DTCs), sessions and security access, and firmware flashing.
UDS (ISO 14229)
The tester sends a request and the ECU responds. The first byte of the request is the service ID.
| SID | Service | Use |
|---|---|---|
| 0x10 | Diagnostic session control | Switch between default / extended / programming sessions |
| 0x11 | ECU reset | |
| 0x14 | Clear DTCs | |
| 0x19 | Read DTCs | Fault codes and the conditions when they occurred |
| 0x22 / 0x2E | Read / write data (DID) | Version, VIN, calibration values |
| 0x27 | Security access | Seed-key authentication |
| 0x31 | Routine control | Self-test, memory erase |
| 0x34 / 0x36 / 0x37 | Request download / transfer / exit | Firmware flashing |
A positive response is SID + 0x40 (for example 0x22 → 0x62), and a negative response is 0x7F + SID + a reason code.
Transport layer
A UDS message can be longer than the 8 bytes of CAN, so ISO-TP (ISO 15765-2) splits it into several frames and controls the flow. On Ethernet, DoIP is used.
RoadmapSee where this note sits in Automotive Software→DTC
When an ECU detects a fault it stores a fault code (P0xxx and so on) in non-volatile memory together with the conditions at the time (the freeze frame). Defining the conditions for detecting, confirming and clearing a fault is the heart of developing diagnostic functions.
Flashing sequence
Enter the programming session → security access → memory-erase routine → download → verification routine → reset. The bootloader handles this sequence.