STM32N657 XIP + STM32CubeAI Studio – aiRun() stuck in LL_ATON_RT_WFE loop

[ayaaaa]

Hello,

I’m working on a project generated by STM32Cube AI Studio targeting the NUCLEO-N657X0-Q, using an XIP configuration with external XSPI flash ( It was said in another post that the generated projects from STM cube AI Studio follow XIP configuration).

---

Setup

• Board: STM32N657X0-Q
• Toolchain: STM32CubeIDE(2.1.1) + STM32CubeProgrammer(2.22.0)
• Project generated with STM32Cube AI Studio
• Execution mode: XIP (application in external flash)
• Runtime: Bare metal (LL_ATON_OSAL_BARE_METAL)

---

Memory mapping

Model location (from generated network.c):

.addr_base = (unsigned char *)(0x71000000UL)

---

Programming steps

I programmed manually using STM32CubeProgrammer:

• second_Appli.elf 
• network_atonbuf.xSPI2.bin → placed at 0x71000000

---

Debug configuration (FSBL project)

I start debugging from the FSBL project.
In Debug Configuration → Startup → Load Image and Symbols, I configured:

• second_Appli.elf
  • Download = OFF (already flashed manually)
  • Load symbols = ON

So FSBL is loaded/debugged, while App and model are already present in flash.

Additionally, I also tried adding the runtime GCC libraries to the FSBL debug configuration, but this did not change the behavior

---

 What works

• FSBL runs correctly from RAM (0x3418xxxx)
• XSPI initialization seems correct
• Jump to application works

• Application reaches:

  STM32CubeAI_Studio_AI_Init();
  STM32CubeAI_Studio_AI_Process();

• Execution enters:

  aiRun();

---

 Problem

Execution gets stuck in:

do {
ll_aton_rt_ret = LL_ATON_RT_RunEpochBlock(&NN_Instance_network);

if (ll_aton_rt_ret == LL_ATON_RT_WFE)
LL_ATON_OSAL_WFE();

} while (ll_aton_rt_ret != LL_ATON_RT_DONE);

Observed behavior:

• ll_aton_rt_ret remains LL_ATON_RT_WFE
• Loop never exits

---

Question

• is this the right debug configuration for projects generated by STM Cube AI Studio ?
• if so ,is there additional steps before debugging so that the inference ?

Thanks for your assistance 

[ayaaaa]

 Additional debug attempts (LED + UART)

 LED test

To verify that the application is actually running, I added a simple GPIO test:

• Configured a GPIO pin as output in MX_GPIO_Init()
• Set the pin high before and after aiRun()

Result

• The code does reach the LED control function
• However, the LED does not visibly toggle .

---

UART / printf test

I also tried UART debugging. USART1 is initialized and I have used USART1 successfully on the same board in other projects. However, in this Cube AI Studio project, printf does not output anything. I noticed that _write() is already defined in aiTestUtility.c, so I did not add a duplicate _write() in main.c.

---

 Interpretation

• The application does execute (Confirmed by code stepping)
• But : aiRun() never completes (still stuck in LL_ATON_RT_WFE)
• Could not debug with printf /leds as they dont output anything despite not having any building errors and the code stepping in their functions .

Can you please provide and explanation/tutorial that would be very helpful 

[ayaaaa]

Update : 

I now understand that not being able to use the virtual com port or leds to debug was because they were not configured in the generated Cube mx project , but i still didnt find a solution to the inference stuck in the aiRun() Loop

[ayaaaa]

i attach here my full project on zip format 

can you please look into it 

[hamitiya]

Hello @ayaaaa 

On my side, your project is not stuck in the while loop:

I will share with you a NUCLEO-N657X0-Q project with outputs in UART, if it works on your side, I will try to help you to modify the model integrated in it.

Best regards,

Yanis

[ayaaaa]

Thanks for your reply ! 

Okay i see , i must be doing something wrong then in the debugging phase , can share with me please how you debugged (app/fsbl) with options and also the positions of boot 0 and boot1. Thanks 

[ayaaaa]

Im sorry but it doesnt work , when i try to debug the application i get this error 

and when i try to debug the fsbl it doesnt get to the application , was i supposed to flash it manually beforehand or anyhting else ? 

[hamitiya]

Hello,

Yes, startup is quite tricky. 

Either you start using this tutorial: How to debug STM32N6 using STM32CubeIDE - STMicroelectronics Community

Or, you can avoid signing procedure by:

- Flash Appli.elf with STM32CubeProg

- Power cycle your board

- Start your debug session with FSBL, and "Download" only the FSBL .elf file. 

Best regards,

Yanis

[ayaaaa]

i did actually end up following the tutorial ( which i did in my intiial project too ) 

this is the configuration : 

i ended up with the same error on the fsbl debug too !

I figured it might be a board problem , but its not as old project debug normally . 

[hamitiya]

Could you please try to disable the first "binary" flash and only load the FSBL to see what happens?

You have two kinds of errors:

- ST-Link probe undetected => power-cycle required

- Startup issue => related to flashing procedure

Be aware that setting up breakpoints prior to jump to Application can lead to startup issues as well.