When writing a user-defined bootloader keep the following points in mind:
- Placement
- Normally a user bootloader resides at the beginning of MAIN flash (sector 0, 1, and so on) to allow per-sector write/erase protection (from the application) and chip erase protection (from the programmer).
- The bootloader can use all of SRAM except the area 0x20000400-0x2000047F which contains boot flow state variables.
- Entering and exiting the bootloader
- The bootloader is always invoked as part of any boot flow, so to optimize boot time the bootloader should quickly determine whether it has been triggered or not (typical mechanisms are I/O-level on some pin, a flag from an application somewhere in flash, a flag from application in the REG3V3 registers).
- The entry function must never return and should accept two 32-bit arguments, bldrParam, and bldrFlags.
- If not triggered the bootloader shall return control back to the boot flow through the Hard API function HapiEnterApplication(), see SimpleLink™ CC23xx Software
Development Kit (SDK) documentation.
- Between the return from bootloader and the invocation of the application boot flow applies CCFG restrictions, opens up for (application-only) debug, and processes the application's HW initialization copy list.
- Ensure that SP is unwound to the top of the stack (or that at least 256 bytes are available downwards until the start of SRAM) before calling HapiEnterApplication().
- CCFG bootloader configuration
- CCFG.bootCfg.pBldrVtor is a pointer to the bootloader's ISR vector table which has to contain at least two entries (initial-stack-pointer, function-pointer-to-bootloader-entry-function)
- The bootloader should also populate the VTOR entries for CPU exceptions (HardFault, UserFault, NMI, and so on) or immediately change to a RAM-based VTOR that does
- Bootloader can reuse the space used by boot flow for call stack by placing initial SP at 0x20000400.
- Bootloader entry function arguments
- The first is copied from CCFG.bldrParam and typically contains some bootloader-specific configuration options (for example, trigger pin, serial baud rate, timeout, and so on).
- The second is bldrFlags, which contains useful hints from the boot flow. At a minimum, bAppCanBoot and bChipEraseAllowed should be heeded.
- General
- To keep the size of the bootloader small it is advantageous to reuse some of the functionality already in ROM exposed through the Hard API (CRC32, SHA2-256, Flash programming functions, and so on).
Note: The bootloader has an elevated privilege level compared to even the OS kernel. Among other things, the bootloader can program the CCFG sector or program/erase sectors that later have hardware write/erase protection.