As an automotive engineer, manager, executive or technician, you have heard this one before: Electronic Control Unit (ECU) software reflash. Whether it’s for a bug fix or recalibration for enhanced system operation, it is a very common occurrence; it can also be a very timely one. How can we reduce the reflash time and regain the lost reflashing resources?

Let’s take a high level look at the typical reflashing process: There are partitions of the ECU’s memory (like the C:\ drive of your PC for Windows users) that have specific programming for proper operation. These partitions may be as small as 100 kilobytes or as large as 40 megabytes (or even larger!). Maybe you have experienced the time it takes to reflash a head unit with a considerable memory map. I have experienced some head unit reflashes that take as long as an hour and a half! Why does it take so long? Typical reflashes replace the whole memory partitions, even though just a portion of the new software has been changed.

Exclusive Origin has a Diff File Creation algorithm that compares the old and new software and generates a reflash strategy that only replaces the altered memory in the ECU. This allows for faster reflash activities. How much faster? If only 10% of the software was altered in the hour and a half flash I witnessed, it would only take approximately 15 minutes. And you know the saying—Time is Money!


The majority of the autospace leverages Unified Diagnostic Services, also known as UDS, as the primary mode for installing new software into an ECU for production vehicles. Much of the industry refers to this as reflashing. Perhaps this term has carried over from decades past, when the actual microcontrollers had to be removed from the circuit and “flashed” by a tool, commonly referred to as a ”chip burner”.

For those not privy to UDS, here’s a few important tidbits that will be helpful to this post, and a couple bonus points, too. Unified Diagnostics Services:

·       is an ISO standard (ISO 14229) protocol ;

·       defines Application Layer(7) and Session Layer(5) services in accordance to the OSI model;

·       outlines how an ECU (ISO refers to an ECU as a “server”) and a diagnostic tester (and ISO refers to the tester as the “client”) manage communications;

·       refers to each communication type as a service;

·       supports many networks, including Controller Area Networking, or CAN;

·       was first released in 2006.


It is important to understand and remember that UDS offers guidelines to flash reprogramming ECUs, not one hard and fast process. Automotive OEMs have different flavors of the protocol; it is not a one-size-fits-all. You can think of UDS being a language like English, German or Spanish- different regions have different vernaculars, and so is true for Automotive OEMs.

UDS outlines and specifies many diagnostic parameters, but we’re going to take a look at the process of installing software as per UDS protocol.

UDS protocol defines a set of processes it deems necessary when performing ECU programming. It is broken down into two phases, and each phase contains a list of services. Some of these services are mandatory, and others are optional; each OEM has their own implementation. Let’s take a look at these two phases, and break down the services in each. The services below follow a template I have created:

SessionName(whether it is ISO or OEM defined)-OPTIONAL or MANDATORY implementation- input from yours, truly.


Pre-Programming Phase

1.       DiagnosticSessionControl(ISO)-MANDATORY- Informs the ECU that the test tool will be beginning a diagnostic interchange, and the ECU will return important data about the session, such as timing limits. You can imagine this similar to how you might say to someone, “Hello! Do you have a moment to speak?” and they may return, “Sure! I have a moment.”

2.       CommunicationControl(OEM)-MANDATORY- Switches off any normal operation CAN message broadcasts. This reduces the bus load and may allow for a faster programming routine.

3.       RoutineControl(OEM)-OPTIONAL-Switches off any safety interjections that may be inadvertently triggered during the programming phase, or perhaps to perform a necessary OEM specific task.

4.       ControlDTCSetting(ISO)-MANDATORY- Switches off raising any Diagnostic Trouble Codes (DTCs) during the programming process.

5.       ReadDataByIdentifier(OEM)-OPTIONAL-May be implemented by the OEM to check which software level is currently installed in the ECU before beginning the programming process.

6.       LinkControl(ISO)-OPTIONAL- Changes the bitrate of the CAN channel. So, if the ECU’s CAN network communicates at a 125k bitrate, we could possibly increase the bitrate to 1m (so long as the ECU’s clock oscillator is up to the task, but that’s another conversation entirely). I have not seen the utilization of this service very often, which strikes me as odd, however I am sure it is not without reason. With the continuing trend decreasing costs in microcontroller memory, and increasing complexity and sum of code size altogether, I would imagine implementing the CAN FD protocol would be very likely.

