1.1.4 PIC32CX-BZ2 Standalone Bootloader Component Help

PIC32CX-BZ2 bootloader is a standalone harmony component, Using it, one can generate bootloader which is a program that is loaded on internal flash memory and gets executed every time the device powers up or resets.

Bootloader can be used to upgrade firmware on a target device without the need for an external programmer or debugger. It does not fully operate on the device, but can perform various functions prior to starting the main application

Functionality of Bootloader
  • Loads firmware images to flash over the serial connection using a tool or python script, known as Device Firmware Upgrade (DFU)
  • Provides application protection for firmware
  • Replaces application firmware
  • Starts the application
  • If the device wakes from deep sleep, then bootloader directly jumps to the application

Memory Information and Layout of PIC32CXBZ2 device

Table 1-5. 
Memory AreaPurpose
Boot Flash Size is 0x0 to 0x5E00 – (~24KB)The memory where bootloader code runs
Slot 0 base address - 0x01000000The memory where the application firmware runs and the memory where the bootloader copies the new application firmware
Slot 1 base address - 0x01080000The memory where the received image(Either through DFU or any other way) gets stored. and the memory where bootloader looks for the new image to copy into the Slot 0

The full memory layout can be found here

Boot Flash

In PIC32CXBZ2, 24KB boot flash memory is separated from the main execution memory. This boot flash is used for bootloader code

Metadata Header

Format of image meta-data header are described below. Notice that some of the elements in the header is reserved for future expansion and they are not used in this version of bootloader implementation

Table 1-6. 
OffsetNameDescription
Metadata Header
0x00:0x07FillerSet to all zero
0x08:0x0DMANU_IDENTIFIER *“MCHP” ASCII String Identifier
0x0C:0x0FFillerSet to all zero
0x10:0x13SEQ_NUM *Metadata Sequence Number of the image (little endian). Monotonically decreasing image index. Values of 0 or 0xFFFFFFFF indicate that the image is invalid.
0x14MD_REVMetadata Revision. This field must be set to 0x02 for this version of metadata header
0x15CONT_IDX

Container Index
1: Plain firmware image
2: Encrypted firmware image

0x16MD_AUTH_MTHD *

Metadata authentication method.
0: None
1: SHA-256
2: ECDSA p256 + SHA-256

0x17MD_AUTH_KEY

Key index for authenticating metadata
0: IB Key
1: Key #2
Reserved for future use. Not for MD_REV 0x01

0x18PL_DEC_MTHD

Payload Decryption method
0: Plain
1: AES

0x19PL_DEC_KEY

Key index for decrypting payload
0: Key #1
1: Key #2

0x1A:0x1BPL_LENMetadata payload length. The payload length for this version should be 0x55
Metadata Payload = Firmware Image Header
0x1C:0x1FFW_IMG_REV *Firmware Image revision (little endian).
0x20:0x23FW_IMG_LENFirmware Image length
0x24FW_IMG_AUTH_MTHD *

Firmware Image authentication method. For Chimera the acceptable method are ECDSA p256 + SHA-256
0: None
1: SHA-256
2: ECDSA p256 + SHA-256

0x25FW_IMG_AUTH_KEY

Firmware Image authentication key index
0: IB key
1: Key #2

0x26FW_IMG_DEC_MTHD

Firmware Image decryption method.
0: Plain
1: AES
Reserved for future use. Not for MD_REV 0x01

0x27FW_IMG_DEC_KEY

Firmware Image decryption key index
0: Key #1
1: Key #2
Reserved for future use. Not for MD_REV 0x01

0x28FW_IMG_SIG_SZFirmware Image signature size
0x29:0x70FW_IMG_SIG

Firmware Image Signature.
The concatenated R and S term of the ECDSA signature (P-256) of the SHA-256 hash of the firmware image

Metadata Footer
0x1B7MD_SIG_SZMetadata payload signature size
0x1B8:0x1FFMD_SIG

Metadata payload signature
The concatenated R and S term of the ECDSA signature (P-256r1) of the SHA-256 hash of the metadata payload (firmware image header).

* Configurable by user

Working of Bootloader

when the application receives new image from a server or via a tool, it will/should store in the Slot 1 location with meta data header & firmware and it should trigger software reset so that bootloader code runs

Bootloader checks for valid image in Slot 1 by reading the meta data header and firmware and authenticating the same with the selected authentication method. If valid image is found and successfully authenticated, then
  • Erases Slot 0
  • Copies the Slot 1 image to Slot 0
  • Verifies the Copy
After that it checks for valid image in Slot 0 by validating it, it jumps to the application if valid image is found

Bootloader usage with DFU

bootloader programmed to the MCU (in DFU mode) receives an application image from the host over serial interface and writes it to the internal flash in Slot 1 . After loading new image on slot 1, if reset is triggered, then bootloader erases the slot 0, copies the image from slot 1 to slot 0, verifies the copy procedure, erases the slot 1. Then bootloader jumps to application which is the new application image

Bootloader stores information about the image in Meta Data Header. This is basically size of 0x200 bytes and gets stored at the start of slot. Bootloader reads this meta data header and does the authentication procedure based on the information in meta data header

Flow Diagram of Bootloader

The detailed flow diagram of bootloader with the optional DFU block can be found below