The basic idea of a flash kernel and how the firmware upgrades has been described, the next section details the first step of the process: loading the kernel to RAM via bootROM.

At the beginning, the device boots and, based on the boot mode, decides if the device executes the code already programmed into the Flash memory or load in code using one of the ROM loaders. This application note focuses on the boot execution path when the emulator is not connected.

After the boot ROM readies the device for use, the device decides where to start executing. In the case of a standalone boot, the device does this by examining the state of two GPIOs (as seen in Table 2-2 , the default choices are GPIO 72 and 84). In some cases, two values programmed into one time programmable (OTP) memory can be examined. In the implementation described in this application note, the UART loader is used, so at powerup GPIO 84 must be forced high and GPIO 72 must be forced low. If this is the case when the device boots, then the UART loader in ROM begins executing and operates at a baud rate of 115200. At this point, the device is ready to receive code from the host.

A major difference between the previous C28-based devices and the F29H85x is the inclusion of the Hardware Security Module (HSM). All boot flows require the HSM to authenticate the incoming image before the boot flows can be executed.

Please see the ROM code and Peripheral Booting section of the Technical Reference Manual (TRM) for details on the boot flow. And Device Boot Flow Diagrams section, on how the HSM and C29 CPUs communicate during the boot sequence.