Request Download (0x34) Service: UDS Protocol

Introduction To Request Download (0x34) Service

The Request Download (0x34) is one of the most important services in the UDS protocol. It is helping in any data transfer from an external diagnostic tool to your vehicle ECU. This Request Download service together with Transfer Data (0x36) and Request Transfer Exit (0x37) constitute the main components of the actual transfer of new block data to a re-programmable ECU.

The use of this service is to download new software or any data set, or calibration parameters, etc. from any external computer. This external computer will be having OEM-designed diagnostic software. This software basically called Diagnostic Engineering Tool (DET).

The definition of the request download (0x34) service is to request or initiate the download service by a client to the server about the data transfer.

Request Download (0x34) Service Request Frame Format

The Request Download UDS service contains the information. This defines which memory address the data block should be downloaded. How large the data block is in bytes, and if the data block is encrypted or not & also compressed or not. If it is encrypted then what kind of encryption is being used. If it is compressed then what type of compression method is used.

The below table shown the frame format of Request Download Service general standard request frame format defined as per the ISO-14229 standard.

Request Download Request SID (Byte-1):

The Request Download Service Identifier is the first byte of Diagnostic Data in UDS Protocol. This defines the type of service that should be requested by the client to the server.

Data Format Identifier (Byte-2):

The Data Format Identifier is the second byte of Request Download (0x34) Service in the UDS Protocol. It is a fixed 1-byte value with each nibble encoded separately. Low nibble (bit: 3-0) is defining the type of encryption defined by the OEM. High nibble (bit: 7-4) defines the type of compression defined by the OEM. If it is 0x00, that means there is neither any Encryption nor Compression method being used for this ECU.

Address & Length Format Identifier (Byte-3):

The Address and Length Format Identifier is the third byte of Request Download (0x34) Service in the UDS Protocol. This Address and Length Format Identifier is also a fixed 1-byte value. This 1-byte value is again encoded separately with each nibble. The address and length format identifier specifies the size of the memory address and the size fields in bytes.

Low Byte (Bit: 3-0): Length or number of bytes of the memory address parameter.

High Byte (Bit: 7-4): Length or number of bytes of the memory size parameter.

Memory Address Parameter

The Memory address parameter defines the next how many bytes of data defines the memory address. This memory address is the starting address of the microcontroller NVM memory available in this ECU. You need to do the memory mapping at the time of ECU design. This memory mapping helps in storing different ECU data’s in different memory blocks.

The Memory Address Parameter is mostly having 1 extra byte. Basically, the processors are having 8-bit, 16-bit, 32-bit, or 64-bit addresses. So as per the bit, it should have 1-byte, 2-byte, 4-byte, or 8-byte of memory address parameter.

Mostly to identify it, it should be an even number. If this parameter is having an odd number then it is having 1 extra byte. This byte defines the type of memory added by the OEM.

This is used because, in ECU, there might be a multi-core processor or any external memory. So how the client or external computer will get to know in which memory it should flash or write the data. Because there might be the same memory address for both internal & external memory.

Memory Size Parameter

This Memory size parameter specifies how many bytes are in the block to be downloaded onto the flash memory of the microcontroller. This parameter shall be used by the server to compare the memory size with the total amount of data transferred during the Transfer Data (0x36) service.

Example Of Request Download (0x34) Service Request Frame

1. B1 (0x34): Download Request Service Identifier.
2. B2 (0x10): Data Format Identifier (DFI).
   • Lower Nibble from Bit:3-0: The Lower nibble value is ‘0’. There is no Encryption is defined since the value is 0.
   • Higher Nibble from Bit:7-4: The Higher nibble value is ‘1’. So we need to check the OEM project requirement for what type of Compression is used for the value ‘1’.
