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

[mƎALLEm]

Hello,

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

[exarian]

Thank you @mƎALLEm 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?

[mƎALLEm]

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.

[exarian]

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.

[exarian]

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?

 

[RomainR.]

Hello @exarian 

 

"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?

Great, so the kit is not usable at all then?"

Okay, I am sorry that you are encountering such issues with pausing and restarting the debugger with your Nucleo-N657X0-Q. And before incriminating your board, let me give you some help:

1) Your attached archive GPIO_IOToggle_export.zip is incomplete. The main sources codes are missing.
If you imported the example project from STM32CubeMX, it might sometimes cause these problems.
Please proceed as follows:
From the local directory C:\Users\yourname\STM32Cube\Repository\STM32Cube_FW_N6_V1.0.0\Projects\NUCLEO-N657X0-Q\Examples\GPIO\GPIO_IOToggle\STM32CubeIDE.
Double-click directly on .project (see below).




The example will be automatically imported into your STM32CubeIDE workspace. This should resolve the issue you described in step 6. Click Run. No LED flashing so Pause debugger.

2) Now regarding the behavior of the suspend and reset buttons, the behavior of the reset must be modified, because after a system reset the BootROM has restarted, and we must inform the STLink GDB server to set the program counter (pc) and stack pointer (sp) registers to the correct addresses. This can be done by changing the Restart Configurations settings.

Then changing the system reset by a Core reset, and add the correct addresses for sp and pc as below:

      

Here pc = 0x34180404 corresponds to Reset handler and 0x341FFD00 corresponds to the beginning of stack in RAM. This configuration can be applied to FSBL but must changed for other execution context. For that you must refer to the corresponding linker file. 

With these settings you should be able to debug, suspend and restart the code (note the first breakpoint at SCB_EnableICache(); take 1.seconde after pressing reset/restart icon.

Let me know if it helps?
Best regards,

Romain,

[exarian]

Thank you @RomainR. for your help,

I made a new workspace then imported the GPIO project by clicking on the file as suggested.

Debugging the first time ran into the LPTIM4 issue.

I added the Reset Configuration commands, then Reset using the button in the IDE.

The LPTIM4 issue went away and the While (1) could be entered.

The LED 1 turns On, however the code seems to get stuck on the HAL_Delay function.

There appears to be a stack corruption that occurs when stepping into the HAL_Delay()

The Delay argument jumps from 100 to 0x34180771, which is closer to the PC value.

In summary, I am glad that the LPTIM4 interrupt is not stalling the processor after the Reset, at least the LED can turn On! 

[RomainR.]

Hi @exarian 

Without any breakpoint, I do not reproduce your LPTIM4 issue and If you add a breakpoint in the while(1) at HAL_Delay(100); the code should loop to toggle the LED blue and halt again at HAL_Delay ? 

Could you confirm that you're using STM32CubeIDE 1.17.0 and STM32Cube_FW_N6_V1.0.0 ?

Share also the board part number and revision, something like MB1940-N657X0Q-C01.

Best regards,

Romain

 

[exarian]

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.

[RomainR.]

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,