Bootloader

A bootloader lets ECU software be updated in the field. Learn memory layout (bootloader, application, calibration), the reprogramming sequence over UDS, CRC/signature verification, secure boot, A/B partitions for OTA, flash timing and fail-safe design.

Cars receive software fixes and new features long after production. Each ECU contains a small, permanent bootloader that can erase and rewrite the application in flash — via workshop tools or over the air.

A bootloader must never 'brick' an ECU: power loss mid-update, corrupted data or malicious images must all be handled safely.

An analogy

The bootloader is like a building's emergency staircase: rarely used, but it must always work, even when the rest of the building (application) is being renovated.

Memory layout

Flash is split into a protected bootloader region, the application, and calibration data (and sometimes a second application slot). At reset, the bootloader decides whether to run the application or stay in reprogramming mode.

Reprogramming sequence (UDS)

Tester: extended session (10 03) → disable DTC setting (85 02) and non-diagnostic communication (28 03) → programming session (10 02, ECU reboots into bootloader) → security access (27) → erase routine (31 01 FF00) → RequestDownload (34) → TransferData (36) blocks → RequestTransferExit (37) → check dependencies/CRC routine (31 01 FF01) → ECU reset (11 01).

Integrity and security

CRC detects corruption; digital signatures (RSA/ECDSA) verify authenticity — secure boot refuses unsigned code. Hardware security modules (HSM/SHE) store keys; rollback protection prevents old vulnerable versions. UNECE R156 requires a software update management system.

OTA and fail-safety

A/B (dual-bank) partitions let the new image be written while the old one runs; a switch occurs only after verification, with automatic rollback if the new image fails. Delta updates reduce download size. Updates must be coordinated across ECUs (dependencies) and done in safe vehicle states.

Formulas

Worked example: Flash time over different links

Given: 2 MB image; CAN 500 kbit/s at ≈ 50 % efficiency; CAN FD 2 Mbit/s effective; DoIP ≈ 50 Mbit/s effective

Find: Transfer times.

Answer: 67 s vs 8.4 s vs 0.34 s (+ erase/verify)

Worked example: Fleet OTA duration

Given: 20 ECUs × 67 s each over CAN, sequential

Find: Total time.

Answer: ≈ 22+ min — why OTA architectures use Ethernet, parallel flashing and A/B banks

Boot decision with integrity check (C)

#include <stdint.h>
#include <stdbool.h>

#define APP_START   0x08010000u
#define APP_SIZE    0x00070000u
#define APP_CRC_ADR (APP_START + APP_SIZE - 4u)

extern uint32_t crc32(const uint8_t *data, uint32_t len);
extern bool     sig_verify(const uint8_t *img, uint32_t len);   /* ECDSA/RSA, secure boot */
extern bool     reprogram_request_flag(void);                   /* set by app via UDS 0x10 02 */

void bootloader_main(void)
{
    const uint8_t *app = (const uint8_t *)APP_START;
    uint32_t stored = *(const uint32_t *)APP_CRC_ADR;

    bool valid = (crc32(app, APP_SIZE - 4u) == stored) && sig_verify(app, APP_SIZE - 4u);

    if (!valid || reprogram_request_flag()) {
        uds_programming_session_loop();     /* stay in bootloader, accept new image */
    }
    jump_to_application(APP_START);          /* set MSP, VTOR, branch to reset handler */
}

The bootloader only starts an application that passes integrity and authenticity checks; otherwise it waits for reprogramming.

Common mistakes

Applications

Key takeaways

Going further