on 2025-02-14 04:48 AM
The First Stage Boot Loader (FSBL) is a key component in the boot process of STM32N6 microcontrollers. It is responsible for initializing the system, configuring the hardware, and loading the application code from external memory into the internal or external memories for execution. This article provides a quick tutorial on how to use the FSBL in the load and run mode including the process to program the external memory.
It covers two practical examples, the first being a simple blink LED application running directly from the FSBL. The second being a more useful setup, where the FSBL loads an application from external memory and runs it from the internal RAM.
At power on, the boot ROM copies the FSBL binary from the external memory into the internal SRAM. Once the boot ROM task is completed, it will jump to the FSBL project, which is usually responsible for executing the clock and system settings, configure the external memories and finally, it either copies the application binary in internal SRAM or sets the external memory in memory mapped mode. When done, the application itself starts up and runs. If you want to know more about the boot ROM, please check this knowledge article.
On STM32N6 MCUs, the first-stage bootloader (FSBL) must be signed or at least have a valid header, so the boot ROM can execute it in a secured-locked state. The FSBL layout includes several key components, and more details are available in this article.
This article uses the STM32N6570-DK as base for its hands-on portion, but the content can be tailored to any specific STM32N6 hardware. Two examples are shown: the first example is a simple blink LED running directly from the FSBL, and the second example is composed of two binaries, the application and FSBL. Both examples have the header added and programmed on the external memory. It is up to the FSBL to execute the application directly from the internal RAM, or copy from the external FLASH to the internal RAM and execute the application.
The FSBL can be used in several different ways, each suited to specific application requirements. The following sections describe the two modes that the FSBL is used in this article.
In this mode, the boot ROM fetches the FSBL from external serial NOR flash memory. As the FSBL and application are contained in the same binary, there is a 511 KB size limitation in this mode. This is due to the total area of 512 KB that the boot ROM copies from the external memory into the internal SRAM. The visual representation can be observed in the small animation below:
In this mode, the boot ROM fetches the FSBL from external flash memory. This time, the FSBL proceeds to configure the external memory and fetch a second binary stored in it, then copy it into internal SRAM. Once the binary is loaded, the FSBL jumps to the new position in RAM, where the application code is located and starts the execution. This mode is applicable to a few examples available in the STM32Cube_FW_N6. The interesting aspect is that the 511 KB size limitation is no longer applicable, as the user code can be placed in the remaining area of the internal RAM.
This article assumes you have installed STM32CubeMX (6.13 or later), the latest version of the STM32N6 HAL driver, STM32CubeProgrammer (2.18 or later), and STM32CubeIDE (1.17.0 or later). The hardware used to showcase is the STM32N6570-DK and make sure you have it in DEV boot mode to program the code:
The project needs to configure a few peripherals to properly work, including the green LED, associated with the PO1 and its active HIGH to validate the first step. Also, the FSBL and application being in the same binary. So, let us start with this initial configuration first.
Create a new project using the STM32CubeMX and select the [STM32N657X0H3Q]. Select the option to use the [Secure Domain only].
Locate the PO1 and configure it as GPIO_Output and use the label to name it GREEN_LED.
We need to assign the GPIO to be used by the FSBL
In the [Project Manager] tab, ensure the [FSBL] checkbox is selected and generate the code for your preferred toolchain.
Once the project is created, add these two lines in the main loop:
while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
HAL_GPIO_TogglePin(GREEN_LED_GPIO_Port, GREEN_LED_Pin);
HAL_Delay(100);
}
/* USER CODE END 3 */
Make sure that your project settings are configured to generate the *.bin as well, since we use it to run the scripts.
Enter in debug mode and validate that your code is working. Now that you have, we need to add the FSBL header to ensure that the boot ROM is capable of reading and copying it from the external memory. In order to do this, we will use the STM32CubeProgrammer’s CLI. The next assumes the STM32CubeProgrammer was installed in the default path, if not, make sure to adjust it accordingly.
To facilitate the process, its possible to type [cmd] in the binary folder. For example ..\LED_Toggle\STM32CubeIDE\FSBL\Debug. This will pop up the cmd in the selected path and its possible to use the command below:
"C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_SigningTool_CLI.exe" -bin LED_Toggle_FSBL.bin -nk -of 0x80000000 -t fsbl -o Project-trusted.bin -hv 2.3 -dump Project-trusted.bin
This creates the header for the binary, which can now be loaded into the external FLASH using STM32CubeProgrammer.
Make sure that the external loader for the FLASH memory is enabled and use the address [0x7000 0000] to program the binary.
TIP: you might need to power cycle the board in case failure message appears when clicking [Start Programming].
To validate the entire process worked, disconnect from the STM32CubeProgrammer. Then switch BOOT1 to 0 and reset the board. This ensures the boot ROM uses the external memory and the green LED should blink.
Now that we concluded the process to run our simple code from the FSBL, it's time to implement the second example. This example consists of having the FSBL to copy the application content from the external FLASH to internal RAM, and executing the code from there.
Using the same STM32CubeMX project, locate the [XSPIM] under the [Connectivity] menu on the left and select it to run during the [FSBL] and have the [Direct] mode selected:
The OCTOSPI flash memory has the following characteristics: 1 Gbit, 1.8 V, 200 MHz, DTR, read while writing. It is connected to the OCTOSPI interface of the STM32N657X0H3Q microcontroller on the STM32N6570-DK board on XSPI2. With that information, go to XSPI2 to configure the peripheral according to the hardware available:
As for the [Parameter Settings], look carefully at the image below:
The next step is locating the [Middleware and Software Packs] in the [Categories]. Expand the [EXTMEM_MANAGER]. Add the FSBL and activate it using the following settings:
[LRUN source address offset] = 0x00100000
[LRUN source code size] = 0x10000
[LRUN destination address] = 0x34000000
In the [Memory 1] tab, ensure its as follows:
The last step for the XSPI is to configure its clock. For this example, we will set the XPI2 clock to 50MHz. To achieve higher speeds up to the 200 MHz supported by this serial NOR FLASH, you need to make changes to OTP for IO speed optimization, which is not covered in this article. Go to the [Clock Configuration] tab and have the IC3 as the source for the XSPI2 and type 50 and press enter for the clock to be automatically adjusted:
Now that we are done with the XSPI, it is time to add the [APPLI] checkbox in the [Project Manager] tab, so the application project can be created:
And roll back to the [Pinout & Configuration] tab to change the [GPIO] LED pin to be assigned to the application instead of the FSBL:
Proceed with the code generation for both projects.
In the _Appli project, locate the main.c file and add the toggle LED function call in its main loop:
/* USER CODE BEGIN WHILE */
while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
HAL_GPIO_TogglePin(GREEN_LED_GPIO_Port, GREEN_LED_Pin);
HAL_Delay(200);
}
/* USER CODE END 3 */
In the FSBL project, remove the previous user code portion in the main.c file, responsible for the LED toggling we had in the first hands-on. Make sure to either change the #define EXTMEM_HEADER_OFFSET from 0x0 to 0x400 in the stm32_boot_lrun.c or define it in the stm32_boot_lrun.h. The reason is that our application also has the 1 KB header, added by the script.
Build both projects, making sure the *.bin is created for both the _Appli and the _FSBL projects. Once the build is done successfully, we perform the same step of calling the STM32CubeProgarmmer’s CLI in each of the binaries respective folder to perform the signing. These are the commands:
FSBL:
"C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_SigningTool_CLI.exe" -bin LED_Toggle_FSBL.bin -nk -of 0x80000000 -t fsbl -o FSBL-trusted.bin -hv 2.3 -dump FSBL-trusted.bin
Application:
"C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_SigningTool_CLI.exe" -bin LED_Toggle_Appli.bin -nk -of 0x80000000 -t fsbl -o Appli-trusted.bin -hv 2.3 -dump Appli-trusted.bin
Use the same process using the STM32CubeProgrammer to program the FSBL at address 0x7000 0000 and the appli at address 0x7010 0000. Remember to have the STM32N6’s BOOT1 set to HIGH and reset or power cycle the board before programming.
To see your application running, have the BOOT1 set to LOW, disconnect the programmer and power cycle. Now, you have the green LED blinking with the code copied from the external FLASH into the internal RAM by your custom FSBL!
By understanding the FSBL layout and its main features, developers can effectively utilize the FSBL to meet their specific needs. This article has provided a hands-on tutorial using the STM32N6570 discovery kit. demonstrating how to implement and run applications directly from the FSBL and how to configure the FSBL to load and run applications from external memory. By following these steps, developers can ensure a smooth and efficient boot process for their STM32N6-based projects.