Encountering "Target is not responding, retrying..." a few seconds after starting the GDB debugger

[rrooyen]

I tried an uninstall and reinstall of STM32CubeIDE V1.14 (this version is a project requirement), but there has been no change in the behavior. That target board is a NUCLEO-F413ZH. I have never seen this behavior before on a variety of other NUCLEO boards using STM32CubeIDE V1.8.

Console:

STMicroelectronics ST-LINK GDB server. Version 7.5.0
Copyright (c) 2023, 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.15.0
-------------------------------------------------------------------

 

Log output file: C:\Users\rob\AppData\Local\Temp\STM32CubeProgrammer_a23412.log
ST-LINK SN : 066EFF363445503043033620
ST-LINK FW : V2J43M28
Board : NUCLEO-F413ZH
Voltage : 3.26V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x463
Revision ID : Rev A
Device name : STM32F413/F423
Flash size : 1.5 MBytes
Device type : MCU
Device CPU : Cortex-M4
BL Version : 0x90

 

Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a23412.srec
File : ST-LINK_GDB_server_a23412.srec
Size : 175.92 KB
Address : 0x08000000

Erasing memory corresponding to segment 0:
Erasing internal memory sector 0
Erasing memory corresponding to segment 1:
Erasing internal memory sectors [4 5]
Download in Progress:

File download complete
Time elapsed during download operation: 00:00:03.549

 

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.

[STTwo-32]

Hello @rrooyen 

I suggest you to take a look at this article. It should be helpful. 

Best Regards.

STTwo-32 

[MM..1]

Perfectly normal if you in code use low power mode. Wake it...

[rrooyen]

Hello and thank you very much for your prompt reply!

I went through all of the steps in the article, however it had no effect on the debugger retry behavior. I also do not have the system in low power mode.

I recall a recommended update of the STLINK/V2 firmware, but I'm not sure if this is related. Would it make sense to roll back the version of STLINK/V2 firmware and if so where can I find a known good older version to try?

[AScha.3]

Just - what i would do:

Make new project (for test) with settings (maybe from Cube -> for your board) for clock-tree and debug,

and only toggle LED in main, to see it running.

Try to load and debug this - then you know, is something wrong with st-link or is it your program.

(Maybe using the debug pins for other I/O, then debug "suddenly" has no more connection.)

IF this gets no debug connection, THEN try an older version of CubeProgrammer and test with test-program.

[rrooyen]

Creating a generic project based on the NUCLEO-F413ZH board and adding a simple blinky in the default while loop worked in terms of debugging, e.g., no issues. This is a very good baseline indeed and I tried to compare all of the settings including the clock configuration between the two projects, but it is not obvious what would cause the debugger to fail.

With regard to he debug pins, the project specific .ioc does not reallocate or use the TCK (PA14) and TMS (PA13) pins in any way.

I have attached a diff of the two .ioc files in the hope that they may offer some type of clue to the trained eye. Thank you in advance for reviewing the diff and perhaps suggesting next steps.

[happyojj]

OK OK OK!

I solved this problem!
Shorten the usb length of stlink.
And try connecting directly without using usb hub!