Introduction To Request File Transfer (0x38) Service
Request File Transfer (0x38) Service is the latest added new Service in the UDS Protocol standard ISO 14229. This is an advanced version of the Request Download (0x34) or Upload (0x35) Service. This service is the combination of both 0x34 & 0x35 services. Basically, the older two services are using for data transfer in the general byte transfer method. But in the case of new service 0x38, the file transfer method used for Request download & Upload of data. The data might be a Boot-loader, Application Software, or any calibration data, etc. This Tutorial will help you to implement this service from end to end in your ECU, or testing of this service, etc. This 0x38 service is one of the most used UDS services lists. This service is added in the UDS protocol to overcome the limitation of 0x34 & 0x35 services.
Working of Request File Transfer (0x38) Service
This service is working like a file transfer from client to server. The request FileTransfer (0x38) service is used by the client to initiate a file data transfer from the client to the server or from the server to the client. This is nothing but called a download & upload method. Even though you can use this service to retrieve information about the file system.
This service is intended to give an alternative solution to the Request Download (0x34) & Request Upload (0x35) services. The main purpose of this service is to provide the file system data transfer method.
Need Of Request File Transfer (0x38) Service
Since the automotive requirement functionality is increasing gradually, it requires making the UDS Protocol compatible with all. Actually, previously we were supposed to use a normal microcontroller-based RTOS system. It doesn’t have any file system. But nowadays, we have started using the ADAS-based ECU. Here we have started using the Linux System, where we need to use the file system for any kind of data transfer between the client & server.
Request File Transfer (0x38) Service Request Frame Format
This request frame is used by a client to send the file transfer request to the server. Please look onto the below table for request frame format.
| Byte Number | Parameter Name | Parameter Value Range |
|---|---|---|
| #1 | Request FileTransfer Request SID | 0x38 |
| #2 | ModeOfOperation | 0x01 – 0x05 |
| #3 #4 | FilePathAndNameLength | 0x00 – 0xFF 0x00 – 0xFF |
| #5 – #(5+n-1) | FilePathAndName | 0x00 – 0xFF 0x00 – 0xFF |
| #5+n | DataFormatIdentifier | 0x00 – 0xFF |
| #5+n+1 | FileSizeParameterLength | 0x00 – 0xFF |
| #(5+n+2) – #(5+n+2+k-1) | FileSizeUnCompressed | 0x00 – 0xFF 0x00 – 0xFF |
| #(5+n+2+k) – #(5+n+1+2k) | FileSizeCompressed | 0x00 – 0xFF 0x00 – 0xFF |
Request FileTransfer Request SID (0x38)
The 0x38 is the first byte of Request File Transfer (0x38) Service. It informs the server about the type of data transfer.
ModeOfOperation
The purpose of this parameter is to define what type of file operation should be applied to that file or directory available in processor memory. That file or directory should be indicated in the “FilePathAndName” parameter. This parameter is having 5 different values defined in the below table.
| Value | Parameter Name | Parameter Description |
|---|---|---|
| 0x00 | ISO/SAE reserved | Reserved for future use |
| 0x01 | AddFile | It is used to add the file to the downloaded file defined in the “FilePathAndName” parameter. |
| 0x02 | DeleteFile | It is used to delete the downloaded file defined in the “FilePathAndName” parameter. |
| 0x03 | ReplaceFile | It is used to replace the downloaded file defined in the “FilePathAndName” parameter. |
| 0x04 | ReadFile | This parameter is used to read the file from the ECU Memory & upload it onto the computer memory location defined in the “FilePathAndName” parameter. |
| 0x05 | ReadDirectory | This is similar to the “ReadFile” parameter. Only the difference is the directory path instead of the file path defined in the “FilePathAndName” parameter. |
| 0x06 – 0xFF | ISO/SAE reserved | Reserved for future use |
FilePathAndNameLength In Request File Transfer (0x38) Service
This is a 2 byte of the second parameter in Request File Transfer (0x38) Service. its byte number 3 is the MSB byte whereas byte number 4 is the LSB byte.
It defines the length of FilePath parameter in bytes.
FilePathAndName In Request File Transfer (0x38) Service
This parameter defines the file system location of the server memory. This value can be added, deleted, replaced, or read is depending on the “ModeOfOperation” parameter. This is also defining the file name as per the “ModeOfOperation” parameter.
This parameter range is dynamic and it can be any range as per the client requirement. This should be encoded in ASCII format for request transfer. The number of bytes used for this parameter can be calculated by Byte number 5 – (5+n-1).
DataFormatIdentifier In Request File Transfer (0x38) Service
This is a 1-byte value parameter encoded each nibble separately. This higher nibble specifies the type of compression method used for this file. The lower nibble defines the types of encryption methods used for this file.
- Lower Nibble (Bit:3-0): Type of Encryption Method used for the file.
- Higher Nibble (Bit:7-4): Type of Compression method used for the file
If the value is 0x00 then neither any compression method nor any encryption is being used for this file. If the value is other than the 0x00 then you should follow the OEM requirement for both the encryption & compression method type definition. This byte can be calculated from the #5+n formula.
This parameter shall not be included in the Request File Transfer (0x38) Service if the “ModeOfOperation” type is equals to DeleteFile (0x02), ReadFile (0x04) or ReadDir (0x05).
FileSizeUnCompressed In Request File Transfer (0x38) Service
This is a 2 byte fixed parameter value that defines the size of the uncompressed file in bytes. This parameter will not be a part of the Request File Transfer (0x38) Service if the “ModeOfOperation” type is equals to DeleteFile (0x02), ReadFile (0x04) or ReadDir (0x05).
FileSizeCompressed In Request File Transfer (0x38) Service
This is also a 2 byte fixed parameter value like the “FileSizeUnCompressed” parameter. It is the size of the compressed file in bytes. This parameter also shall mot be a part of Request File Transfer (0x38) Service if the “ModeOfOperation” type is equals to DeleteFile (0x02), ReadFile (0x04) or ReadDir (0x05).
Example Of Positive Response For Request File Transfer (0x38) Service
The below table shows the example of Request File Transfer (0x38) Service frame format. It describes that how to send any request format from client to server.
| RSID | MOP | FPNL | FPN | DFI | FSPL | FSUC | FSC |
|---|---|---|---|---|---|---|---|
| 0x38 | 0x01 | 0x0020 | “D:\PiEmbSysTech\Training\bcm.tlv” | 0x11 | 0x02 | 0xC350 | 0x7530 |
- RSID (0x38): The Request Service Identifier is the first byte of the diagnostic data frame.
- MOP (0x01): Mode Of Operation (MOP) is the “AddFile” to the server memory.
- FPNL (0x0020): File Path and Name Length defines the next 32 bytes (20 in hex) of ASCII character is holding the file pathname of the “FilePathAndName” parameter.
- FPN (D:\PiEmbSysTech\Training\bcm.tlv): It Describes the File Path Name (D:\PiEmbSysTech\Training\) with file file name (bcm.tlv).
- DFI (0x11): Data Format Identifier describes the Compression Method = 0x1X; Encryption Method = 0xX1.
- FSPL (0x02): The File Size And Parameter Length describes the length of both FSUC & FSC as 2 bytes.
- FSUC (0xC350): The Uncompressed File Size (FileSizeUncompressed) is 50,000 in decimal value of 0xC350. So it is 50 Kilo Bytes.
- FSC (0x7530): Compressed File size is 30,000 in decimal, so the size is 30 KiloBytes.
Request File Transfer (0x38) Service Positive Response Frame Format
The response message of Request File Transfer (0x38) Service can be positive or negative type. If the server successfully completed the verification & validation of this service then it will execute this service & sends a positive response to the client.
Please look onto the below table for better understanding of Positive Response Frame Format.
| Data Byte Number | Parameter Name | Value |
|---|---|---|
| #1 | RequestFileTransfer Response SID | 0x78 |
| #2 | ModeOfOperation | 0x01 – 0x05 |
| #3 | LengthFormatIdentifier | 0x00 – 0xFF |
| #4 – #4+(m-1) | MaxNumberOfBlockLength | 0x00 – 0xFF 0x00 – 0xFF |
| #4+m | DataFormatIdentifier | 0x00 – 0xFF |
| #4+m+1 – #4+m+2 | FileSizeOrDirInfoParameterLength | 0x00 – 0xFF 0x00 – 0xFF |
| #4+m+3 – #4+m+3+k-1 | FileSizeUncompressedOrDirInfoLength | 0x00 – 0xFF 0x00 – 0xFF |
| #4+m+3+k – #4+m+3+2k-1 | FileSizeCompressed | 0x00 – 0xFF 0x00 – 0xFF |
I hope you understood the positive response message frame format syntax. So now lets discuss of each parameter used in this message frame.
Request FileTransfer Response SID (0x78)
This is the response message service identifier of Request File Transfer (0x38) Service.
ModeOfOperation In In 0x38 Positive Response Messsage
The Mode Of Operation parameter is the echos of the Request FileTransfer Request SID (0x38). So the value of each parameter is already explained above.
LengthFormatIdentifier In 0x38 Positive Response Message
This parameter defines the length of the “MaxNumberOfBlockLength” parameter in bytes. This parameter will not be a part of this response message if the “ModeOfOperation” is a DeleteFile (0x02) type.
MaxNumberOfBlockLength In 0x38 Positive Response Message
This parameter value is sent by the server to the client. This defines how many data bytes (MaxNumberOfBlockLength) will be included by the client for the next Request File Transfer (0x38) Service. This parameter will not be included in the 0x38 Positive Response Message by the server if the “ModeOfOperation” parameter is a DeleteFile(0x02) type.
DataFormatIdentifier In 0x38 Positive Response Message
This parameter is also the same as the DataFormatIdentifier defined in the Request File Transfer (0x38) Service Request Frame. So you can follow the same standard as I have already explained above. There are two exceptional conditions that make the difference from the request frame format explained below.
- This parameter will not be included in the 0x38 Positive Response Message, if the “ModeOfOperation” parameter is DeleteFile(0x02) type.
- The value of the “DataFormatIdentifier” will be zero if the “ModeOfOperation” parameter is ReadDir(0x05) type.
FileSizeOrDirInfoParameterLength In 0x38 Positive Response Message
This parameter defines the length of both “FileSizeUncompressedOrDirInfoLength” and “FileSizeCompressed” in bytes. This parameter is optional and depending on the “ModeOfOperation” parameter. If the “ModeOfOperation” is AddFile(0x01), DeleteFile(0x02), or ReplaceFile(0x03) type, then this will not be a part of the 0x38 Positive Response Message.
FileSizeUncompressedOrDirInfoLength In 0x38 Positive Response Message
This parameter defines the size of the Uncompressed file to be uploaded. It also defines the length of the folder or directory to be read from the client in bytes. This parameter also will not be included in the response message, if the “ModeOfOperation” is AddFile(0x01), DeleteFile(0x02), or ReplaceFile(0x03) type.
FileSizeCompressed In 0x38 Positive Response Message
This parameter is defining the compressed file size in number of bytes. It shall not included in the response message of 0x38 if the “ModeOfOperation” is AddFile(0x01), DeleteFile(0x02), or ReplaceFile(0x03) type.
Example Of Request File Transfer (0x38) Service Positive Response Message
| RRFT | MOOP | LFID | MNROB | DFI |
|---|---|---|---|---|
| 78 | 01 | 02 | C3 50 | 11 |
- RRFT (0x78): Request File Transfer Response SID is the fixed value (0x38 + 0x40).
- MOOP ()0x01: Mode Of Operation is AddFile(0x01) Type.
- LFID (0x02): Length Format Identifier value is 2. So the MaxNumberOfBlockLength value is defined in the next 2 data bytes.
- MNROB (0xC350): Maximum Number Of Block Length is 2 bytes having the value defined as 50 KiloBytes.
- DFI (0x11): Since the Data Format Identifier is 0x11, hence the Compression Method = 0x1X and the Encryption Method = 0xX1.
Negative Response Message Of Request File Transfer 0x38 Service
If the requested File Transfer 0x38 Service is failed in any stage of verification or validation, the server will send a negative response message. The below table shows an example of the Request File Transfer 0x38 Service negative response message. This might come if you send any wrong message length in the Request File Transfer (0x38) Service.
| NRSID | RFTSID | NRC |
|---|---|---|
| 7F | 38 | 13 |
Supported NRC For 0x38 Service Of UDS Protocol
There is a total of 5 NRC has been added as per the ISO 14229 standard. It is up to the OEM what are NRC will be implemented for that particular ECU server. Please look at the below table for the full description.
| NRC VALUE | NRC Parameter Name | Description |
|---|---|---|
| 0x13 | IncorrectMessageLengthOrInvalidFormat | If the 0x38 Message length is wrong |
| 0x22 | ConditionsNotCorrect | If the Server is already doing any download or upload or any other ECU condition is not satisfying, the server will return this NRC. |
| 0x31 | RequestOutOfRange | If any of the 0x38 service parameters is not valid then it will return with 0x31 NRC. |
| 0x33 | SecurityAccessDenied | This will be returned if the server is not unlocked and the client is requesting 0x38 service. |
| 0x70 | UploadDownloadNotAccepted | If the server or ECU memory is having some faults, then the server will return with 0x70 NRC. |
My Dear Engineers, Please give your feedback suggestion in the below comments, if you are getting benefited from our Tutorial. We do write all the tutorials from the heart of the Embedded System in depth.
