STM32N6 USB Serial boot not working with STM32CubeProgrammer

[washburne018]

I cannot get USB DFU serial boot to work correctly with STM32CubeProgrammer.

I keep getting the error "Please specify Binaries path" but there is no area to specify the binary path.

Does anyone have any experience with USB serial boot on the STM32N6.

If USB serial boot isn’t working on the STM32N6, first check that you’re running STM32CubeProgrammer 2.18 or newer since that’s when N6 support was added. Make sure the chip is in the right boot mode for usb serial using the boot0/boot1 settings, then try connecting through usb in cubeprog right after a reset. on linux, don’t forget the udev rules or run it once as root so the device is detected properly. It also helps to avoid hubs or adapters at the start and plug directly into the pc. If it still doesn’t show up, it’s worth rechecking the boot pin wiring and swapping the cable or port.

[washburne018]

After verifying the device was enumerating appropriately and being identified by cube programmer correctly, I realized that it expects a .tsv file to be opened in the Memory & File Editing page so that the "Binaries path" input box will pop up.

Once connected to cube programmer, the "Partitions" tab in the Memory & File Editing page shows 5 partitions with the name, id, size, and rights. below are the names and Ids.

• FSBL - 0x1 
• RSSE_FW - 0xf3
• RSSE_BLOB - 0xf5
• RSSE_PLUGIN - 0xf6
• virtual - 0xf1

Can cube programmer use a .tsv file to write to the AXI SRAM similar to how the debug sessions will write data into the AXI SRAM?

I've run into an odd situation where it may be best to always boot the device over USB rather than program some external flash.

Yeah, cube programmer does expect a .tsv file to map out partitions and binaries, but it doesn’t directly stream into AXI SRAM like debug sessions. It’s more for flashing partitions (like FSBL, RSSE, etc.) into storage. If you want to boot from SRAM/USB without touching flash, you’ll usually need to load binaries via the debugger or a dedicated USB boot mode instead of through the .tsv flow.

Might be worth checking if your chip supports a USB/SRAM boot path—that could fit your “always boot over USB” idea better.

[Mikk Leini]

I tested USB DFU on STM32N6570-DK. I bring BOOT0 high and reset MCU. USB DFU device is found in PC. I use STM32CubeProgrammer v2.22.0 CLI and this command:

STM32_Programmer_CLI.exe -c port=usb1 -d firmware.bin 0x1 -detach

-d and -w do the same thing. It downloads signed (see How to add the STM32N6's header signature as post ... - STMicroelectronics Community) firmware binary (no .tsv needed) into partition 1 which is SRAM (probably AXISRAM2) and launches it from there after detachment. It is not programming external flash because after bringing BOOT0 low and resetting MCU, code that was in flash is run instead.