Skip to main content
Associate III
June 16, 2026
Solved

Using a Single SD Card for Both STM32N6 FSBL Boot and FileX File System

  • June 16, 2026
  • 2 replies
  • 115 views

Hi,

We are currently evaluating the possibility of booting an STM32N655X0-based custom board from an SD card and would appreciate some guidance before committing to this design.

Current Setup

  • MCU: STM32N655X0

  • Custom hardware

  • Currently, the FSBL is downloaded directly into RAM during development.

  • The FSBL then loads the application from external flash.

  • We would like to migrate to SD card boot.

Understanding from UM3234

While reviewing UM3234 - How to Proceed with Boot ROM on STM32N6 MCUs, I found the following description (page 15):

In data transfer mode, the Boot ROM searches for two FSBL images. It first looks for a GPT header at LBA1. If GPT is present, the Boot ROM uses the GPT table to locate the FSBL images. If GPT is not found, it falls back to the default locations:

  • FSBL1: LBA 128

  • FSBL2: LBA 640

Our goal is to use a single SD card for both:

  1. Storing the FSBL used by Boot ROM

  2. Storing application data using FileX

What We Tried

Option 1: GPT Partitioning

We partitioned the SD card as follows:

  • Partition 0: Reserved for FSBL

  • Partition 1: FAT32 file system for FileX

The partition style used was GPT.

When opening the media using FileX:

fx_status = fx_media_open(&sdio_disk,
FX_SD_VOLUME_NAME,
fx_stm32_sd_driver,
(VOID *)FX_NULL,
(VOID *)fx_sd_media_memory,
sizeof(fx_sd_media_memory));

fx_media_open() failed and FileX eventually reformatted the entire card.

I noticed that FileX does not appear to provide a parameter to specify which partition should be mounted.

As an experiment, I modified the FX_DRIVER_BOOT_READ handling in fx_stm32_sd_driver() so that sector reads started from the offset corresponding to Partition 1 instead of LBA 0. This also reformatted the entire card.

Option 2: Using Hidden Sectors

I then experimented with the hidden_sectors parameter in fx_media_format() and configured it to reserve space at the beginning of the SD card for the FSBL region.

With this approach:

  • FileX formatting succeeded.

  • FileX file operations worked correctly.

However, when the SD card was inserted into a PC using a card reader:

  • Windows detected the device as a USB Mass Storage device.

  • The drive letter appeared.

  • Opening the drive resulted in the message:

    "Please insert a disk into drive G:"

This makes me think that the resulting partition/file system layout may not be compatible with what Windows expects.

Questions

  1. Is it officially supported to use a single SD card for:

    • STM32N6 Boot ROM FSBL storage, and

    • a FileX-managed FAT file system?

  2. What is the recommended SD card layout for this use case?

  3. Does FileX support mounting a specific partition on an SD card, particularly when GPT partitioning is used?

  4. Is the hidden sector approach the correct method, or should a standard MBR/GPT partition table be maintained?

  5. Once the layout is finalized, what is the recommended way to program the FSBL image into the required sectors (for example LBA 128)?

    • Can the SD card external loader provided for the STM32N657-DK be used for this purpose on a custom STM32N655X0 board?

    • Or is another programming method recommended?

Additional Concern

We are still in the research phase and want to be certain that this approach is fully supported before proceeding.

To enable SD card boot, we will eventually need to program the corresponding OTP boot configuration. Since this operation is irreversible, we would like to validate the entire workflow before committing to that step.

Any guidance, recommendations, or example implementations would be greatly appreciated.

Thank you.

Best answer by Khaled_DHIF

Hi ​@Gowri_M ,

Yes, this is feasible. Here is the recommended approach:

SD card layout

  • LBA 128: FSBL1 (Boot ROM default)
  • LBA 640: FSBL2 (Boot ROM default)
  • LBA 8192+: FileX partition (safe, no overlap with FSBL)

FileX and GPT

  • fx_media_open() has no built-in GPT partition selector. If you use GPT, you need to translate the partition start offset in the storage driver. Without that, FileX treats LBA 0 as the filesystem root and may reformat unexpectedly.
  • The simpler and more reliable approach for embedded use is to skip GPT and use a fixed hidden-sector offset in fx_media_format() so FileX starts at a known LBA beyond the FSBL regions. The "Please insert disk" message on Windows is expected when the partition table is non-standard — it does not affect embedded operation.

Programming FSBL
Sign with STM32_SigningTool_CLI -t fsbl -hv 2.3 -nk, then write to LBA 128 and LBA 640 via CubeProgrammer with the SDMMC external loader. The DK loader works for the DK board; custom hardware may need a matching loader for your bring-up environment.

Kind regards, 

DHIF Khaled

2 replies

ST Technical Moderator
June 18, 2026

Hello ​@Gowri_M 

Please refer to this article as starting point. 

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Saket_Om
Khaled_DHIFBest answer
ST Employee
June 19, 2026

Hi ​@Gowri_M ,

Yes, this is feasible. Here is the recommended approach:

SD card layout

  • LBA 128: FSBL1 (Boot ROM default)
  • LBA 640: FSBL2 (Boot ROM default)
  • LBA 8192+: FileX partition (safe, no overlap with FSBL)

FileX and GPT

  • fx_media_open() has no built-in GPT partition selector. If you use GPT, you need to translate the partition start offset in the storage driver. Without that, FileX treats LBA 0 as the filesystem root and may reformat unexpectedly.
  • The simpler and more reliable approach for embedded use is to skip GPT and use a fixed hidden-sector offset in fx_media_format() so FileX starts at a known LBA beyond the FSBL regions. The "Please insert disk" message on Windows is expected when the partition table is non-standard — it does not affect embedded operation.

Programming FSBL
Sign with STM32_SigningTool_CLI -t fsbl -hv 2.3 -nk, then write to LBA 128 and LBA 640 via CubeProgrammer with the SDMMC external loader. The DK loader works for the DK board; custom hardware may need a matching loader for your bring-up environment.

Kind regards, 

DHIF Khaled

"Please mark my answer as best by clicking on the “Accept as solution"" button if it fully answered your question. This will help other users find this solution faster.​"