Automotive Bootloader Complete Guide with UDS Frame Format
1 like1,804 views
The document outlines the processes involved in automotive bootloader application software downloading, detailing various file formats like versatile binary format, bin-format, intel hex format, and motorola s-format. It also discusses security access services, diagnostic session controls, negative response codes, and the significance of the request download service in reprogramming the ECU. Additionally, it highlights the routines and structure for data transfer and the requirements for successful ECU communication during software loading sequences.
![Format
Versatile Binary Format
The Versatile Binary Format or VBF is a format used by Volvo Car Corporation and
its collaborating partners [11]. The file format contains a header that contains useful
information for the software loading sequence in addition to the binary data.
BIN-format
In the BIN-format there is only the binary data without a structure, therefore it is not
possible to easily visually inspect the data as can be done with the Motorola S format
or Intel HEX. Furthermore, the format does not contain all information needed in the
software loading sequence (see Chapter 2.4.2 how this is solved in the internally
developed flashing tool).
Intel HEX format
A binary file format that is frequently used when programming or flashing
microcontrollers is the Intel HEX format. In many ways it is similar to the Motorola S-
format. Containing the same kind of fields as the S-format: Fields for record type,
byte count, address field, binary data and a checksum for each record.](https://image.slidesharecdn.com/downloadkapilnewmay24-240521200757-b2afeee2/85/Automotive-Bootloader-Complete-Guide-with-UDS-Frame-Format-3-320.jpg)
![Format
Motorola S-format
The binary data contained in the SRE-format is represented according to the
Motorola S-format. Motorola created the Motorola S-format for the Motorola 6800-
series 8-bit microprocessors in the 1970:s. The main benefit of the S-format
is that it provides a way to transport data in a way, which can be visually inspected.
The S-format file contains several lines of S-records, each S-record contains five
data fields: record type, byte count, address, binary data and checksum.
In Figure 2-5 a typical S-format file is depicted. The S0-record is the header record
for all S-format files and the S7-record is a termination record for a S-format file with
S3 data records. The S3-record contains 4 address field bytes. The address field of
the first S3 data record is used in the internally developed tool (see Chapter 2.4) to
identify which file block is being read. There are a few different record types
specified in the Motorola S-format standard with varying address field size. The byte
count is denoted in hexadecimal, in this case the S3-record is 37 bytes long (25 in
hex), included in this number the address field therefore there are 33 data bytes in
this record (37 bytes in total – 4 address field bytes = 33 data bytes in total) [9] [10] .](https://image.slidesharecdn.com/downloadkapilnewmay24-240521200757-b2afeee2/85/Automotive-Bootloader-Complete-Guide-with-UDS-Frame-Format-4-320.jpg)
![Format
A standard Intel HEX file format is depicted in Figure 2-6. Figure 2-6: A
standard Intel HEX format binary data file. All records start with a colon ":",
byte count (Red), address field (Blue), record type (Black), binary data
(Green) and a checksum (Yellow) on each record. Figure from SB-Projects
[12]. The record types most frequently used are “00” which is a standard
data record and “01” which is an end of file record [12].](https://image.slidesharecdn.com/downloadkapilnewmay24-240521200757-b2afeee2/85/Automotive-Bootloader-Complete-Guide-with-UDS-Frame-Format-6-320.jpg)
Automotive Bootloader Complete Guide with UDS Frame Format
- 1. BY KAPIL THAKAR Automotive BOOTLOADER Application Software Download 0x34 : Download 0x36 : Transfer Data 0x37 : Transfer Exit
- 2. Download Request Sequence Programming Session Request : 10 02 / 10 80 Security Access to Unlock the ECU OEM Specific Read Data By Identified Erase Request Programming Request Download Request : 0x34 Data Transfer : 0x36 Transfer Exit : 0x37 Application Validation ECU Reset
- 3. Format Versatile Binary Format The Versatile Binary Format or VBF is a format used by Volvo Car Corporation and its collaborating partners [11]. The file format contains a header that contains useful information for the software loading sequence in addition to the binary data. BIN-format In the BIN-format there is only the binary data without a structure, therefore it is not possible to easily visually inspect the data as can be done with the Motorola S format or Intel HEX. Furthermore, the format does not contain all information needed in the software loading sequence (see Chapter 2.4.2 how this is solved in the internally developed flashing tool). Intel HEX format A binary file format that is frequently used when programming or flashing microcontrollers is the Intel HEX format. In many ways it is similar to the Motorola S- format. Containing the same kind of fields as the S-format: Fields for record type, byte count, address field, binary data and a checksum for each record.
- 4. Format Motorola S-format The binary data contained in the SRE-format is represented according to the Motorola S-format. Motorola created the Motorola S-format for the Motorola 6800- series 8-bit microprocessors in the 1970:s. The main benefit of the S-format is that it provides a way to transport data in a way, which can be visually inspected. The S-format file contains several lines of S-records, each S-record contains five data fields: record type, byte count, address, binary data and checksum. In Figure 2-5 a typical S-format file is depicted. The S0-record is the header record for all S-format files and the S7-record is a termination record for a S-format file with S3 data records. The S3-record contains 4 address field bytes. The address field of the first S3 data record is used in the internally developed tool (see Chapter 2.4) to identify which file block is being read. There are a few different record types specified in the Motorola S-format standard with varying address field size. The byte count is denoted in hexadecimal, in this case the S3-record is 37 bytes long (25 in hex), included in this number the address field therefore there are 33 data bytes in this record (37 bytes in total – 4 address field bytes = 33 data bytes in total) [9] [10] .
- 5. Format
- 6. Format A standard Intel HEX file format is depicted in Figure 2-6. Figure 2-6: A standard Intel HEX format binary data file. All records start with a colon ":", byte count (Red), address field (Blue), record type (Black), binary data (Green) and a checksum (Yellow) on each record. Figure from SB-Projects [12]. The record types most frequently used are “00” which is a standard data record and “01” which is an end of file record [12].
- 7. Memory Layout Flash Memory RAM
- 8. PBL
- 9. PBL + SBL
- 10. When the ECU sends a negative UDS-response to the diagnostic tester (client) the response must include a response code on byte #3 as seen in Figure 2-17. There are some general negative response codes or NRC:s which are defined in the UDS-standard in addition to the UDS-service specific NRC:s. The NRC:s are divided into two different byte value ranges depending on the type of errors: • 0x01-0x7F – Communication related NRC:s. • 0x80-0xFF – NRC:s which are sent for specific conditions which are not correct at the time when the request is received by the server. General negative response codes
- 11. NRC : commonly used NRC in the software loading sequence
- 12. NRC(s) General Reject (0x10): Should only be used if none of the NRCs defined in the UDS-standard meet the requirements of the implementation. Service Not Supported (0x11): Should be sent when the ECU receives a UDS-service request with an SID which is unknown or not supported. Sub-function Not Supported (0x12): Should be sent when the ECU receives a UDS-service request with a sub-function which is unknown or not supported. Incorrect Message Length Or Invalid Format (0x13): Should be sent when the length or format of the received request message does not match what is specified by service.
- 13. NRC(s) Conditions Not Correct (0x22): Should be sent when the prerequisite conditions are not correct. Request Sequence Error (0x24): Should be sent when the ECU expected a different sequence of messages than what was sent by the tester. Request Out Of Range (0x31): Should be sent when the tester requests modifying a value which it does not have authority to change. Security Access Denied (0x33): Should be sent when the security requirements of the ECU are not fulfilled for the current request. General Programming Failure (0x72): Should be sent when the ECU has noticed an error while programming or erasing memory.
- 14. NRC(s) Request Correctly Received - Response Pending (0x78): Should be sent when the request is correctly formulated, but the server has not yet completed the required actions. This NRC is supported in all UDS services.
- 19. Diagnostic Session Control : Programming session Request
- 20. Diagnostic Session Control : Programming session Response
- 22. ECU Reset service: Request The UDS-service ECU Reset is used to perform a reset of the ECU. This service is usually used in post-programming after a reprogramming of an ECU. There are several sub-functions defined in the UDS-standard but only the sub-function “Hard Reset” is used in the software loading sequences used. After ECU Reset has been performed the ECU should enter the default session.
- 23. ECU Reset service: NRCs
- 24. Security Access Service In order to prevent unauthorized access to the ECU the vehicle manufacturers implement the Security Access service, which is specified in the UDS-standard. Generally, security access is required before any transfer of new software to the ECU can be performed. The Security Access service utilizes a seed and key structure; the tester (client) will request security access with a UDS-request (see Figure 2-24).
- 26. Security Access service If the security key returned by the tester (client) is correct the ECU will respond with a positive UDS-response (see Figure 2-27). After this the tester will be granted security access at the requested security level. The vehicle manufacturers have the option of adding different security levels to differentiate what level of access is given to the user of the security access. Different levels of security access can be implemented by using different sub-function byte values to symbolize different levels of security. The relation between the request seed request and send key request is fixed so that if the request seed byte value is 0x01 then the send key byte value will be 0x02. If the request seed byte value is 0x03 then the send key byte value will be 0x04.
- 30. NRC(s)
- 31. NRC(s) Invalid Key (0x35): Sent if the security key sent by the tester (client) does not match the expected key value. Exceeded Number Of Attempts (0x36): Sent if a delay timer is active due to too many incorrect send key Security Access requests. Required Time Delay Not Expired (0x37): Sent if the delay timer is still active.
- 32. Read By Identifier service Service to read data at a memory location specified, used in a flashing sequence to read programming-, fingerprint-data and prepare the ECU for reprogramming. It is a vehicle manufacturer specific step that is sometimes included in the preprogramming part of the software loading sequence.
- 33. Read By Identifier service : NRCs
- 34. Read By Identifier service : NRCs
- 35. Write By Identifier service The Write By Identifier service is used to write data to a specific memory location, for example writing programming date and fingerprint data. Typically this is done right before transferring data to the ECU and/or after a successful software loading sequence. An example of a Write By Identifier UDS-request
- 36. WriteData By Identifier service : Request
- 37. WriteData By Identifier service : NRCs
- 38. Routine Control Service The Routine Control service is one of the most flexible services in the UDS standard. It is typically used in the software loading sequence to check programming pre-conditions and disable failsafe reactions in pre-programming (see Chapter 2.8.4). Also used for performing erasure of EEPROM or flash memory before downloading a new block, checking for valid flash memory and application after the transfer of data. The structure of a routine control service is shown in Figure 2-32. One of the Routine Control services defined in the UDS-standard is the Erase Memory or Erase Flash routine. It will perform the erasure of EEPROM and flash memory before loading a new block. It has the routine identifier FF01, specified on bytes #3-4 in the UDS-request. The remaining bytes of the request contain a routine control option record which is of variable length depending on vehicle manufacturing specification and which routine identifier is used. An example of a start Erase Flash Routine Control service is shown.
- 40. Routine Control Service: Request
- 41. WriteData By Identifier service : NRCs
- 42. Request Download service The Request Download service together with Transfer Data and Request Transfer Exit constitute the main components of the actual transfer of new block data to a reprogrammable ECU. A Request Download UDS-request contains information of which memory address the data block should be downloaded to, how large the data block is in bytes and if the data block is encrypted and/or compressed. The structure of a Request Download UDS-request can be seen. The data format identifier specifies if data is encrypted and/or compressed. The address and length format identifier specifies the size of the memory address and size fields in bytes. The memory address indicates where the data should be written and memory size specifies how many bytes are in the block to be downloaded.
- 43. Request Download
- 44. Request Download
- 45. Request Download: Response The response from a Request Download UDS-request contains information about how large Transfer Data requests are accepted by the ECU. The UDSstandard requires that the ECU must be able to accept at least a Transfer Data request of the length specified by the “MaxNumberOfBlockLength” contained in the response. Transfer Data requests of shorter length than what is indicated by the “MaxNumberOfBlockLength” are vehicle manufacturer specific if they accept or not. However, the last Transfer Data message may contain less than the maximum size of data packages, which must be handled by the ECU according to the UDSstandard.
- 49. Transfer Data - 0x36
- 50. Transfer Data - 0x36
- 51. Transfer Data - 0x36 Transfer Data Suspended (0x71): If the memorySize (see Figure 2-34) parameter in the Request Download request does not match the number of bytes sent by the Transfer Data requests this NRC should be sent by the ECU. • Wrong Block Sequence Counter (0x73): If the ECU notices an error in the “block Sequence Counter ” sequence then it should send this NRC. • Voltage Too High / Voltage Too Low (0x92/0x93): Should be sent if the voltage measured by the ECU are outside of the permitted range for a software loading sequence
- 55. Questions?
- 56. Service: Request Download – 0x34 0x10 0x09 0x34 AA AA AA AA BB 0x30 0x00 0x00 Pad Pad Pad Pad Pad 0x21 0xBB 0xBB 0xBB Pad Pad Pad Pad 0x04 0x74 0xCC 0xCC Pad Pad Pad Pad 1. Compression format support 2. Address / Length Specifier can be used Tester : ECU : Tester : ECU :
- 57. Service: Data Transfer – 0x36 0x02 0x36 0x01 0x7F 0x10 0x22 0x7F 0x10 0x22 0x7F 0x10 0x22 0x7F 0x10 0x22
- 58. Service: Transfer Exit – 0x37 0x7F 0x10 0x22 0x7F 0x10 0x22 0x7F 0x10 0x22 0x7F 0x10 0x22 0x7F 0x10 0x22