Skip to main content

EXST bootloader

The EXST (External Storage) system requires that the targets' CPU has a small program, called a bootloader, that provides functionality to load firmware from an external storage into the CPU's RAM so that the firmware can be executed.

Example external storage systems include:

  • External Flash using Firmware Partition
  • File on an SD card.

EXST targets also have the requirement of providing a mechanism to load and save configuration ('eeprom'). options for this include:

  • CPU Embedded flash page.
  • External Flash using Config Partition
  • File on an SD card.

Since external storage systems can become corrupted, and communication errors can occur, Bootloaders should verify correct loading of the firmware from an external storage system, or after transferring via a debugger. An hash is provided for this purpose.

Bootloaders are not limited to just one storage system.

Bootloaders may offer additional functionality, such as:

  • a means to update the firmware on an external storage medium (e.g. via DFU)
  • update one external storage system from another (i.e. update external flash from file on SD card)
  • backup, select, swap or erase firmware
  • backup, select, swap or erase configuration.

Users should consult the manual that came with their EXST bootloader-equipped flight controller for details on how to use any such features.

The build system provides a way to build files suitable for transferring onto an external storage medium via the standard 'bin'/'hex' make goals.

make TARGET=<targetname>

This results in the usual *.bin and *.hex files and also a *_EXST.elf file which have been patched to contain information required for bootloader operation.

The .bin file is a binary file which should be transferred to the storage medium and is suitable for distribution. The .hex file is a hex file which can be used by tools for uploading to a bootloader and is suitable for distribution.

For developers there is a _EXST.elf file which is a standard .elf file that has had one section replaced, this file is suitable for uploading to targets using a debugger such as GDB.

For details on the memory sections used refer to the linker files.

EXST format

The format for EXST targets is as follows:

  • Firmware.
  • Bootloader block.

The bootloader block is 64 bytes.

For example a 448K EXST .bin file is comprised as follows:

Start AddressEnd addressUsage
0x000000x6FFBFFirmware section
0x6FFC00x6FFFFBootloader block

EXST bootloader block

The bootloader block is comprised as follows:

Start AddressEnd addressUsage
0x000x00Block Format
0x010x3FBlock Content

Block Formats

0x00Block format 0x00

Block Format 0x00 Content

Note: addresses relative to start of bootloader block

Start AddressEnd addressUsage
0x010x01Checksum/Hash method
0x020x2FReserved, fill with 0x00
0x300x3FChecksum value, pad with trailing 0x00

Checksum Hash methods

0x00No checksum.

Checksum locations:

Start AddressEnd addressUsage
0x300x3FMD5 hash of firmware section

The bootloader should make no attempt to use any reserved area otherwise this prevents it's future use by the firmware.

The bootloader should ensure this block is in RAM when the firmware is loaded. i.e. copy the entire EXST image.

As the reserved area is under control of the build system, not the bootloader, additional information can stored there for use by the firmware or future bootloaders. Extreme care must be taken not to break the bootloaders ability to load firmware. Consultation with the developers for any changes to this area is required.

Example possible future enhancements for the EXST bootloader block

  • Hardware layout identification - to allow the firmware to identify the hardware, such that IO pins and peripherals can be reserved/initialised.
  • Alternative hashes/CRCs.