How to execute code from the external serial NOR using the STM32N6

B.Montanari · ‎2025-02-20

Summary

The first stage bootloader (FSBL) is a key component in the boot process of STM32N6 microcontrollers. It’s 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 and have it configure the external serial NOR FLASH in Execution in Place (XiP), including the process to configure and program the external memory.

Introduction

At power-on, the boot ROM copies the FSBL binary from the external serial NOR flash 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 and configuring the external memories. 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 boot ROM, check this 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. The example shows a simple blink LED running directly from the external serial NOR FLASH. The project will have two binaries, one for the FSBL and another one for the external FLASH. Both have the header added and programmed on the external memory. It's up to the FSBL to execute the XSPI in memory-mapped mode to allow the execution from the external FLASH.

1. FSBL main features

The FSBL can be used in several different ways, each suited to specific application requirements. The following section describes the mode that the FSBL is used in this article.

1.1 FSBL and application running from external flash

In this mode, the FSBL and application are in different addresses of the external flash memory. The boot ROM copies the FSBL from the external memory into the internal SRAM. It’s up to the FSBL to prepare the memory to operate in memory-mapped mode and jump to the application’s location to be executed directly from the external FLASH. The visual representation can be observed in the small animation below:

2. Hands-on: blink LED

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:

2.1 FSBL and application: blink code in XiP

2.1.1 Configure the LED pin

The project needs to configure a few peripherals to work properly, including the green LED, associated with the PO1 and its active HIGH and the external memory connected to XSPI2.

Start by creating 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 application.

2.1.2 Configure the XSPI and XSPIM

Locate the [XSPIM] on the left side under the "Connectivity" menu, and select it to run during the [First Stage Boot Loader] and have the [Direct] mode selected:

The Octo‑SPI flash memory has the following characteristics: 1 Gbit, 1.8 V, 200 MHz, DTR, read while writing. It’s 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:

2.1.3 Configure the EXTMEM_MANAGER

The next step is locating the [Middleware and Software Packs] in the [Categories] and expand the [EXTMEM_MANAGER]. Add the [First Stage Boot Loader] and the [Activate External Memory Manager] checkbox, using the following settings:

[XiP Application offset] = 0x00100000

[XiP Header size] = 0x400

In the [Memory 1] tab, ensure that the configuration is as follows:

2.1.4 Configure the XSPI clock

The last step for the XSPI is to configure its clock. We set the XPI clock to 50 MHz for this example. To achieve higher speeds up to the 200 MHz supported by this serial NOR FLASH, you need to make changes to OTP for I/O speed optimization. This isn’t 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:

Proceed with the code generation for both projects.

2.1.5 Code editing and build

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 */

Make sure that your project settings are configured to generate the *.bin as well, since we’ll use it to run the scripts:

2.1.6 Adding the header

We need to add the FSBL header to ensure that the boot ROM is capable of reading and copying it from the external memory. Also, that the same header is added for the application. To do this, we 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, it’s possible to type “cmd” in the binary folder, for example ..\XIP\XIP\STM32CubeIDE\Appli\Debug. This will pop up the cmd in the selected path.

Note that this process needs to be performed on the appli and the FSBL, so here are the commands for each one, assuming the project name is XIP:

Build both projects, making sure the *.bin file is created for both the _Appli and the _FSBL projects. Once the build is done successfully, we’ll 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 XIP_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 XIP_Appli.bin -nk -of 0x80000000 -t fsbl -o Appli-trusted.bin -hv 2.3 -dump Appli-trusted.bin

When issued, this is the expected output:

This will create the header for the binary, which can now be loaded into the external FLASH using STM32CubeProgrammer.

2.1.7 Programming the binaries

Make sure the external loader for the flash enabled:

And use the address [0x7000 0000] to program the FSBL binary and the [0x7010 0000] to program the application binary:

TIP: you might need to power cycle the board in case a failure message appears when clicking [Start Programming] and ensure it’s positioned in DEV boot mode.

2.1.8 Validation

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 being executed from an external flash!

Conclusion

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-DK, demonstrating how to implement the FSBL. Additionally, how to configure the external memories to run the application from the external serial NOR flash. By following these steps, developers can ensure a smooth and efficient boot process for their STM32N6-based projects.