UDS Bootloader: Diagnostic services for boot programs (ISO 14229)
KopherBit UDS Bootloader adopts the ISO 14229 (UDS) standard diagnostic service as the basis for ECU firmware burning communication. It sequentially completes the Flash erasure, writing and switching application process through SecurityAccess, RoutineControl, RequestDownload, TransferData, TransferExit, ECUReset and other services, which complies with vehicle regulations OEM Mass production and after-sales flashing requirements.
Summary
UDS Bootloader is an ECU firmware flashing mechanism based on ISO 14229 (UDS, Unified Diagnostic Services) standard diagnostic services.A complete flash process goes through DiagnosticSessionControl (0x10) → SecurityAccess (0x27) → RoutineControl (0x31) (erase) → RequestDownload (0x34) → TransferData (0x36) → TransferExit (0x37) → RoutineControl (0x31) (verification) → ECUReset (0x11) Wait for the service to complete.KopherBit provides a complete UDS Bootloader implementation in KopherBoot, compliant with ISO 14229-1, ISO 14229-3 (CAN/CAN FD) and ISO 14229-5 (DoIP/Ethernet).
Technical Role
UDS Bootloader is a small program executed by ECU under “Boot Mode (Programming Session)”. It is responsible for receiving the firmware image sent by external diagnostic tools through CAN / CAN FD / DoIP and writing it into Flash.The advantages are:
- OEM standardization process: All tools that support UDS (such as Vector CANoe, ETAS INCA, KopherUDS, and in-factory programming tooling) can be reused.
- Clear message level: UDS The message format is consistent for easy reuse across ECUs.
- Support SecurityAccess: Use Seed/Key mechanism to protect flash permissions.
- Supports large segmented transmission: Blocked transmission through TransferData, and maxNumberOfBlockLength is used to control the size of each packet.
- Also covers OEM mass production lines, after-sales maintenance, OTA back-end push and other scenarios.
Architecture
| Stage | UDS Service | Description |
|---|---|---|
| 1 | 0x10 DiagnosticSessionControl | Switch to Programming Session (sub-function 0x02). |
| 2 | 0x27 SecurityAccess | Grant flash permission through Seed/Key algorithm. |
| 3 | 0x28 CommunicationControl (optional) | Turn off non-diagnostic communication to avoid interference. |
| 4 | 0x85 ControlDTCSetting (optional) | Pause DTC logging. |
| 5 | 0x31 RoutineControl | Execute Pre-Programming Conditions Check and Erase Memory routine. |
| 6 | 0x34 RequestDownload | Declare Flash write section, addressFormat, memorySize. |
| 7 | 0x36 TransferData | Transfer firmware image in segments (each block size is limited by maxNumberOfBlockLength). |
| 8 | 0x37 RequestTransferExit | End this transfer. |
| 9 | 0x31 RoutineControl | Check Programming Dependencies / Verify CRC and signature. |
| 10 | 0x11 ECUReset | Restart the ECU and enter the new firmware. |
Supported transport layers: CAN/ISO-TP (ISO 15765-2), CAN FD/ISO-TP, DoIP (ISO 13400).
Key Capabilities
- Complete implementation of the ISO 14229 Programming Session service set.
- Supports three transport layers: CAN, CAN FD, and DoIP/Ethernet.
- Segmented transfer of large files and CRC/signature verification.
- Supports SecurityAccess Seed/Key algorithm (can be customized by OEM or adopt solution provided by KopherBit).
- Independent from the ECU main application Flash section, you can still re-enter the bootloader if flashing fails.
- Integrated with KopherSAR DCM, it can be actively triggered by the application to enter Boot Mode in the Application Session.
Engineering Inputs Required
| Input | Purpose |
|---|---|
| Flash Section Configuration | Define Bootloader, Application, Calibration, NV Data section boundaries. |
| Boot process details | Pre-Programming check, erase range, CRC/signature algorithm. |
| SecurityAccess Algorithm | OEM customized algorithm or KopherBit provides a solution. |
| Transport layer | CAN / CAN FD / DoIP, including CAN ID / routing table configuration. |
| OEM Tool Compatibility | Expected support for Tester tools (Vector / ETAS / KopherUDS). |
| OTA backend | If OTA is required, define the backend push and signature verification process. |
How KopherBit Supports This
- KopherBoot: UDS-based Bootloader provided by KopherBit, with built-in Programming Session service set, SecurityAccess, CRC/signature verification.
- KopherUDS: The host computer supports the complete flashing process and can directly verify the bootloader behavior during the development stage.
- AUTOSAR integration: Support Programming Session switching logic in Application through KopherSAR DCM.
- HSM integration: Use the built-in HSM to complete signature verification on KCU GEN2 (TC387QP), and the private key is not exposed.
FAQ
What is the difference between Programming Session and Default Session?
The Default Session is the normal operating mode of the ECU and only allows reading diagnostic data; the Programming Session switches to the Bootloader environment and allows Flash erasure and writing.Most ECUs will reboot and enter the bootloader program section when switching.
Why does SecurityAccess need Seed/Key?
Seed/Key is an OEM-customized symmetric algorithm: Tester receives the Seed → calculates the Key through the key → ECU verifies whether the Key is correct.Prevent unauthorized tools from flashing the ECU.
What happens if power is lost during flashing?
After the ECU restarts, if the Application section is not completely written, the Bootloader will detect it (usually through CRC or write completion flag) and stay in Bootloader mode waiting for re-flashing.KopherBoot This design ensures that it will not be “bricked”.
Does it support DoIP (Ethernet flashing)?
support.KopherBoot supports ISO 13400 DoIP. You can establish a Tester connection with DoIP routing through the DoIP Activation Line and then execute the UDS service.
How does CAN FD help with flashing?
CAN FD increases the amount of data per frame to a maximum of 64 bytes, and can increase the baud rate in the data phase (such as 2 Mbit/s), which significantly shortens the writing time of large files compared to CAN 2.0B (8 bytes / 500 kbit/s).
Do I need to re-verify the firmware after flashing?
yes.It is recommended to execute the Check Programming Dependencies routine after flashing is completed to perform CRC or signature verification, and restart to verify that the Application starts successfully.
JSON-LD
{
"@context": "https://schema.org",
"@type": "TechArticle",
"headline": "UDS Bootloader: Diagnostic services for boot programs (ISO 14229)",
"description": "UDS Bootloader completes the ECU firmware flashing process through the ISO 14229 service set (0x10/0x27/0x31/0x34/0x36/0x37/0x11).",
"url": "https://kopherbit.com/knowledge/uds-bootloader-diagnostic-services/",
"datePublished": "2026-05-09",
"dateModified": "2026-05-09",
"inLanguage": "zh-TW",
"keywords": ["UDS", "Bootloader", "ISO 14229", "SecurityAccess", "RequestDownload", "DoIP"],
"articleSection": "Diagnostics",
"author": { "@type": "Organization", "name": "KopherBit", "url": "https://kopherbit.com" },
"publisher": { "@type": "Organization", "name": "KopherBit", "logo": { "@type": "ImageObject", "url": "https://kopherbit.com/logo.png" } }
}