UDS ECU Flashing Sequence: From Programming Session to ECU Reset

An automotive ECU may need new software to correct a fault, improve functionality, or support an updated vehicle configuration. But how does a diagnostic tool transfer firmware to an ECU without accidentally overwriting important memory or leaving the controller unable to start?

The answer lies in a controlled programming process known as the UDS ECU flashing sequence.

Unified Diagnostic Services (UDS), defined by ISO 14229, provides diagnostic services used by a tester to communicate with electronic control units. These services can support software reprogramming through a suitable ECU bootloader.

During flashing, the tester does more than transmit a firmware file. It establishes the correct diagnostic session, obtains programming authorization, prepares the memory, transfers data in controlled blocks, verifies the programmed image, and requests an ECU restart.

This article explains how the UDS ECU flashing sequence works, why each diagnostic service matters, and how engineers troubleshoot failed firmware updates.

1. What Is the UDS ECU Flashing Sequence?

The UDS ECU flashing sequence is a coordinated series of diagnostic requests and responses used to transfer firmware or other supported data into an ECU’s programmable memory.

A typical programming arrangement contains three major elements:

• Diagnostic tester: A PC application, service tool, or automated programming system that controls the update.
• Communication transport: A supported network such as CAN with ISO-TP or Ethernet with DoIP.
• ECU bootloader: Firmware responsible for accepting authorized programming requests, managing flash memory, checking transferred data, and controlling application startup.

The tester acts as the diagnostic client, while the ECU acts as the diagnostic server.

UDS defines the diagnostic communication services. The ECU manufacturer determines the flash memory layout, programming conditions, security configuration, erase routines, image format, and software activation rules.

Therefore, the UDS protocol provides a common foundation, but there is no single universal programming script that works with every automotive ECU.

2. Why Does an ECU Need a Bootloader?

Most microcontrollers cannot safely overwrite application flash without following hardware-specific programming requirements.

Erase operations may affect entire flash sectors, programming can take significant time, and execution from a memory bank being modified may be restricted.

A UDS Bootloader manages these operations while maintaining diagnostic communication with the external tester.

Typical bootloader responsibilities include:

• Receiving supported diagnostic programming requests.
• Checking programming authorization and operating conditions.
• Protecting bootloader and configuration memory.
• Erasing permitted application flash regions.
• Programming incoming firmware data.
• Checking image integrity and, where required, authenticity.
• Determining whether an application is valid for execution.
• Supporting recovery after interrupted programming.

Bootloader architecture matters because losing power during a firmware update can leave an incomplete application image.

A robust design should preserve an available recovery mechanism and prevent unverified firmware from being treated as valid application software.

For related learning topics, see the Embedded Bootloader Development Course at PiEST Systems.

3. UDS ECU Flashing Sequence: Ten Main Steps

A practical ECU Flash Programming workflow can be divided into ten stages.

Step	Diagnostic service	Purpose
1	0x22 or configured checks	Identify the ECU and verify programming conditions
2	0x10	Enter an appropriate diagnostic session
3	0x27 or supported authorization	Obtain programming permission
4	0x31	Run a supported flash preparation or erase routine
5	0x34	Request a firmware download
6	0x36	Transfer firmware data blocks
7	0x37	Terminate the transfer operation
8	0x31	Verify programmed data and dependencies
9	0x11	Request an ECU reset when permitted
10	0x22 and functional tests	Confirm application startup and software identity

This table represents a common engineering workflow, not a mandatory ISO 14229 sequence. Some manufacturers require additional diagnostic services or different ordering.

For example, an ECU may first enter an extended diagnostic session, disable selected communications, or stop diagnostic trouble code recording before entering the programming session.

4. Step One: Check ECU Identity and Programming Conditions

Before changing ECU software, the tester needs to know what controller it is communicating with.

The tool may read identifiers through ReadDataByIdentifier (0x22), including supported software versions, ECU identification data, or diagnostic configuration information.

The actual identifiers are manufacturer-defined or standardized according to their respective specifications.

The programming tool must also check whether the operating environment permits an update.

Examples include:

• Correct ECU and target software package.
• Stable electrical supply.
• Permitted vehicle operating state.
• Valid diagnostic communication.
• Compatible firmware and hardware variants.
• Required programming authorization.

