2. Booting

The booter is always executed when a POR, a Hardware Reset, or the RESET_ON_WAKEUP feature is configured. Different booting flavors are supported:

  • Boot from eFlash cached (secure/non-secure), Configuration Script in eFlash

  • Boot from QSPI cached (non-secure), Configuration Script in QSPI

  • Boot from QSPI cached (secure), Configuration Script in eFlash

  • Boot from UART (non-secure), no eFlash/QSPI Flash image available.

The booter also detects available software updates and applies them according to the eFlash/QSPI header.

The Boot flow is divided into five separate phases:

  1. Initialization.

  2. Run configuration script.

  3. Retrieve the application code.

  4. Device administration.

  5. Load image.

2.1. Initialization phases

The initialization phase takes care of enabling the Power domains. Then it initializes the QSPI interface and Clocks. Following this, it enables Development mode. This is done so that it can be disabled by the CS in the next phase if desired. Development mode can be used for having the debugger on and updating the device firmware using UART. Next, it sets all XTAL-related flags to “False” and finally, it initializes the UART (but not enables it yet) with the default settings, which can still be overwritten by the configuration script.

2.2. Configuration Script phase

This phase tries to locate and execute the Configuration Script (CS) from eFlash or QSPI Flash. The booter tries to locate the CS in the eFlash customer area at address 0. If no CS is found, it looks at the start of QSPI Flash after performing the generic reset QSPI function. This function performs a generic wake-up and reset that should be able to reset and wake up the majority of QSPI Flash devices.

After the CS is processed, the “XTAL Ignore” flag is checked. If it is not set, the XTAL32M is enabled and the booter checks if the settle and trim-ready bits are set within 10 ms. If not, the XTAL_ok Flag is kept at False, if it is settled correctly it is set to True. This flag is later used to detect if it is safe to switch to XTAL32M, or to continue using the default sys clock (RC32M).

The Booter uses a default 10 ms timeout between enabling the XTAL32M and checking the settling bits. This time can be overruled by the CS. Also, checking the settle bits can be overruled completely by the same keyword in the CS and the booter just assumes the XTAL is OK and settled.

2.3. Retrieve Application Code phase

During this phase, the booter scans to check if the development mode flag is disabled or not. If it is still in development mode, then it enables the Debug interface and tries to boot from UART. If booting from UART is successful, then it issues a software reset after having remapped address zero to RAM. If not, then it tries to locate a valid Flash header (first in eFlash then in QSPI Flash), trying to boot from Flash. If not in development mode, the booter continues to the next phase after having identified a valid product header in any of the embedded or QSPI Flashes.

2.4. Device administration phase

The device administration phase is used to check for pending updates and validate the Flash images. It also processes corresponding image headers and revoke keys, if needed. The booter checks if the “Active FW Image address” and the “Upgrade Image address” fields of the Flash product header are the same. If not, an upgrade image is available. The firmware validation is executed if the secure boot bit has already been set by the Configuration Script (CS).

Validation is done by identifying the public key, checking if the key is already revoked, and if not, proceeding with invoking the Ed25519 verification algorithm. This happens with the doubler being enabled and the system CPU running at 64 MHz.

Note

The booter does not manipulate the product headers in case of a firmware update. This should be taken care of by the application level which is also responsible for updating both product headers (primary and backup).

2.5. Load Image phase

In this final phase, the actual firmware image is loaded. This is done by setting up the eFlash/QSPI and cache controllers and executing the QSPI Loader if the application is running from QSPI, which is located in the Product header of Flash. The cache controller is then configured to point to the interrupt vector table (copied in RAM) and address zero is remapped to eFlash/QSPI Flash. Any error condition during this or previous phases results in a hardware reset.