3. B3 (0x45): Address Length & Format Identifier (ALFI).
   • Lower Nibble from Bit:3-0: The Value is ‘5’ that an odd value. So it should be defined as 5-1 = 4. That means 4 is the Memory address byte. the ‘1’ is defining the next byte (B4) of B3 as having memory type. So from B4, the next 4-byte value is having the Starting memory address of the microcontroller Non-Volatile Memory.
   • Higher Nibble from Bit: 7-4: The value is ‘4’. So after the 5 bytes of memory type & memory address, the next 4 bytes (B9-B12) will be defining the memory size.
4. B4 (0x01): This is the 4th byte of this service. it might range from 0x00 to 0xFF. The value identification can be done by following the OEM document. So here the ‘1’ means it is an internal memory of the microcontroller. Most of the OEM is having this value for internal memory.
5. B5-B8 (0x40000000): This 4-byte value is the starting address of the microcontroller memory. Since the B4 byte defines the internal memory, so obviously it is internal to the microcontroller.
6. B9-B12 (0x00000458): This 4-byte value is the total memory size. That means the Client is having that much data to be transmitted or written to the NVM memory.

Request Download (0x34) Service Response Frame Format

The response frame of the Request Download (0x34) Service is sent by the server to the client. This might be a positive response or a negative response. So let us discuss first the Positive Response.

Positive Response Frame In Request Download (0x34) Service

If the server or the ECU has successfully executed the request service received from the client, the the server will send the positive response message to the client. Let us discuss with the syntax of this positive response message frame format.

Download Request Positive Response Identifier:

This is a positive response Identifier value of Download Request service in UDS Protocol. This value is a fixed value. It always follows a standard calculation format. Since the Download Request Service Identifier value is ‘0x34‘, the response value should be the addition of ‘0x40‘ which is nothing but the ‘0x74‘.

Length Format Identifier Parameter In 0x34 Positive Response

The Length Format Identifier is a 1-byte parameter in the Download Request Positive Response Identifier of the UDS Protocol. This 1-byte value is encoded separately with each nibble.

1. Lower Nibble (Bit: 3-0): It is reserved by the ISO-14229 standard document. It should be set to ‘0’ always by the server or ECU.
2. Higher Nibble (Bit: 7-4): This defines the number of byte or length of the maximum Number Of Block Length of the “maxNumberOfBlockLength” parameter.

MaxNumberOfBlockLength Parameter of Download Request (0x34) Service

This parameter is used by the request download positive response message to inform the client how many data bytes (maxNumberOfBlockLength) to include in each TransferData request (0x36) service message from the client.

This length defines the total message length, including the SID and the data parameters present in the TransferData request message (0x36). This parameter allows the client to adapt to the receive buffer size of the server before it starts transferring the data to the server. A server is required to accept Transfer data requests that are equal in length to its reported “MaxNumberOfBlockLength“.

Example Of Download Request (0x34) Positive Response Message

The below table shown the best example with real time value of this service.

1. B1 (0x74): Download Request (0x74) Service Positive response message value.
2. B2 (0x20): Length Format Identifier value is 0x20.
   • Lower Nibble from Bit 3-0: This nibble is reserved, so it should be ‘0’.
   • Higher Nibble from Bit:7-4: This nibble is having a value of ‘2’. So the next ‘2’ bytes of data defines how many maximum bytes of the data can be sent by the client to the server.
3. B3-B4 (0x0FFA): This 2-byte data (4090 bytes) is the real data bytes sent by a server to the client. That is why this (4090 bytes) MaxNumberOfBlockLength (MNBL) parameter value should be included in each TransferData request (0x34) message from the client.

Request Download (0x34) Service Negative Response Frame

If the server does not understand or not able to execute the request then it will send a negative response to the client. This response message will be having a Negative Response Code (NRC) with the reason.

Let us discuss the frame format with syntax

Supported NRC For 0x34 Service

There are 5 Negative Response Codes are being defined by the ISO-14229 standard. When this service is being used in any ECU, the developer shall implement these 5 Negative Response Codes. Please check the below table with explanation reason of NRC.