Bootloader Operation — Flow Overview
This document describes how the bootloader (BL) and application interact from power-up through a firmware update. The two flowcharts below form a single cycle: the startup sequence decides whether to run the application or the bootloader, and the running application can hand control back to the bootloader when a new image needs to be programmed.
1: Startup and firmware update
On every power-on or reset, the device first checks a dedicated RAM location, BL_is_requested. If that flag is set, the bootloader runs immediately. Otherwise the device waits a short, customer-configurable window (200 ms by default) for a host request, then validates the application before launching it.
- Verify application: the application image CRC is checked together with the "application valid" flag.
- If both the CRC and the valid flag are correct, the application starts.
- If either check fails — or if BL_is_requested was set — the bootloader runs instead.
- In the bootloader, the host is authenticated (unless it was already authenticated before this reset). A new image is then downloaded and written to flash, followed by the CRC and the "application valid" flag.
- A CPU reset restarts the sequence at power-on, so the freshly written image is validated and launched cleanly on the next boot.
2: Requesting the bootloader from the application
While the application runs normally, it can be commanded to enter the bootloader. This path ensures a new image is only accepted from a host that has been authenticated.
- The application runs until it receives a "start BL process" request.
- On that request, the host tool is authenticated.
- If authentication fails, the application resumes normal operation and no update occurs.
- If authentication passes, the application sets both BL_is_requested and Host_is_authenticated, then performs a CPU reset.
- Because BL_is_requested is now set, the reset drops directly into the bootloader; because Host_is_authenticated is already set, the bootloader skips re-authentication and proceeds straight to the download.
How the two flags tie the diagrams together
BL_is_requested tells the startup sequence to enter the bootloader instead of the application. Host_is_authenticated lets the bootloader skip the authentication step when the application already authenticated the host prior to the reset. Together they allow the application to request and pre-authorize a firmware update, which the bootloader then completes after the reset.
