2025-02-07 07:19 AM
Good day Folks,
I am trying to get a simple program working on the STM32N6 Nucleo board, however when debugging an interrupt
occurs causing the code just to get stuck in the Default Handler.
I am not sure what interrupt is triggering it.
This is most likely a 1 line fix, or some arbitrary setting I haven't found yet.
Steps:
1. Change Boot 1 jumper to VCC
2. Connect USB, Red LED2 is On.
3. Started a new STM32 project and used the Example Selector. Select and Build GPIO_IOToggle.
4. Make Debug profile and connect
5. Wait until main() entered.
6. Click Run.. No LED flashing so Pause debugger
7. Resetting the Micro just freezes and the device never gets the first main() breakpoint. I was expecting it to return to Step 5.
8. Pausing at that point just shows the device is at some address.
9. We need to restart the debugger session from scratch:
In summary, Pausing the Debugger on Step 6 shows its stuck. I don't believe it's anything related to XSPI3, as adding a handler for it, just makes the code get stuck in the XSPI2 handler instead. Also viewing the XSPI3 its all zeros.
I am just trying to run the FSBL from RAM and not load it from the Flash.
Optimize for Debug has been added, as I saw other people had issues with a HardFault triggering in some instances.
Note: The onboard application runs fine with Boot1= 0, pressing the blue button changes the 3 LED's.
Thank you in advance, it's pretty frustrating as I am just trying a simple blinky and it doesn't seem to be working.
2025-02-07 07:24 AM
2025-02-07 07:33 AM
Hello,
https://community.st.com/t5/stm32-mcus-embedded-software/freertos-with-usb-cdc/m-p/766406#M59420
2025-02-07 07:37 AM
Thank you @SofLit for your swift response.
The project is not using USB or FreeRTOS.
I am just attempting to use the default example project. I wasn't aware that anything else needed to be configured?
2025-02-07 07:42 AM
My answer is generic not related to USB or FreeRTOS. If you have that behavior, it means you have an interrupt that is firing without any IRQ handler defined.
2025-02-07 10:09 AM
Thank you. If I put a breakpoint in Reset_Handler, and check the SCB, there is a Pending interrupt already immediately on powerup.
Clicking Run, and Pausing, It just shows that the VECTACTIVE = 0x9B.
I haven't changed the example project, I'm just trying to get it to run. This is on the STM32N6 Nucleo board.
No hardware has been modified, besides Boot1 being changed to 3.3V.
The STLink firmware has been updated to:
I've used other STM32 variants before such as the STM32H7, but have not ran into these issues. Especially not on a Dev kit.
2025-02-07 11:22 AM
I've figured out that the interrupt which is being triggered is for LPTIM4.
I have not added this to the project so it was a real surprise.
It is disabled in the IDE config.
Checking LPTIM4 on Reset, shows that it has been configured and its running.
I am assuming that the debugger uses it as when I disable the interrupt, then the debugger just crashes shortly after.
I am not having much luck even with a simple Blinky, my thoughts are leaning towards having a damaged board somehow.
How can I build and program a simple blinky that just runs in RAM?
Lets google and see what comes up..STM32N6 Errata
Great, so the kit is not usable at all then?