1 MCC Melody 8-Bit MDFU Client Library

Introduction

The 8-Bit Microchip Device Firmware Update (MDFU) Client library in MPLAB® Code Configurator (MCC) Melody is the new implementation of the 8-Bit Bootloader library. Refer to the library Release Notes for the list of supported devices, along with version information, dependencies, and required versions for MCC libraries and drivers.

Bootloader Overview

A bootloader is crucial for updating a device's firmware in the field to add new application features or fix bugs while reducing device downtime. This process requires a communication method to transfer data between the device needing an update (Client Device) and a PC or another device holding the new firmware (Host Device). Consequently, the device in the field must be programmed with not only the application code that performs the desired operation for the end user (User Application), but also additional software to manage the loading and unloading of that application code (Bootloader Client). While each user application can implement a custom handler for this purpose, writing firmware to update another firmware is a complex task that requires a deep understanding of device operations, software compiler, and linker options, and the software running on the host device. Due to this steep learning curve, Microchip has designed the 8-Bit MDFU Client library, an easy-to-configure library for PIC® and AVR® devices that will help facilitate the creation of a firmware update ecosystem. The 8-Bit MDFU Client library utilizes the newly designed MDFU Protocol, a common firmware update protocol that can be used across a wide range of embedded devices. Refer to the MDFU Protocol Specification for all protocol related topics.

Vocabulary

This section will outline some common terms used in this document and other documents that describe various parts of the MDFU ecosystem.
  • User Application: Main operational code that creates the behavior seen by the end product user
  • Bootloader Client: Special pieces of firmware designed to run when a device is started to control what the device operation will be and perform firmware updates in the field
  • Target Device: The device in the field that contains the user application and bootloader
  • Host Device: The device or PC that is responsible for sending the new image data to the target device
  • Client: Another word for Target Device in the MDFU ecosystem
  • Host: Another word for Host Device in the MDFU ecosystem

MDFU Ecosystem

An MDFU ecosystem has four main parts: the Bootloader Client, User Application, Application Image Builder (pyfwimagebuilder), and Bootloader Host (pymdfu).

The bootloader client firmware is always the initial entry point when the device exits a Reset state. Its primary task is to check the validity of the existing user application on the device. If the user application is validated, the program counter is set to the application's start address to begin execution. If the validation fails, the system enters the bootloader operation cycle and waits for the host application to initiate a bootload process. Additionally, the bootloader client firmware can detect specific signals on the device to start the firmware update process before performing verification of the user application. This can be as simple as checking the value of a General Purpose Input/Output (GPIO) pin or monitoring specific traffic on the Universal Asynchronous Receiver and Transmitter (UART) to indicate that a new application firmware version needs to be installed.

The user application is the second part of the infrastructure. This suite of code is entirely developed and managed by either the user or the manufacturer, and it is this application that the bootloader will install. Subsequent sections of this document provide an example bootloader project, using a blinking LED application to illustrate the process of loading a custom application with a bootloader solution.

The application image builder (pyfwimagebuilder) is a Python command line utility designed to convert an application hex file into a format recognized by the bootloader client. The pyfwimagebuilder tool requires two input arguments and one optional output argument to create a custom image file for the host. The first input argument is the application hex file, and the second is the bootloader client’s configuration file (bootloader_configuration.toml). The third argument is optional, it is used to give a custom name to the image file that will contain the application program code and other necessary device configurations for the firmware upgrade. This generated file includes device parameters such as: Memory Unlock keys, Flash memory row size, application start address, and Device ID, along with the application program data. When loaded into the bootloader host, the file is parsed and packetized for transmission to the bootloader client on the target device. The pyfwimagebuilder tool can be run manually or as a post-build process in MPLAB® X IDE to convert the application hex file into the image file for the bootloader host.

The final component of any bootloader infrastructure is the bootloader host, which is essential for transferring the user application to the target device. The bootloader host responsible for managing the Device Firmware Update (DFU) process can be either pymdfu, developed by Microchip Technology Inc. and available on PyPi, or another third-party source. Alternatively, an embedded host can be used to transfer the application image created by pyfwimagebuilder to the target device. Regardless of the method, the ultimate goal is to update the user application version using the MDFU Protocol and ecosystem.
Figure 1-1. MDFU Ecosystem

Verification Features

A crucial feature of any bootloader is its verification options. Bootloaders use these verification methods to ensure the application code is valid before handing over control to the user application. Microcontroller (MCUs) Units are, essentially, small computers and must be protected similarly to other computer systems. To achieve this during the bootloading process, the bootloader must be capable of detecting errors in the application code before execution, thereby safeguarding the MCU from running harmful or corrupted code. For more information, refer to the Verification Schemes chapter.

Memory Provisioning Features

Another feature of the MCC Melody 8-Bit MDFU Client is its communication interface, specifically designed to warrant the communication of commands used for transferring bytes of the application image into the MCU program memory. To utilize a bootload process, the bootloader code must be programmed into the Flash memory of the MCU. It is necessary to provision the MCU’s Flash memory to prevent writing in the boot section, as well as to tell the MCU where to write the new application image and how much data the application is allowed to access. Bootloader Memory Map shows the provisioned memory layout of a general bootloader solution where the bootloader partition begins at PFM location 0x0000 and goes up to the byte before the start address of the application section.

Figure 1-2. Bootloader Memory Map
Note: The above image is describing the partitions of a PIC ® device, but the general layout of the Bootloader and Application is consistent for all supported devices.