STM32N6 Nucleo - Interrupt loop preventing bootup

[exarian]

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.

[exarian]

Included the reference project here

[SofLit]

Hello,

https://community.st.com/t5/stm32-mcus-embedded-software/freertos-with-usb-cdc/m-p/766406#M59420

[exarian]

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?

[SofLit]

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.