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 File Transfer (0x38) Service is the latest added new Service in the UDS Protocol standard ISO 14229. This is an advanced version of the
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.
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.
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 |
The 0x38 is the first byte of Request File Transfer (0x38) Service. It informs the server about the type of data transfer.
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 |
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.
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).
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.
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).
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).
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).
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 |
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.
This is the response message service identifier of Request File Transfer (0x38) Service.
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.
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.
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.
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 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.
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.
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.
RRFT | MOOP | LFID | MNROB | DFI |
---|---|---|---|---|
78 | 01 | 02 | C3 50 | 11 |
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 |
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.
Subscribe to get the latest posts sent to your email.