Skip to main content
B
bsgursta
Associate II
May 5, 2026
Solved

STM32N6 Nucleo Target Not Responding After Intial Success

  • May 5, 2026
  • 3 replies
  • 182 views

Hi everybody.

I'm currently trying to use the N6 Nucleo for a personal application but am having trouble starting the debugger after initially successes. I am using the Nx_TCP_Echo_Server example, and after a couple of successful iterations my debugger stopped working entirely.

I am using the VSCode extension. When I start my debug session with ST-Link GDB server it will connect to the debugger, but an error will follow in the terminal as shown ("target not responding"). After disconnecting and re-initializing the debugger I will get the following error ("error in intializing... please check power"). I get the same issues after power-cycling the board. LED 2 (Red) will then remain off until I power cycle the board after the first error.

bsgursta_0-1777955391246.png

bsgursta_1-1777955450403.png

Previous issues led me to believe I re-wrote the SWD lines so I connected BOOT0 to 3.3V and used the CubeProgrammer to perform a chip erase. Specifically for the external memory since to my knowledge the N6 doesn't maintain internal memory. After the chip erase and unplugging the BOOT0 jumper I'm still stuck with the same issue.

If I could be offered some guidance to remedy my problem. I still suspect issues with the SWD but I might be overlooking an architectural aspect with the board that could resolve the issue.

Best answer by bsgursta

I was able to find the issue which was a VSCode extension update. Specifically with the STM32 Debug Core extension. I suggest to roll back that extension as well as the Cmake Support one as I couldn't run a project with Cmake Support updated but Debug Core rolled-back.

Here is a link to a post about the issue which hopefully will be resolved in the future.

Solution 

3 replies

B
bsgurstaAuthor
Associate II
May 5, 2026

Here is the initial error for more visibility.

Nx_TCP_Echo_Server/Core/Src/main.c:100
100 MPU_Config();
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
GdbSession, Lost target connection, Exiting...
Shutting down...
Exit.
cube has exited with code 0

B
bsgurstaAuthor
Associate II
May 5, 2026

I was able to halt the debugger in the reset hander but once I run the code below the target is lost.

mov sp, r0 /* set stack pointer */

Here is the entire snippet:

Reset_Handler:
ldr r0, =_sstack
msr MSPLIM, r0
ldr r0, =_estack
mov sp, r0 /* set stack pointer */
/* Call the clock system initialization function.*/
bl SystemInit

 

B
bsgurstaAuthor
Associate II
May 5, 2026

I was able to resolve the issue with the example by running it in the STMCubeIDE. I still have no idea what could be the issue as I was running the ST-Link GDB server in the IDE, just like VSCode. I never ran into the target lost issue in the IDE so I assume it's a configuration I had messed with somewhere throughout the code.

B
bsgurstaAuthorBest answer
Associate II
May 6, 2026

I was able to find the issue which was a VSCode extension update. Specifically with the STM32 Debug Core extension. I suggest to roll back that extension as well as the Cmake Support one as I couldn't run a project with Cmake Support updated but Debug Core rolled-back.

Here is a link to a post about the issue which hopefully will be resolved in the future.

Solution 

Terms & ConditionsAccessibility statement