The ECU itself should enforce critical programming conditions. A tester-side warning alone is not adequate protection.

5. Step Two: Enter Programming Session with UDS 0x10

DiagnosticSessionControl (0x10) changes the diagnostic session used by the ECU.

The programming session is commonly requested using:

Tester request:
10 02

ECU positive response:
50 02 ...

The request contains:

• 10: DiagnosticSessionControl service identifier.
• 02: Programming session subfunction.

The positive response begins with 50 02. Depending on the applicable UDS specification and configuration, additional bytes convey diagnostic timing information.

Some ECUs require an extended session before programming. Others change execution context or restart into a dedicated bootloader when programming is requested.

That transition is an implementation detail, not an automatic result guaranteed by the service identifier alone.

Why are diagnostic sessions necessary?

Normal vehicle operation and flash programming need different permissions.

In the default diagnostic session, an ECU may permit routine diagnostic reads while rejecting memory programming requests.

The programming session makes an appropriate programming workflow available, subject to the ECU’s additional security and condition checks.

6. Step Three: Obtain Programming Authorization

Many traditional UDS Bootloader implementations use SecurityAccess (0x27) to protect sensitive operations.

The diagnostic tester requests a seed. The ECU returns challenge data, and the tester calculates a corresponding key using an authorized mechanism.

For one commonly used security level, the requests may resemble:

Tester:
27 01
Request seed

ECU:
67 01 [seed bytes]

Tester:
27 02 [key bytes]
Send authorized key

ECU:
67 02
Positive response

The seed and key values are deliberately omitted. They are specific to the ECU security implementation and must not be replaced with arbitrary values.

The standard diagnostic service defines the request-and-response structure. It does not provide a universal seed-to-key algorithm for every manufacturer.

Modern diagnostic systems may also support other authorization mechanisms, including certificate-based authentication, depending on the platform and OEM design.

SecurityAccess alone does not establish firmware authenticity. A properly protected bootloader may separately verify a digital signature or another approved authenticity mechanism before activating an application image.

7. Step Four: Prepare and Erase Flash Memory with RoutineControl 0x31

Before new firmware is programmed, the target memory region may need to be erased.

Automotive bootloaders commonly use RoutineControl (0x31) to invoke a configured erase operation.

A generic StartRoutine request has the structure:

31 01 [RID high] [RID low] [parameters]

Here:

• 31 identifies RoutineControl.
• 01 requests the start of a routine.
• RID identifies the configured routine.
• Optional parameters provide additional routine information.

The erase Routine Identifier is not universal. The ECU supplier or manufacturer defines the supported routine and its parameters.

A positive response normally begins with 71 01 followed by the relevant routine identifier and optional response data.

What happens inside the ECU?

The bootloader validates the requested memory region and checks whether programming is permitted.

It then invokes the appropriate flash driver operations, which can involve unlocking a flash controller, erasing sectors, waiting for completion, and checking hardware status.

Protected areas such as bootloader code, calibration regions, or persistent configuration must not be erased unless the approved update architecture explicitly permits it.

Flash erasing is not identical to writing. On many devices, erasing prepares memory cells for subsequent programming operations, while programming writes the new information into that region.

8. Step Five: UDS RequestDownload 0x34

UDS RequestDownload 0x34 tells the ECU that the tester intends to begin a data transfer.

The request identifies the transfer characteristics, including the target memory address and intended data size.

A typical request is structured as:

34 [DFI] [ALFI] [memoryAddress] [memorySize]

The fields mean:

• 34: RequestDownload service.
• DFI: Data Format Identifier, which describes supported compression or encryption formatting.
• ALFI: Address and Length Format Identifier, defining the sizes of the memory address and memory size fields.
• memoryAddress: Target starting address.
• memorySize: Number of bytes associated with the requested download.

The ECU must verify that the requested range is valid and that the requested operation is permitted.

What does the ECU return?

A successful RequestDownload response begins with 0x74 and includes information describing the maximum permitted TransferData message length.

This allows the tester to choose data blocks that fit the ECU’s supported diagnostic transfer limits.

The maximum number of bytes accepted in a TransferData request must be interpreted according to the relevant protocol field definition. The tester must account for the diagnostic message overhead, not merely the firmware payload length.

