Intermittent but frequent "Target is not responding, retrying..." with STM32CubeIDE debugger

[CKugl.1]

This problem is driving me crazy. I'm running STM32CubeIDE, Version: 1.9.0, Build: 12015_20220302_0855 (UTC) connected to a NUCLEO-L4A6ZG. Very frequently, my debug sessions go like this:

 
STMicroelectronics ST-LINK GDB server. Version 6.1.0
Copyright (c) 2022, STMicroelectronics. All rights reserved.
 
Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 1
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled
        InitWhile                  : Enabled
 
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.10.0                  
      -------------------------------------------------------------------
 
 
 
Log output file:   c:\users\carlk\appdata\local\temp\stm32cubeprogrammer_a23636.log
ST-LINK SN  : 0675FF535155878281053933
ST-LINK FW  : V2J39M27
Board       : NUCLEO-L4A6ZG
Voltage     : 3.22V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x461
Revision ID : Rev 2.0
Device name : STM32L496xx/STM32L4A6xx
Flash size  : 1 MBytes
Device type : MCU
Device CPU  : Cortex-M4
BL Version  : --
Debug in Low Power mode enabled
 
 
 
Memory Programming ...
Opening and parsing file: st-link_gdb_server_a23636.srec
  File          : st-link_gdb_server_a23636.srec
  Size          : 110.57 KB 
  Address       : 0x08000000 
 
 
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 55]
Download in Progress:
 
 
File download complete
Time elapsed during download operation: 00:00:03.779
 
 
 
Verifying ...
 
 
 
 
Download verified successfully 
 
 
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...
Shutting down...
Exit.

Some things I've tried:

1. Really short USB cable
2. Got myself a gold plated USB cable with a ferrite choke
3. DeoxIT D100 contact cleaner spray on USB connections
4. Reduced SWD frequency to 1000
5. 4 or 5 different USB connections to the PC
6. Checking for updated Windows 11 USB drivers
7. Swapping the NUCLEO-L4A6ZG for a NUCLEO-L496ZG

Nothing has made the slightest difference, as far as I can tell.

I'm running the Virtual COM port interface on USB for LPUART communication. Could that make any difference? I tried reducing the frequency on that from 115200 to 57600, but that didn't help, either.

I have some external gear connected to the Nucleo, so I am feeding 10 V at 120 mA into VIN (JP6 on VIN), but I had this problem before I had that hooked up.

What else can I try?

[CKugl.1]

I don't know if it could be related, but sometimes around the time I'm being plagued with "Target is not responding, retrying...", STM32CubeIDE itself stops responding:

Stack:

ntdll!NtWaitForSingleObject + 0x14   
KERNELBASE!WaitForSingleObjectEx + 0x8e   
serial!Java_org_eclipse_cdt_serial_SerialPort_write1 + 0x180   
0x14e0bf1f2d7   
0x14e030a8b48   
0xd9772cf30   
0x1454   
0xd9772cf18   
0x14e00000000   
0x14e00000001   
0x14e030a9988   
0xd8   
0xd9772da50   
ntdll!RtlpAllocateHeapInternal + 0x12a   

[CKugl.1]

I think I found my problem: a Zigbee-type wireless hub was nearby. After moving that, my problems went away! (At least so far. Never know with intermittent problems!)

[Sara BEN HADJ YAHYA]

Hello @CKugl.1​ ,

Did you by any chance used the debugger pins for other purpose ?,if this is your case, please check this article How to solve debugger connection issues?.

I hope this helps ��

Sara.

[CKugl.1 · Accepted solution]

I don't think so. I have:

Pin Nb PINs FUNCTIONs LABELs

SYS Trace Asynchronous Sw SYS_JTMS-SWDIO PA13 (JTMS/SWDIO)

SYS Trace Asynchronous Sw SYS_JTCK-SWCLK PA14 (JTCK/SWCLK)

SYS Trace Asynchronous Sw SYS_JTDO-SWO PB3 (JTDO/TRACESWO)

The problem went away for a long time, and then came back one day. I have a daughter board plugged into the Zio connectors, and my new theory is that the cheap breakaway header strips that I got from Amazon are making a poor connection somewhere in the expansion connectors. The daughter board is not even involved in the path from the PC->USB->ST-Link->STM32; except that when I have it configured for external power on VIN, I am feeding that in through a pin on the daughter board that is connected to a pin that goes into the expansion socket. (In that case, I move JP6 from STLK to VIN, so the only power to the non-ST-Link part of the Nucleo is coming through VIN instead of USB.) What I have done for now is to carefully clean all the pins with isopropyl, and then I sprayed some DeoxIT D100 "more than a contact cleaner" into the sockets. If I have the problem again, the first thing I will try is reseating the board. The problem went away when I reseated the board, and things have been running well on external power for weeks now. I will stick to gold-plated Berg strips from now on.

[CKugl.1]

The problem kept coming back, intermittently. I finally resorted to sawing off the NUCLEO's integrated ST-LINK/V2-1 debugger/programmer, and connecting a STLINK-V3MINI. I have also used the STLINK-V3SET. I have never had the problem again, and it has been months now.