DFU Protocol
The application layer uses a Command/Response scheme. Every Command/Response consists of a standard header and an optional body. The header has the following format:
typedef struct
{
uint8_t code; /* unique Command/Response code */
uint8_t param[3]; /* Command/Response specific parameters*/
uint32_t body_len; /* length of the following body (0 = no body)*/
} header;
Currently only a single Command/Response is specified: IMAGE_DOWNLOAD (code = 1). The command is used to transfer a sub-image to the RSL device. The three parameters are not used by the command and must be set to 0. The body contains one of the two sub-images including the signature. The response signals back the success or failure of the operation; in the case of failure, the RSL device can send the response before the whole command body is transferred. The response itself has no body. Param[0] is used for the status; the other parameters are not used, and must be set to 0.
The "Status Codes" table, below, shows the specific status codes:
Code |
Meaning |
0 |
The sub-image has been downloaded successfully |
1 |
Download rejected due to incompatible Device ID |
2 |
Download rejected due to incompatible Build ID (only for application sub-images) |
3 |
Download rejected due to image size too large or small |
4 |
Download failed due to flash storage error |
5 |
Download failed due to invalid signature |
6 |
Download rejected due to invalid start address |
For the transport layer, an HDLC-like protocol with windowing is used to transport the upper layer SDUs. For the data-link layer, the transport characteristic of the DFU service is used.