Programming Phase

1.       DiagnosticSessionControl(ISO)-MANDATORY-As stated above, basically just a handshake of sorts

2.       SecurityAccess(ISO)-OPTIONAL-Protects the ECU firmware from any malicious attempts of alteration. The security method is of the seed-key type: (1) the tester requests a seed, (2) the tester is required to perform an algorithmic task upon the seed to generate the key, while the ECU is also privately performing this task, (3) the tester returns the key to the ECU, and if it matches with the key the ECU has calculated, access is granted. ISO states this is mandatory for any theft, emission, or safety related devices, however it is widely implemented due to the nature of possible security breaches. Also, the size of seeds and their keys are optional; some ECUs may incorporate a 24-bit seed/key, whereas others may be as long as 64-bits. This section of UDS may change soon, though, with numerous security breaches, some even headlining the media. One possibility could be what Jihas Kahn, of Tata Elxsi Ltd., has proposed with Advanced Encryption Standard (ADESTA) for Diagnostics over CAN. Time will tell.

3.       WriteDataByIdentifier(OEM)-OPTIONAL-Writes a “fingerprint” on the ECU. This is a log of the machine’s identity (again OEM specific), and current time and date, amongst other possibilities of data.

4.       RequestDownload(OEM)-MANDATORY- I know what you’ve been thinking, when do we actually start pushing our binary into the ECU? Well, here’s where we finally begin. This service asks the ECU if the binary can be shuffled in at a specific start address of the ECU’s memory map and the size of the binary. There is a byte in this service reserved for the OEMs to allow for binary compression and encryption, as well. The ECU will return the maximum number of bytes it can digest at a time, or block length. That variable will be used for the service below.

5.       TransferData(OEM)-MANDATORY- Transfers the binary file in by two bytes short of the maximum block length (the first two bytes are reserved for the UDS service) using CAN Transport Protocol, or ISO 15765. This service is reused until all the bytes of the binary have been pushed in.

6.       RequestTransferExit(OEM)-MANDATORY- tells the ECU that we have completed uploading the binary.

7.       RoutineControl(OEM)-OPTIONAL- Depending on the OEM, this service is used to check that the binary was received correctly by performing some sort of check, like a Cyclic Redundancy Check (CRC) or similar.

8.       ECUReset(ISO)-MANDATORY-Reboots the ECU to execute the new firmware that was just installed

As you can see, there can be many variants, and in fact, there are. There is no one-size-fits-all. What would be the fun in that, anyway?!

I hope you enjoyed this not-so-brief explanation. If you would like more information on ECU reflashing and automotive electronic technology, be sure to check out more posts on our blog. UDS reflashing solutions? Yeah, we have that covered, too. Do-it-yourself or turn-key solutions. Come check out what we have to offer!


Professionals in the world of Controller Area Network (CAN, or CAN bus) embedded electronics development and design are most probably familiar with Vector and their CAPL programming, but oddly enough, are not familiar with Kvaser’s t Script. Why? Well perhaps its due to Kvaser’s t Script functionality is relatively new, or maybe because it’s not properly leveraged. Let’s scratch the surface shall, we?

Vector set off to create a system that allows for more direct control of and access to CAN nodes, or ECUs. This resulted in CAPL, a C -based programming language that is based on event handling. Although it may be referred to a scripted language, which means it is compiled at runtime, CAPL is compiled just before runtime.

CAPL has proven itself as a powerful resource for an overwhelming number of organizations which develop, produce, and test embedded systems.

Kvaser’s t Script functionality is relatively new to the game. Similar to CAPL, it is designed to handle events, as that’s the nature of embedded systems. It is C -based (probably no surprise here), and is not a scripted language; it is compiled.

I have developed a wealth of t Script experience and products, some of which I offer here. I can say that this system is a force to be reckoned with; a sleeping giant, if you will. The potential is motivating.

The similarities and parallels these two systems share are not well known. Recently, I tested the portability of CAPL code to t Script, and it is surprisingly portable. The syntax is different, but there’s much potential here that I believe no one has caught on to.


Are you interested in porting your Vector CAPL code to Kvaser’s t Script? Please contact me with your thoughts. If there is interest in this strategy, maybe I will offer a utility to port your CAPL to t Script!