ECU Reflashing is something quite popular among auto enthusiasts. They do it primarily to enhance the power of the vehicle or to improve the fuel efficiency. Repair shops re-flash the ECU to restore faulty ECUs or to upgrade the firmware from a new version supplied by the manufacturer may be to correct some observed issues.
In a typical setup, a flashing tool hardware will be connected to the OBD port of the vehicle and this tool does the ECU reflashing. There will be option to select the firmware file in the flashing tool. If you want to see what messages are exchanged between the ECU and the flashing tool, you can hookup a CAN Analyzer (like CANMate from us) on the CAN line and dump all the messages. You may probably get thousands of messages logged by the Analyzer and the dump would be mind boggling. This blog tries to demystify the process by explaining the messages that flows between the flashing tools and the ECUs.
Communication Message Explanation
The reflashing process is primarily governed by the ISO standard ISO15765 which is the Unfied Diagnostic Standard.
This discussion pertains to CAN bit rate is set as 500 kbps and CAN uses standard identifier (11 bit ID) although there are 250Kbps systems and 29 bit CAN IDs are also in use. The number of data bytes is always 8.
Message ID 7DF is used for functional addressing and all the ECUs on the network will respond for such a message.
Message ID 7E0 is used to physically address the Engine ECU and ECU will respond with ID 7E8.
Data Length will always be 8 bytes.D to D. High nibble (ie upper 4 bits ) of Data will determine the type of message as shown in the table below
The messages used for flashing and the relevant bytes in them are explained here. The first message send is Diagnostic session control with sub parameter as “standard diagnostic session”. The message structure send by the flashing tool is given below. X indicates don’t care and typically they are either FF or 00.
Positive reply from ECU will be of the following form.
In the positive reply, D1 will always be D1 in the command +40(hex). As you see, in this case it will be 50(hex). D2 in the reply repeats D2 in the command.
For a negative reply value of D1 will be 7F and the D2 will indicate the error code. For all the messages, reply will have this form and hence won’t be repeated in this document.
Second message is ECU identification request. Message structure is shown below.
Next message is Communication control request with sub function parameter as “Transmit disable”. This is sent to the broadcast ID 7DF and if there are multiple ECU’s all of them might respond to this.
Message format is shown below.
You will see a number of unrelated messages on the bus until this time. They are all periodic messages sent out by the ECU for the functioning of the vehicle. But after giving the positive reply for this message, ECU stops all the other communication and reserves it resources for programming operation.
Next message is Security access request with sub function parameter as “Seed request”. Message format is shown below.
Next message is Security access request with sub function parameter as “Key transfer”. This message will contain the Key related to the seed sent from ECU. Message format is shown below.
Key is generated from the seed values using a confidential algorithm provided by the manufacturer. If you don’t have this algorithm you are stuck here and you won’t be able to “unlock” the ECU for programming. This is to prevent any unauthorized access to the ECU. (Ofcourse, you can try hacking into ECU and if you want to try that, Good Luck . If you are lucky to have a working reflashig tool, there is a method, we tried to extract the key values. This will be the topic of another blog. So get tuned to this blog
Next message is Routine control request which will request ECU to execute a software routine in its memory. Message format is shown below.
Next message is Download request which will request ECU to accept data from the flashing app. It is a 2 frame message. Message format for first frame as shown below
Second frame is
After the second frame is acknowledged by ECU, the flashing operation starts. During flashing the file is broken up into chunks of 255 bytes and sent to ECU. For each chunk ECU acknowledges the correct receipt.
After flashing the entire file, the flashing app should send an “End of download message”. The format is shown below.
Hope this article helps you to get an understanding of the messages flowing between ECU and an ECU reflashing tool during an ECU firmware upgrade process.