Important: RequestDownload initiates the transfer process. It does not by itself prove that the firmware has been programmed successfully.

9. Step Six: UDS TransferData 0x36

UDS TransferData 0x36 carries the firmware content in successive diagnostic blocks.

Each request includes a Block Sequence Counter (BSC), allowing the ECU to track the expected transfer order.

A simplified transfer is:

Tester:
36 01 [Firmware block 1]

ECU:
76 01

Tester:
36 02 [Firmware block 2]

ECU:
76 02

Tester:
36 03 [Firmware block 3]

ECU:
76 03

The response service identifier is 0x76.

For a new transfer, the first block sequence counter normally starts at 0x01. The counter increments modulo 256, meaning that after 0xFF it rolls over to 0x00.

The ECU should validate the expected sequence and apply the transfer rules required by the diagnostic implementation, including permitted handling of repeated blocks.

How does firmware reach flash memory?

The received diagnostic data may be collected in a RAM buffer or passed through another controlled programming path.

The bootloader uses the appropriate flash driver to program the destination memory.

The permitted buffer sizes, address alignment, programming granularity, and write timing depend on the microcontroller and memory technology.

Consequently, ECU Flash Programming must respect both the UDS transfer protocol and the flash controller’s hardware requirements.

UDS blocks are not ISO-TP frames

This distinction is especially important when flashing over CAN.

A UDS TransferData request is a diagnostic message. If that message exceeds the payload capacity of a single CAN transport frame, ISO-TP segments it across multiple CAN frames.

ISO-TP defines:

• Single Frame (SF).
• First Frame (FF).
• Consecutive Frame (CF).
• Flow Control Frame (FC).

The ISO-TP flow control block size and separation time govern transport-frame transmission. They do not replace the UDS Block Sequence Counter.

An engineer debugging a failed download should therefore distinguish a UDS transfer-block error from an ISO-TP flow-control or consecutive-frame error.

10. Step Seven: Finish the Transfer with UDS 0x37

After the tester sends the expected data, it requests completion through RequestTransferExit (0x37).

A basic exchange can look like:

Tester:
37

ECU:
77

The request and response can also contain configured parameters.

RequestTransferExit indicates the end of the current diagnostic data transfer. Its exact processing and any associated checks depend on the ECU implementation.

It should not be assumed that a positive 0x77 response always proves image authenticity, programming compatibility, or successful application startup.

Many systems perform further checks before marking the application valid.

11. Step Eight: Verify the Programmed Firmware

After the transfer, the bootloader may execute an image verification routine using RoutineControl (0x31).

The verification mechanism may involve:

• Checking the expected image length.
• Comparing a checksum or CRC.
• Checking programmed memory regions.
• Validating software compatibility or programming dependencies.
• Verifying a digital signature where required.
• Updating image validity metadata only after successful checks.

A CRC is useful for detecting accidental corruption. It is not equivalent to cryptographic authentication.

A secure software-update design must distinguish data integrity from authenticity and authorization.

The check-memory routine identifier, its parameters, and its response format depend on the ECU supplier and the applicable programming specification.

Why are programming dependencies important?

Some ECUs store multiple software components or data blocks that must work together.

For example, an application and its calibration data may require compatible versions. A gateway controller may also contain separate software and configuration regions.

The programming workflow must verify these relationships before allowing the updated application to run.

12. Step Nine: Request ECU Reset with UDS 0x11

Once programming and the required checks are complete, the tester may request an ECU reset.

A common example is:

Tester:
11 01

ECU:
51 01

The request 11 01 selects the hard-reset subfunction.

However, the precise reset behavior, response timing, bootloader exit conditions, and subsequent application startup depend on the ECU implementation.

After reset, the bootloader or startup logic may check the installed software image and determine whether execution can proceed.

A correct design must not blindly jump to an application whose integrity or required validity conditions have not been established.

13. Step Ten: Verify the Updated ECU Application

The last step in Automotive ECU Reprogramming is confirming that the updated controller operates correctly.

Simply receiving a positive reset response is insufficient.

The tester should reconnect if necessary and perform the checks defined by the project.

Possible verification activities include:

