2025-11-01 1:08 PM
I tried to follow this tutorial: How to build an AI application from scratch on the... - STMicroelectronics Community , could not figure out how to enable NPU RIF, so i skipped it. I tried to debug using the FSBL main.c, the blue led did turn on, but i got the error in the screenshot when trying to launch application in FSBL main.c. Project: willisk0612/nucleo-getting-started
2025-11-02 9:34 PM - edited 2025-11-02 11:33 PM
I had the same issue, but I managed to solve it.
For RIF - NPU, you can configure it in the RIF Panel before setting up X-CUBE-AI.
In XSPI2, set the following:
Chip Select Override: NCS1 -- Port2 --
Memory Type: Macronix
In EXTMEM_MANAGER → Memory1 →
Number of memory data lines: 8 LINES
After applying these settings, it worked for me.
I recommend creating a new project and setting it up again.
My English may not be perfect, but I hope this helps.
2025-11-04 8:36 AM
Thanks for the answer. It turned out i had to disable X-CUBE-AI software pack, enable NPU in RIF panel and enable X-CUBE-AI. I tried implementing the XSPI2 and EXTMEM_MANAGER changes you mentioned. I still get the same error when trying to debug. I also tried signing, flashing FSBL, Appli and weights, i did not get any LED response or COM response. I updated the github project repo above, so you can see my files. If someone has a working x cube ai stm32n6 nucleo project, i would appriciate a github or zip file, its very frustrating to fight these errors.
2025-11-04 6:33 PM - edited 2025-11-04 6:34 PM
2025-11-06 5:23 AM
@silpiode Thanks for the answer. I tried to implement your project, but i got no response from the COM port or LED still. Since i have no idea what may be causing the error, i tried debugging with the same config as you mentioned. The debugger hung at
SCB_EnableDCache();in AI_FSBL/Core/Src/main.c. Tried to uncomment that line, the debug pointer got stuck at
if (BOOT_OK != BOOT_Application())Again, i do not know if debugging is possible on this project, did you get the debugger to work? The tutorial used DK external loader in cubeprogrammer, i think this screenshot was from the previous tutorial he did on the STM32N6 DK board, so I switched to STM32N6 NUCLEO external loader.
Did you flash the files exactly like in the tutorial?
2025-11-06 6:00 PM - edited 2025-11-06 6:34 PM
Could you share your project, please?
I have newly created the project, verified the jump from FSBL to Appli in action, and am sharing it again.
When debugging this project, you need to upload the Appli.Debug.nucleo_ai_Appli-trusted.bin file to the STM32 N6 Nucleo board in advance using STM32CubeProgrammer.
2025-11-07 11:21 AM - edited 2025-11-07 11:26 AM
2025-11-08 4:32 PM - edited 2025-11-08 4:40 PM
I have reproduced the issue and found the solution.
When debugging, please press Resume (F8) to skip the SCB_EnableDCache(); line.
If you Step Over (F6) at SCB_EnableDCache();, the debugger will stop responding.
I confirmed that the program runs normally when skipping this line using Resume (F8).
2025-11-09 3:22 AM
@silpiode i got the same behaviour. But when debugging the application, my pointer seems to get stuck at this loop in app_x-cube-ai.c:
do {
// Execute first/next epoch block
ll_aton_rt_ret = LL_ATON_RT_RunEpochBlock(&NN_Instance_Default);
// Wait for event if required
if (ll_aton_rt_ret == LL_ATON_RT_WFE) {
LL_ATON_OSAL_WFE();
}
} while (ll_aton_rt_ret != LL_ATON_RT_DONE);It seems like LL_ATON_RT_RunEpochBlock(&NN_Instance_Default); expression always evalutes to LL_ATON_RT_WFE
The tutorial mentioned that we should add LED blinking after MX_X_CUBE_AI_Process(); to make sure it does not get stuck during inference. But that seems to be my problem if i am not doing anything wrong?
2025-11-09 5:18 AM
The “Cannot access memory at address” error usually indicates the debugger is trying to access an invalid or uninitialized memory region. Check that your FSBL and application memory regions match, and ensure the NPU RIF or required peripherals are properly enabled before launching the app.