Know-how · Calibration
ECU flashing
Writing a new image to a control unit is a defined sequence, and almost every failure is a precondition that was not met rather than a transfer that went wrong.
In short
ECU flashing is the process of writing new software or calibration data into a control unit's non-volatile memory. Over UDS (ISO 14229) it follows a defined sequence: move the ECU into a programming session (0x10), unlock it with security access (0x27), optionally erase the target memory via routine control (0x31), then RequestDownload (0x34) to declare the address and size, repeated TransferData (0x36) blocks carrying the image, and RequestTransferExit (0x37) to close. A checksum or signature check usually follows before the new software is allowed to run. The ECU is normally executing a bootloader during this, not the application. Flashing writes the whole image or a defined memory region; it is not the same as changing a single calibration value online, which is done over XCP while the application runs.
01
The sequence, and why each step exists
A programming session is required because flashing must not be possible during normal operation. Security access is required because an unlocked ECU that accepts arbitrary memory writes is an attack surface. The erase routine exists because most flash memory cannot be rewritten in place without first being cleared. RequestDownload declares what is coming so the ECU can validate the address range and refuse one it does not own.
TransferData then carries the image in blocks, each with a sequence counter so a lost or repeated block is detected rather than silently accepted. RequestTransferExit closes the transfer, and a verification step — checksum, CRC or signature depending on the programme — decides whether the new software is allowed to become active.
- 0x10 — programming sessionFlashing services are unavailable outside it.
- 0x27 — security accessSeed and key; failed attempts usually trigger a lockout delay.
- 0x31 — routine controlErase the target region, and later check programming dependencies.
- 0x34 — RequestDownloadDeclares address, size and the format of what follows.
- 0x36 — TransferDataBlocks with a sequence counter; the actual payload.
- 0x37 — RequestTransferExitCloses the transfer before verification.
02
Why a flash fails
Far more often than not, the transfer was never the problem. A session that timed out because tester-present stopped. Security access refused, or a lockout still counting down from earlier attempts. An address range the ECU does not accept, because the image was built for a different variant. A voltage dip during erase, which is why bench flashing uses a stabilised supply rather than a vehicle battery.
The negative response code is the fastest route to the cause and is routinely ignored. 0x33 means the session is not unlocked. 0x31 usually means the address range is wrong. 0x72 is a programming failure inside the ECU. 0x78 is not a failure at all — the ECU is asking for more time during an erase, and a tester that treats it as an error will abort a flash that was proceeding normally.
- Stable supplyAn interrupted erase can leave an ECU that no longer boots.
- Right image for the variantAddress ranges and dependency checks are variant-specific.
- Read the NRCThe response code names the precondition that failed.
- Keep the originalThe outgoing image and its identifiers, before anything is written.
03
Flashing versus online calibration
These solve different problems and get confused constantly. Flashing writes an image into non-volatile memory, requires a programming session, and ends with the ECU restarting into new software. Online calibration over XCP changes a parameter in a running application, with no session change and no restart, which is what makes iterative tuning on a dyno possible at all.
A calibration programme uses both. Values are explored online over XCP, the resulting dataset is merged and reviewed, and a new image carrying it is produced and flashed as a release. The flash is the point at which a change stops being an experiment.
04
Where the image comes from
An image is only as trustworthy as the dataset behind it. HELIX holds the A2L description and base dataset, merges DCM, CDFX or PACO change packages from several engineers with conflict detection, runs validation gates and freezes a traceable release state before the ECU file is produced.
Hexx opens Intel HEX, S-record or raw BIN images against the matching A2L, so a changed object can be inspected in engineering units with its axes before the image is written, and checksums recomputed on save. DiagAI handles the diagnostic session itself across UDS and the transports it runs on.
The instruments
What does what.
Standards & references
Check the source.
These primary sources define the formats and regulatory context discussed above. They do not certify or endorse VehicleLab products.
Questions
Frequently asked.
What is ECU flashing?
Writing new software or calibration data into a control unit's non-volatile memory, normally through the UDS download sequence while the ECU runs its bootloader rather than its application.
What is the difference between flashing and tuning?
Flashing writes a whole image or memory region and requires a programming session and a restart. Online calibration over XCP changes a parameter in the running application with no session change, which is how values are explored before a release is flashed.
Why does an ECU refuse to flash?
Usually a precondition rather than the transfer: an expired session, security access refused or locked out, an address range the ECU does not accept because the image is for another variant, or an unstable supply. The negative response code names which.
Can flashing damage an ECU?
An interrupted erase or transfer can leave a control unit that no longer boots into its application. This is why bench flashing uses a stabilised supply and why the outgoing image and its identifiers are kept before anything is written.
Is DoIP faster than CAN for flashing?
Substantially. Ethernet removes the frame-size and bandwidth limits of CAN with ISO-TP segmentation, which is the main reason DoIP appears in production programming.
Next step
Open one of your own files with us.
Send a measurement, an A2L or an EHANDBOOK container. We will open it in the instruments on a call, with your engineers in the room.