3.2.2 Responses
Responses in the MDFU Protocol serve multiple purposes. Responses enable the following:
- Hosts can confirm that commands have executed successfully in the client.
- Hosts can retrieve data related to commands that have executed successfully.
- Hosts can know when the client is ready for the next command based on the responses and protocol flow control rules.
- Responses allow the host to understand when recoverable errors have been encountered and trigger the host’s error recovery mechanism.
- When unrecoverable errors are encountered, hosts can learn information about the error to help with diagnosing and debugging problems.
- Clients can abort an update as soon as an unrecoverable error is detected without having to wait until the end of the update for the host to know the update has failed.
3.2.2.1 Response Format
Responses are constructed using a 1-byte Response Sequence Field, a 1-byte Status Code, and a flexible length response data payload. These fields are concatenated together to form a response as shown in the following figure.
The maximum number of bytes that are placed into the response data payload (NR) is client dependent. In version 1.0.0 of the protocol, the GetClientInfo response is the longest response defined by the protocol. If all optional GetClientInfo response parameter values defined by the protocol are included in the response, the data payload to the GetClientInfo response is 28 bytes (6-byte Protocol Version Parameter + 5-byte Client Buffer Info Parameter + 17-byte Client Command Time-out Parameter with four SpecificCommandTimeOuts). Adding more optional parameters to the GetClientInfo response would make this response longer. Future versions of the protocol may define longer responses.
3.2.2.1.1 Response Status
The table below lists the available response status codes. Response status codes allow the client to tell the host if the command completed successfully, there was an issue/error that prevented the command from executing, or if the client wants to abort the file transfer firmware update process.
Supporting some of these codes are mandatory and must be present in every client implemented. Others are optional and the client developer can choose whether or not to implement them in a specific client.
Response Status | Response Status Code | Client Implementation Required |
|---|---|---|
Reserved - Never Used to Be Used1 | 0x00 | N/A |
SUCCESS | 0x01 | Mandatory |
0x02 | Mandatory | |
Reserved for Future Use | 0x03 | Optional |
0x04 | Mandatory | |
0x05 | Optional | |
Reserved for Future Use | 0x06 - 0xFF | Optional |
|
Note 1: The response status code 0x00 must never be used by any host/client. Using the response status code 0x00 may interfere with other aspects of the protocol. Any host/client that implements a response status code of 0x00 is not compliant with the MDFU Protocol specification. | ||
3.2.2.1.2 Response Data Payload
The contents of the response data payload depend on the status code that is contained in the response.
- When the status code is SUCCESS, this indicates that the command executed successfully and the response data payload contains data related to the execution of the command. The SUCCESS response data payload definitions are provided in the detailed definitions of each individual command-response pair.
- When the status code is not SUCCESS, this indicates that an error was detected by the client. In these cases, the response data payload may contain additional information which can be used to help diagnose and debug the issue. See the Error Response Details section of this specification for details on the meaning of the error response status codes and the data payload definitions for these status responses.
