3.1 Firmware Update Algorithm

The Microchip Device Firmware Update Protocol uses five different stages that occur sequentially for a host to update a client’s firmware. The host uses Command-Response Pairs to accomplish each of these stages. The diagram below and the following sections provide information on each of these stages.

3.1.1 Client Setup Prior to Update

Prior to initiating an update from the MDFU host, the user must place the client in a mode where it is ready to receive and process MDFU Protocol commands. Different clients may have different mechanisms for entering a firmware update mode such as:

  • Pressing/holding a button.
  • Power cycling while holding a button.
  • Resetting while holding a button.
  • Sending an update trigger.
  • Accepting an incoming update from a running application (live update).

The mechanism used to enter a firmware update mode is selected by the client firmware developer.

3.1.2 Discovery Stage

Each update starts with a Discovery stage. During this stage, the host discovers the client parameters necessary for updating the client.

Discovery is accomplished through a single GetClientInfo command (see Get Client Info Command) sent from the host to the client. The client must respond to this command with a list of client parameter values. The parameter list includes the MDFU Protocol Version implemented by the client, the Client Buffer Info, and the Client Command Time-out Info.

If the client fails to report a mandatory parameter, the host must terminate the update and provide a mechanism for reporting the cause for terminating the update to the user.

The GetClientInfo command definition in the specification contains a complete description of the parameters.

3.1.3 Start Transfer Stage

After discovering the client capabilities, the host sends a StartTransfer command (see Start Transfer Command).

The purpose of this signal is to allow the client to initialize any state necessary to prepare for incoming Client Update File data.

If an update fails part way through for any reason, this command must result in the client being reset to a state where it is ready to receive the contents of the entire Client Update File starting from the beginning of the file.

Additional details of actions taken when receiving this command are client dependent.

3.1.4 File Transfer Stage

The client firmware is updated by transferring all the data in the Client Update File from the host to the client.

The Client Update File is divided into chunks and sent to the client in smaller pieces for two reasons:

  1. Flow Control
    • The MDFU Protocol uses a stop and wait flow control technique, where commands with a known fixed maximum size are sent from the host to the client and the file chunks must fit inside these command data payloads, to use this form of flow control.
    • See the Flow Control section of the specification for more detailed information.
  2. Quickly Detecting and Handling Errors
    • Integrity checks on individual commands with small chunks of the file enables faster error detection and faster error recovery from errors due to transmission corruption.
    • Sending file data in small chunks allows the client to abort a transfer as soon as an unrecoverable error is detected.

3.1.4.1 File Chunking Details

  • The host divides the file into fixed size chunks and sends the chunks sequentially to the client using successive WriteChunk commands (see Write Chunk Command).
  • The chunk size is obtained during the Discovery stage from the client using the GetClientInfo command.
  • The Client Buffer Info Parameter contains the MaxCommandDataLength field which defines the maximum number of bytes of the file that a client can receive in a single command.
  • The Client Update File is divided into chunks of MaxCommandDataLength bytes.
  • If the file is not an integer multiple of the chunk size, the last file chunk is a smaller chunk containing the remaining bytes from the file.

3.1.5 Verification Stage

The host sends a GetImageState command (see Get Image State Command) after the file has been completely transferred. This command tells the client to run its firmware verification algorithm and respond with information about whether the firmware is valid or not. The response to this command lets the host know if the client has determined that its new firmware is valid.

The mechanism the client uses to verify its memory is selectable by the client and not specified by the MDFU Protocol. Clients could choose to use a checksum, Cyclic Redundancy Check (CRC), or any other algorithm that meets the requirements of the product being designed.

Hosts must provide a mechanism for raising an error, logging the error, or notifying the user of the invalid image on the client so that appropriate actions can be taken to recover from this invalid image.

3.1.6 End Transfer Stage

After verification is complete, the host sends the EndTransfer command (see End Transfer Command) to the client to signal that the update is complete.

The Client Firmware Update Code can decide what action to take at this point (e.g., launching updated firmware).