• Read the active software version.
• Confirm the ECU enters its intended operating mode.
• Check relevant diagnostic services.
• Verify expected communication messages.
• Evaluate startup and fault behavior.
• Confirm required application functions.
• Preserve the programming log and test evidence.

Only after these checks can the update be evaluated against its defined acceptance criteria.

14. Example UDS ECU Flashing Sequence: Request and Response Trace

The following example shows a simplified diagnostic transaction sequence. It is intended to explain the request and response identifiers, not to program an unspecified ECU.

Activity	Request	Typical response
Enter programming session	10 02	50 02 ...
Request seed	27 01	67 01 [seed]
Send authorized key	27 02 [key]	67 02
Start erase routine	31 01 [RID] [parameters]	71 01 [RID] ...
Request download	34 [DFI] [ALFI] [address] [size]	74 ...
Transfer block 1	36 01 [data]	76 01
Transfer block 2	36 02 [data]	76 02
End transfer	37	77
Verify software	31 01 [RID] [parameters]	71 01 [RID] ...
Reset ECU	11 01	51 01

The trace deliberately omits actual flash addresses, seed/key values, and OEM Routine Identifiers. These depend on the target ECU.

During a real programming operation, each request must also comply with the applicable diagnostic session, security state, timing limits, transport rules, and memory configuration.

15. Understanding Negative Response Codes During Flashing

The ECU can reject a programming request when a required condition is not satisfied.

A UDS negative response generally has the structure:

7F [Requested SID] [NRC]

For example:

7F 34 22

This indicates that a RequestDownload operation was rejected with NRC 0x22, ConditionsNotCorrect.

NRC	Meaning	Engineering interpretation
0x13	IncorrectMessageLengthOrInvalidFormat	Request format needs investigation
0x22	ConditionsNotCorrect	Required programming conditions are not satisfied
0x24	RequestSequenceError	A prerequisite operation or request order is incorrect
0x31	RequestOutOfRange	A parameter or range is not permitted
0x33	SecurityAccessDenied	Required security conditions are not satisfied
0x35	InvalidKey	Submitted security key is not accepted
0x36	ExceedNumberOfAttempts	Security attempt limit has been reached
0x37	RequiredTimeDelayNotExpired	Required security delay remains active
0x70	UploadDownloadNotAccepted	Requested transfer cannot be accepted
0x71	TransferDataSuspended	Transfer operation cannot continue
0x72	GeneralProgrammingFailure	Programming operation failed
0x73	WrongBlockSequenceCounter	Block sequencing requires investigation
0x78	ResponsePending	ECU is processing the request

Not every NRC is applicable to every service. Always interpret an actual negative response in the context of the requested service and ECU diagnostic specification.

What does response pending mean?

Flash erasing and programming can take longer than ordinary diagnostic operations.

An ECU may send NRC 0x78 to indicate that the request has been received and processing is continuing.

The tester must respect the configured diagnostic response timing and wait for the final result according to the supported protocol behavior.

It should not interpret every delayed response as a failure or restart the programming operation without evaluating the current transfer state.

16. UDS Flashing over CAN, CAN FD and DoIP

The UDS services involved in firmware programming describe diagnostic operations, not the physical communication medium.

UDS over CAN

When diagnostic messages are carried over CAN, ISO-TP provides the segmentation and flow-control mechanisms needed to transport messages larger than a single CAN frame.

Each UDS TransferData message may itself be carried in one or multiple ISO-TP frames.

UDS over CAN FD

CAN FD permits larger data payloads at the CAN frame level, but the programming workflow must still follow the configured transport and diagnostic limitations.

The actual improvement in programming performance depends on ECU processing, bus configuration, flash write behavior, transfer sizes, and test equipment.

UDS over DoIP

Diagnostics over Internet Protocol (DoIP), defined by ISO 13400, carries diagnostic communication using IP-based network services.

DoIP can support firmware programming through Ethernet-based diagnostic connections, subject to the ECU’s implemented diagnostic services and security requirements.

Changing from CAN to DoIP does not remove the need for correct firmware compatibility, programming authorization, flash protection, and post-programming verification.

17. Common ECU Flash Programming Failures

A useful debugging method is to identify the last successfully completed service and examine the ECU’s response together with the transport log.

