ECU flash programming over UDS: how reflashing actually works

Most diagnostic communication reads: identification, fault codes, measurements. Flash programming is the one operation that replaces the software an ECU runs — and it happens far more often than most people outside the field expect. Every ECU is programmed at the end of the production line, reprogrammed in the workshop when a fix or a feature ships, and, in software-defined vehicles, updated over the air across its whole life.

The component that makes this safe is the flash bootloader: a small, permanently resident program that owns the flash memory and decides what is allowed to run. It is the first thing that executes at power-on, and the one piece of software the reprogramming process must never damage — because it is what everything else recovers through.

Reprogramming over UDS (ISO 14229) is a fixed choreography. It starts before the programming session: in an extended diagnostic session (service 0x10), the tester checks preconditions — the vehicle is stationary, voltage is stable — and quiets the network, using CommunicationControl (0x28) to pause normal message traffic and ControlDTCSetting (0x85) so the rest of the vehicle does not log faults while one node goes silent.

Then the sequence proper: enter the programmingSession (0x10), where execution typically hands over to the bootloader; unlock with SecurityAccess (0x27), the seed-and-key exchange that gates the write path; erase the target logical block with a RoutineControl (0x31) erase routine. The download itself is three services — RequestDownload (0x34) declares the memory address, size and data format; TransferData (0x36) moves the image block by block behind a sequence counter; RequestTransferExit (0x37) closes the transfer. Finally the tester runs verification routines (0x31 again) — an integrity check over what was written, and a dependency check that the combination of blocks now in flash is allowed to run together — before an ECUReset (0x11) boots the new application.

The sequence above assumes nothing goes wrong. Production assumes everything eventually does. The defining property of a production-grade bootloader is that an interrupted flash — power loss mid-erase, a cable pulled mid-transfer — never leaves the ECU dead: the resident bootloader is never erased, and at every boot it validates the application before starting it, staying in programming mode when the application is incomplete or inconsistent. Recovery is designed in, not handled ad hoc.

Two more guarantees separate production designs from demonstrations. First, many bootloaders keep no persistent flash-write code at all: the flash driver is downloaded to RAM at the start of each programming session and gone after reset, so in normal operation there is simply no resident write path to flash. Second, real ECU software is not one image but several logical blocks — application, calibration, data sets — with dependencies between them, and the bootloader must enforce that mismatched combinations never run. On the production line all of this happens inside the takt time, so throughput is a design requirement, not an afterthought.

Unlocking the write path is not the same as trusting what comes through it. A production bootloader verifies the authenticity of the image itself — signed software, checked against keys the bootloader trusts — before the application is ever marked valid, and modern designs anchor those keys in a hardware security module rather than in software.

The diagnostic channel that carries the flash sequence is being re-secured too: ISO 14229-1:2020 adds an Authentication service (0x29) with certificate-based access alongside the classic 0x27 seed-and-key. We cover that side — ISO/SAE 21434, UN R155 and the shift from seed-and-key to certificates — in Securing the diagnostic channel; the point here is that image authenticity and channel security are decided inside the reprogramming sequence, not bolted on around it.

UN Regulation No. 156 requires a Software Update Management System (SUMS) for vehicle type approval: a process that knows which software versions are compatible with which vehicles, protects the integrity of updates, records every update carried out, and identifies software configurations — the RXSWIN identifier exists for exactly this. ISO 24089 describes the corresponding engineering practice. The framing matters: a bootloader and its tooling are built to support that process — supporting a regulation is not a claim of certification.

The uncomfortable discovery for many organisations is that the hard part of R156 is not the update mechanism — it is the record. Proving which software ran on which unit, when it changed and on whose approval is a diagnostics discipline: the same baseline and traceability thinking that end-of-line programming and workshop reprogramming have always needed, now made a condition of selling the vehicle. Reflashing stopped being a tool and became a managed process; the organisations that treat it that way have a much easier conversation with their approval authority.