STM32N6: how to program external XSPI NOR flash over USB serial boot (DFU) without SWD

[Richu Bini]

Board: custom STM32N657Z0H3Q (not a Discovery/Nucleo)
Flash: Macronix MX25U12835F, 16 MB, Quad (x4), 1.8 V, no DQS
Tools: STM32CubeProgrammer 2.22.0 and 2.23.0, Linux

We need to program the external XSPI NOR flash (FSBL + application) using only USB serial boot / DFU, with no ST-LINK connection.
This is a product requirement, not a bring-up convenience. On our board, entering development boot requires BOOT1 = 1, and BOOT1 (PA6) is wired as DCMIPP_PIXCLK and actively driven by an on-board FPGA. We cannot reliably force that pin without contending with the FPGA driver. USB serial boot needs only BOOT0 = 1 and BOOT1 = 0, which is the FPGA-idle state, so it is the only strap combination that is safe on this hardware.
 

We attempted to relocate BOOT1 via OTP19 dev_boot_port/dev_boot_pin, and that attempt left the board permanently inaccessible. That is a separate open thread with no resolution so far: https://community.st.com/stm32-mcus-products-25/stm32n657-after-programming-otp19-dev-boot-port-dev-boot-pin-to-relocate-boot1-to-pn10-device-no-longer-enters-development-boot-168505

So the OTP route is closed to us, and SWD is not usable in the field. USB is what remains.

Question 1 — is there a supported way to run an external loader over DFU?

 

Programming external flash requires an external loader (.stldr) running in SRAM. Over SWD this works. Over USB DFU we cannot find any supported equivalent.

-el over port=usb1 segfaults the tool:

 

 

$ STM32_Programmer_CLI -c port=usb1 -el <loader>.stldr -w FSBL-Trusted.bin 0x70000000 -v
...
Loading Secondary Boot Loader into RAM ...
Segmentation fault (core dumped)        # exit 139

 

If -el is genuinely not supported over DFU, it should return a clear error rather than segfault. Please treat that as a defect report in its own right.

Is -elbl the intended path here? It is documented as "SFIx only," and we are not using SFI. If it can be used for plain external-flash programming over DFU, what is the correct invocation?


Question 2 - Is there any DFU partition ID that writes to external XSPI NOR persistently, or is DFU strictly RAM-only on STM32N6?

Question 3 — is our planned approach the intended one?
 

Given the above, our plan is:

1. Enter serial boot (BOOT0 = 1, BOOT1 = 0)
2. Use DFU to RAM-load a custom FSBL that includes its own USB device stack
3. That FSBL receives the FSBL and application images over USB
4. It writes them to the external XSPI NOR itself and reboots into flash boot

Effectively we would be writing our own external-flash programming agent because we cannot run ST's. Is this the expected approach for a board that cannot use SWD, or is there a standard CubeProgrammer mechanism we have missed? is there any tutorial or guide for this?  If there is a supported path, we would much rather use it than maintain our own loader.

 

[Khaled_DHIF]

Hello @Richu Bini ,

Thanks for the detailed information. You can use the STM32N6 ROM USB boot mode to start CubeProgrammer’s OpenBL flash-layout workflow; you do not need to add a separate USB stack to your FSBL. Configure and build an OpenBL ExtMemLoader for your board’s XSPI flash, then list the OpenBootloader image, ExtMemLoader (fsbl-extfl), and application (fsbl-app, destination nor0) in the flash-layout TSV. Then Run:

STM32_Programmer_CLI -c port=usb1 -d <FlashLayout.tsv>

The ROM DFU interface does not itself provide a general XSPI-NOR partition. OpenBL and the ExtMemLoader provide the external-flash programming step. Use this flow rather than -el or -elbl for this setup.

Separately, the segmentation fault reported with -el is unexpected; it does not establish that external loaders are unsupported over USB. Please share the actual .stldr and full log so we can investigate that CubeProgrammer issue.

​Kind regards, 

DHIF Khaled