3.7.3 Unrecoverable Errors

There are a number of different errors which can be encountered during a firmware update which can’t be recovered by an automatic recovery mechanism. These errors are classified by the MDFU Protocol as unrecoverable errors.

Since there is no automatic recovery mechanism possible for an unrecoverable error, the MDFU Protocol provides a mechanism for stopping the update immediately when an unrecoverable error has been detected by the client and reporting back information on why the update was terminated.

Unrecoverable errors are detected by the MDFU client and reported back to the host using the abort file transfer mechanism defined in this section of the specification. There are many different types of unrecoverable errors which clients could potentially detect. Checking for unrecoverable errors is an optional MDFU Protocol feature for clients to implement. Clients can choose to implement as many or as few checks for unrecoverable errors and report them as desired. Adding client checks for unrecoverable errors is a tradeoff that can be selected by the client developer. Adding more checks consumes more memory for the client implementation but has the following benefits:

  1. Improved Troubleshooting and Debugging
    • The process of aborting a file transfer allows the client to report a cause that the update failed which helps debug the issue.
  2. Time Savings
    • Aborting an update as soon as an error is detected eliminates wasted time which would otherwise occur if the protocol waited until the end of the file transfer to learn that the update failed. This can help eliminate wasted time in production line update environments.

3.7.3.1 Example 1: Invalid Update File

The process of performing an update involves the host transferring the Client Update File to the client. The Client Update File needs to contain data that has a valid application for the client in a valid format for the client to use the data in the Client Update File to successfully update the client.

The MDFU Protocol is responsible for reliably transporting the data in the Client Update File to the client. However, an invalid Client Update File will fail to produce a successful client update, and there is nothing the MDFU Protocol or MDFU host can do to fix or recover from a problem that exists with the contents of the Client Update File. This is an example of an unrecoverable error.

Clients may optionally choose to implement checks for various problems with the Client Update File. If a client detects a problem with the data in the Client Update File, it can abort the file transfer as soon as an error is detected and report a reason why it aborted the transfer.

There are a number of types of problems that could exist with the data in the Client Update File. For example, a Client Update File could contain invalid memory addresses or have an invalid application version. See the FileAbortClause section for a list of the available file problems a client can report.

3.7.3.2 Example 2: Client Flash Memory Issues

Performing a firmware update involves erasing and writing nonvolatile memory (NVM) on a client processor. There are scenarios where a client’s Flash memory may fail to fully erase properly or fully write to the proper values for various reasons. Clients may optionally choose to verify that the result of erase/write operations matches the desired values. When a client has detected that Flash fails to erase/write properly, the MDFU Protocol recommends that the client abort the update process for two reasons:

  1. Users will want to be aware of client Flash issues as opposed to trying to silently recover from them.
  2. Placing automatic retry loops on re-executing erase/write operations could result in a large number of erases/writes to client Flash which could wear it out without the user being aware.

For these reasons, the MDFU Protocol doesn’t include any automatic recovery mechanisms for Flash memory issues, and they are considered unrecoverable errors.

3.7.3.3 Detection

The responsibility of detecting unrecoverable errors is placed on the client.

Clients can choose to check for as many or few unrecoverable errors as are useful for the end application. This allows for the client developer to choose the best balance of client code size vs troubleshooting and debug experience for a particular design.

3.7.3.4 Aborting A Transfer

At any point in the update after an unrecoverable error has been detected by the client, the client can respond to a command with a response containing the ABORT_FILE_TRANSFER status and report any of the available FileAbortCause reasons for aborting the update.