Failure	Possible cause	What to inspect
Programming session rejected	Incorrect state or unsupported request	Session prerequisites and ECU conditions
Security access fails	Authorization or sequence issue	Security level, permitted attempts and timing
Erase routine fails	Invalid range or flash controller failure	Memory map, protections and flash driver status
RequestDownload rejected	Unsupported format or memory region	Address, length, DFI and ALFI
TransferData fails	Block sequencing, transport or programming issue	BSC, diagnostic log and flash write status
TransferExit rejected	Incomplete transfer or format mismatch	Transfer state and received data count
Verification fails	Incorrect image or corrupted data	Image metadata, integrity checks and compatibility
ECU does not restart	Invalid image or startup configuration	Boot decision, reset reason and recovery state

Importantly, a diagnostic failure is not always caused by incorrect application firmware.

Transport timeouts, incorrect block sizes, electrical supply interruptions, memory alignment errors, and inconsistent programming metadata can also interrupt the update process.

18. How Can a Bootloader Recover from Interrupted Flashing?

Firmware updates must account for power loss, communication interruptions, and incomplete transfers.

One common design principle is to avoid marking an application as bootable until its required verification steps have succeeded.

Depending on the ECU architecture, recovery strategies may include:

• A protected recovery bootloader.
• Separate application-validity metadata.
• Dual-bank or A/B firmware storage.
• Persistent transfer state where supported.
• Authenticated image validation.
• Controlled recovery programming sessions.

Not every microcontroller supports dual-bank programming, and maintaining a safe recovery path requires careful architecture and validation.

Even when a bootloader can recover from an interrupted transfer, it may not be able to resume at the exact interrupted block. The supported recovery process must be defined by the ECU design.

19. How Engineers Validate a UDS Bootloader

Testing only one successful programming sequence is insufficient.

A well-defined ECU testing plan should cover normal programming, invalid requests, interruptions, memory boundaries, authorization failures, and application startup.

Representative test scenarios include:

• Successful programming of a compatible image.
• RequestDownload before the required authorization.
• Incorrect or unsupported download address.
• Firmware size exceeding the permitted region.
• Wrong block sequence counter.
• Interrupted ISO-TP transfer.
• Power interruption during an approved recovery test.
• Invalid image integrity check.
• Reset request before programming is complete.
• Recovery and successful programming after a previous failure.

Any fault-injection or interrupted-power test should be performed on an appropriate development bench with a documented recovery plan.

Test results should include the ECU software identity, firmware package, diagnostic session, request and response log, test conditions, and final application status.

This is where automated diagnostics and embedded testing tools become valuable for Automotive ECU Reprogramming.

20. Frequently Asked Questions About UDS ECU Flashing

21. Conclusion: Understanding the UDS ECU Flashing Sequence

The UDS ECU flashing sequence is more than a series of hexadecimal service identifiers.

It is a controlled programming workflow involving diagnostic permissions, memory management, transport handling, data integrity, firmware compatibility, and safe application startup.

The programming session establishes an appropriate diagnostic context. Authorization protects sensitive operations. RoutineControl prepares and verifies memory, while RequestDownload, TransferData, and RequestTransferExit coordinate the firmware transfer.

Finally, ECU Reset and post-programming tests help establish whether the updated application operates as expected.

For embedded software and automotive testing engineers, understanding these dependencies is essential when developing UDS Bootloader software, troubleshooting ECU Flash Programming failures, and validating reliable firmware-update workflows.

Learn ECU Bootloader and UDS Development at PiEST Systems

PiEST Systems provides engineering training covering embedded systems, automotive diagnostics, ECU software development, bootloaders, and test workflows.

Explore the Embedded Bootloader Development Course or browse our Automotive and Embedded Systems Training Programs.

Engineering teams can also contact PiEST Systems to discuss embedded software development, integration, diagnostics, and testing requirements.

Technical References

• ISO 14229-1:2026, Unified Diagnostic Services, Application Layer
• AUTOSAR Classic Platform R21-11, Diagnostic Communication Manager Specification
• AUTOSAR Foundation, Requirements on Diagnostics
• Linux Kernel Documentation, ISO 15765-2 Transport Protocol
• ISO 13400-2:2025, Diagnostic Communication over Internet Protocol