chip enters NMI handler with debugger attached

[msilv.11]

I am having issues debugging a STM32H7 series chip (STM32H755).

When I connect using multiarch-gdb and run `mon swdp_scan` it crashes both cores. I am using a BMP debugger. I end up in the NMI handler. I can see via the external LEDs in the code that it is the monitor command which is causing the interrupt.

(gdb) tar ext /dev/ttyACM0
Remote debugging using /dev/ttyACM0
(gdb) monitor swdp_scan
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      STM32H7 M7
 2      STM32H7 M4
(gdb) attach 1
Attaching to program: /CM7/jc_m7_cube.elf, Remote target
NMI_Handler () at /CubeMX/CM7/Core/Src/stm32h7xx_it.c:77
77        while (1)
(gdb) list *$pc
0x80009d4 is in NMI_Handler (CubeMX/CM7/Core/Src/stm32h7xx_it.c:77).
72        /* USER CODE BEGIN NonMaskableInt_IRQn 0 */
73
74        /* USER CODE END NonMaskableInt_IRQn 0 */
75        HAL_RCC_NMI_IRQHandler();
76        /* USER CODE BEGIN NonMaskableInt_IRQn 1 */
77        while (1)
78        {
79        }
80        /* USER CODE END NonMaskableInt_IRQn 1 */
81      }
(gdb) 

If I hard reset the microcontroller using the reset line, and then do the same steps as above, it will execute normally.

Why is this happening?

[Tesla DeLorean]

NMI's apt to be parity errors on RAM, or ECC failures on FLASH (access to unwritten, or partially written flash lines)

[msilv.11]

Thanks for the response. Do you have have any insight into why a GDB enumeration command would cause either those failure conditions?

[waclawek.jan]

Maybe because

> I am using a BMP debugger.

?

Is it known to work with your target?

JW