Request for steps to run STM32N6 application in DEV_BOOT mode

[viruthi]

  Referred Ticket: How to run program on STM32N6 after flashing without changing BOOT-1 jumper | Community
Thank you for confirming that it is possible to run the application while keeping BOOT1 in DEV_BOOT mode by loading a RAM executable, performing a core reset, setting the SP and PC, and then running the core.

My target is: STM32N6570-DK

I need to achieve the following flow:

1. Flash and verify the complete HEX file (Example: STM32N6-GettingStarted-ImageClassification/Binary/STM32N6570-DK at main · STMicroelectronics/STM32N6-GettingStarted-ImageClassification)

2. Keep the STM32N6570-DK physically in DEV_BOOT mode.

3. Start the flashed application automatically without manually changing the BOOT1 jumper.

4. Perform the complete operation through command-line tools or a user script.

The following command successfully flashes and verifies the image:

STM32_Programmer_CLI.exe `
-c port=SWD mode=UR reset=HWrst `
-el "ExternalLoader\MX66UW1G45G_STM32N6570-DK.stldr" `
-w "STM32N6570-DK_GettingStarted_ImageClassification.hex" `
-v

However:

-run

only reports:

Core run

and the application does not start.

Using:

-s

attempts to run from 0x08000000, and the core later enters a locked-up state.

Could you please provide a complete working example or user script (as mentioned in the referred Ticket comment) showing:

1. Which FSBL/debug binary or ELF should be loaded into AXISRAM.

2. How to determine the correct AXISRAM load address.

3. The STM32CubeProgrammer CLI command to load the RAM executable.

4. The command for performing a core reset without clearing AXISRAM.

5. How to read or set the initial stack pointer (SP/MSP).

6. How to set the program counter (PC) to the FSBL reset handler.

7. How to start execution after setting SP and PC.

8. Whether STM32CubeProgrammer CLI alone supports all these operations.

9. Whether an STM32CubeProgrammer user script is available for this STM32N6570-DK use case.

10. If STM32CubeProgrammer alone is insufficient, whether ST-LINK GDB Server and GDB are the recommended command-line solution.

I am using:

• Board: STM32N6570-DK

• STM32CubeProgrammer: v2.23.0

• Probe: ST-LINK-V3

• External flash: MX66UW1G45G

• External loader: MX66UW1G45G_STM32N6570-DK.stldr

• Application: STM32N6 Getting Started Image Classification example

• External flash base address: 0x70000000

My final goal is to automate the following flow in a service:

Flash external HEX
→ Verify
→ Load RAM FSBL
→ Core reset
→ Set SP and PC
→ Run FSBL
→ Start external-flash application

A complete STM32CubeProgrammer user script, or GDB script example would be very helpful.

[FBL]

Hi ​@viruthi 

I will check internally and get back to you.

[viruthi]

Hi ​@FBL, Any Update regarding this

[FBL]

Hi ​@viruthi 

A quick clarification first: on STM32N6, the normal application boot flow is Flash or Serial boot, not a pure “run from external flash in DEV_BOOT by just pressing run” style flow.

I’ve tried this on my end 

1. "C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe" -c port=SWD mode=HOTPLUG ap=1 -w "C:\STM32Cube\Repository\STM32Cube_FW_N6_V1.4.0\Projects\STM32N6570-DK\Examples\GPIO\GPIO_IOToggle\EWARM\FSBL\GPIO_IOToggle_FSBL\Exe\GPIO_IOToggle_FSBL.bin" 0x34180400
2. "C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe" -c port=SWD reset=Crst -coreReg PC=0x34182181 MSP=0x34180400

The PC value is located at offset 0x4 from the vector table base

• MSP = word at 0x34180400 and PC = word at 0x34180404

and it’s blinking as expected.

 

[viruthi]

​@FBL , Thank you for providing the working example.

I have one clarification regarding the GPIO_IOToggle_FSBL.bin example.

As I understand it, the GPIO toggle example is loaded directly into AXISRAM and executed from RAM:

Load GPIO_IOToggle_FSBL.bin into AXISRAM
→ Core reset
→ Set MSP and PC
→ Run
→ GPIO application executes

In this case, does the example actually access or boot anything from the external flash, or is the complete GPIO application executing directly from AXISRAM?

My actual use case is slightly different. I have an AI application, such as the STM32N6 Getting Started Image Classification example, whose complete HEX image has already been programmed and verified in external flash starting at 0x70000000.

I want to keep the board permanently in DEV_BOOT and achieve:

Flash complete AI application HEX to external flash
→ Load a small FSBL/bootstrap executable into AXISRAM
→ Core reset
→ Set MSP and PC
→ Run the RAM FSBL
→ FSBL initializes the required peripherals/external flash
→ Boot/start the AI application already stored in external flash

Would the same procedure demonstrated with GPIO_IOToggle_FSBL.bin work for this type of application?

More specifically:

1. Is GPIO_IOToggle_FSBL.bin only demonstrating execution of an application directly from AXISRAM, or does that FSBL also demonstrate booting an application from external flash?
2. For applications such as STM32N6-GettingStarted-ImageClassification, do I need a different RAM-resident FSBL specifically built to initialize XSPI/external flash and start the application stored there?
3. Can the existing ai_fsbl.hex / FSBL from the Image Classification example be used for this purpose in DEV_BOOT, or is a separate RAM-linked version of the FSBL required?
4. If a RAM-linked FSBL is required, could you please provide the corresponding binary/ELF or the linker configuration and AXISRAM load address for the STM32N6570-DK?

My goal is not to execute the complete AI application from RAM. I specifically want to keep the application and model in external flash and use a small RAM executable only to reproduce the boot process while keeping BOOT1 physically in DEV_BOOT.

Ultimately, I would like to automate this entirely using STM32CubeProgrammer CLI without changing the BOOT1 jumper.