Trident IoT Zigbee SDK
Loading...
Searching...
No Matches
Bootloader

Back to Trident IoT SDK

Overview

Zigbee projects in the Trident IoT SDK rely on a custom secure bootloader that ensures devices boot safely and can be updated reliably in the field. The bootloader plays a critical role in both device security and firmware management, providing the foundation for features such as secure upgrades, partition management, and recovery mechanisms.

T32CM11 Secure Bootloader

Main Decision Flow:

  1. FOTA (Firmware Over-The-Air) Check Phase:
    • The bootloader first checks if there's a FOTA upgrade image available
    • If found, it verifies the image signature using ECDSA P-256 cryptographic verification
    • If the signature is valid, it checks the CRC32 to ensure data integrity
    • If both checks pass, it installs the update (decompressing if needed)
  2. Application Verification Phase:
    • Regardless of FOTA status, the bootloader always verifies the main application signature
    • If the app signature is valid, it boots the application directly
  3. Recovery Phase (when app verification fails):
    • If the app signature fails but a valid FOTA image exists, it reboots to apply the FOTA update
    • If no FOTA is available and the TR_MFG_TOKEN_SERIAL_BOOT_DELAY_SEC token is non-zero, it falls back to XMODEM mode for manual firmware upload

Key Security Features:

  • Cryptographic verification: All images must have valid ECDSA P-256 signatures
  • CRC32 integrity checks: Ensures data hasn't been corrupted
  • Secure boot: Won't execute unsigned code
  • Recovery mechanisms: Multiple fallback options if primary app fails

Special Behaviors:

  • Compression support: Can handle LZMA-compressed FOTA images to save flash space
  • Manufacturing tokens: Uses stored cryptographic keys for signature verification

Other Considerations:

  • Signature verification relies on the signature data being 256 byte page aligned
  • Signature page alignment MUST be true whether the application image exists inside a hex file, binary file, or wrapped in other files such as a Zigbee OTA file. See OTA Files

Signature Verification

The Trident bootloader uses cryptographic signature verification to ensure only authorized firmware can be executed. This requires specific manufacturing tokens to be programmed during device production containing the public key components used for ECDSA P-256 signature verification. See Key Files for how these keys are used in the build system.

The bootloader requires two manufacturing tokens to be programmed with the public key coordinates:

Token Name Description Size
TR_MFG_TOKEN_SIGNED_BOOTLOADER_KEY_X X coordinate of ECDSA P-256 public key 32 bytes
TR_MFG_TOKEN_SIGNED_BOOTLOADER_KEY_Y Y coordinate of ECDSA P-256 public key 32 bytes

Signature Structure

The bootloader expects signatures to be stored immediately after the firmware image with the following format:

Offset Size Field Description
0x00 4 bytes Magic Pattern Must be 0x58BF4E53
0x04 4 bytes Image Size Size of the signed image in bytes
0x08 32 bytes Signature R R component of ECDSA signature
0x28 32 bytes Signature S S component of ECDSA signature

Bootloader Verification Process

The bootloader performs the following verification steps:

  1. Extract Public Key: Reads X and Y coordinates from manufacturing tokens
  2. Locate Signature: Calculates signature location based on image size
  3. Validate Magic Pattern: Checks for 0x58BF4E53 signature header
  4. Verify Image Size: Ensures signature length matches actual image size
  5. Calculate SHA-256: Computes hash of the firmware image
  6. ECDSA Verification: Verifies signature using public key and image hash

XMODEM

The Trident bootloader includes an XMODEM feature that allows firmware upload via serial connection.

XMODEM Characteristics:

  • Block size: 128 bytes per packet
  • Error detection: 8-bit checksum validation
  • Flow control: ACK/NAK handshaking for reliability
  • Timeout handling: Automatic retry on transmission errors

For detailed protocol specifications, see XMODEM Protocol Wiki.

XMODEM Activation:

To activate an XMODEM transfer the bootloader must have a UART configured and connected to an XMODEM host. The T32CM11 bootloader has this configured by default to be connected over the UART found on the DKNCM11 development board. This defaults to UART0, 115200 baud, 8 data bits, 1 stop bit, no parity, and no flow control.

Additionally, MFG token TR_MFG_TOKEN_SERIAL_BOOT_DELAY_SEC must be written to a value other than 0 or 0xFF. This token is used to tell the bootloader how long to wait for an ascii 'x' character to be received in order to enter XMODEM transfer mode.

TR_MFG_TOKEN_SERIAL_BOOT_DELAY_SEC usage:

Token Value Behavior
0x00 No delay - skip XMODEM check and boot immediately
0x01-0xFE Wait N seconds for 'x' character before booting
0xFF No delay - skip XMODEM check and boot immediately

Once XMODEM mode has been activated, use an existing XMODEM transfer utility such as TeraTerm or minicom to transfer the desired file to the device. It is recommended to transfer the signed.bin file that is created as part of the build. See Files to Flash

Summary:

  • bootloader must be configured to have a UART connection
  • Default settings: UART0, 115200 baud, 8 data bits, 1 stop bit, no parity, no flow control
  • TR_MFG_TOKEN_SERIAL_BOOT_DELAY_SEC must be set to a value between 1-254 seconds
  • send an ascii 'x' character over the serial connection during the boot delay period to start XMODEM mode
    • if no 'x' character received, boot normally
  • use XMODEM transfer utility to send the signed.bin file to the device