How to execute code from the external PSRAM 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 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 to copy the application from an external serial NOR FLASH to an external serial PSRAM, 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, 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, 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 PSRAM. The example will have two binaries, one for the FSBL and another one for the application. The header will be added and programmed on the external serial NOR flash memory. It's up to the FSBL to copy the application from the external FLASH to the external PSRAM and execute the application.

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 will be used in this article.

1.1 FSBL and application running from an external PSRAM

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 PSRAM

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 XSPI1, XSPI2, 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:

The hexadeca-SPI PSRAM has the following characteristics: 256 Mbit/s, 1.8 V, 200 MHz, DDR. It is connected to the hexadeca-SPI interface of the STM32N657X0H3Q, which is associated with the XSPI1. With that information, go to XSPI1 to configure the peripheral according to the hardware available:

As for the [Parameters Settings], please carefully look 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:

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

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

With the memories properly configured, it’s possible to use the [Boot usecase] tab and add the Load and Run selection, copying from the serial FLASH NOR (Memory 1) to the external PSRAM (Memory 2). The addresses and offsets are shown below:

2.1.4 Configure the XSPI clock

The last step for the XSPI is to configure its clock. For this example, we set the XPI clock to 50 MHz. 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:

2.1.5 MPU Configuration

To avoid unwanted cache activity during the copying process, let’s configure the MPU for the external memories. Locate the [CORTEX_M55_FSBL] in the [System Core]. Enable the MPU Control Mode in [Background Region Privileged access only + MPU Disabled during hard fault, NMI and FAULTMASK handler]. If you need more details on MPU, please consider this article here.

It’s worth highlighting this table from the reference manual, showing the mapping addresses for each XSPI:

With that information, along with the offsets used on the EXTMEM_MANAGER, add the MPU region for the external serial NOR FLASH and PSRAM. Starting with the serial NOR FLASH, which will be assigned to Region 0:

Add Region 1 for the external PSRAM:

2.1.6 Generate Code

All settings are now completed and it’s time to proceed with the code generation for both projects:

2.1.7 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:

And change the default linker script that was made for the Load and RUN to the ROMxpsi1.ld. This can be done by locating the [MCU/MPU GCC Linker][General] and changing to STM32N657X0HXQ_ROMxspi1.ld

In the _FSBL project, locate the stm32_boot_lrun.c file and change the define [EXTMEM_HEADER_OFFSET] to be 0x400, since we’ll use the header script in the application as well.

Build both projects by pressing [Ctrl]+[B].

2.1.8 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: ..\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 projects, so here are the commands for each one, assuming the project name is FSBL_PSRAM:

After building both projects, make sure the *.bin will be 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 FSBL_PSRAM_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 FSBL_PSRAM_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.9 Programming the binaries

Make sure that the external loader for the flash memory is 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 is positioned in DEV Boot mode.

2.10 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 the external PSRAM!

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 PSRAM. By following these steps, developers can ensure a smooth and efficient boot process for their STM32N6-based projects.