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.
Solved! Go to Solution.
2025-02-08 09:13 AM - edited 2025-02-08 09:14 AM
Thank you again @RomainR. for your support, it is really appreciated,
I think it's due to the revision of the processor, the 'Z' revision has the LPTIM4 in the Errata, whereas the 'B' does not.
I believe I am doing everything right. STM32CubeIDE is upto date.
This debugging is using the Onboard STLinkV3 via USB.
Oddly enough, if I comment out the `HAL_Delay(100)` it runs just fine. Of course you can't see it blinking, but if you connect the scope you can see the pin toggling.
Enabling the HAL_Delay(), its like the stack always gets corrupted, which is just really weird. I am wondering whether its a problem related to the SysTick. I noticed that the SYS_S configuration is off by default in configuration. Changing it doesn't make a difference.
In summary, thank you its working alot better than it was before your help, however there are still some oddities which I am trying to figure out.
2025-02-08 11:53 PM - edited 2025-02-08 11:54 PM
Hi @exarian
I recommend that you purchase a recent board version that includes an STM32N6570 Revision B.
The board reference should be MB1940-N657X0Q-C02.
https://www.st.com/en/evaluation-tools/nucleo-n657x0-q.html#sample-buy
Thank you in advance for marking my reply as a accepted as solution.
Best regards
Romain,
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.