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.

[MM..1]

Seems your ioc config HSE , but nucleo dont have it.

[AScha.3]

Yes, i seen this also, but on nucleo board 8MHz clk from st-link going to osc-in pin, so it should not matter setting cpu to HSE crystal or HSE bypass.

+

@rrooyen  , more easy to try : if you attach the .ioc file.

+

Do a simple test : in IDE File menu -> new -> STM32project from existing ioc ...

give mod name , like xxx-test , and let it generate new project with this .ioc ; generate code , 

and only toggle LED in main, to see it running. Then try debug ....and you see: is the problem in ioc or not.

[rrooyen]

Thank you and I have attached the .ioc for further analysis.

As was suggested, I tried creating a new STM32 project from the attached .ioc and interestingly it does not exhibit the debugger "Target not responding, retrying..." behavior! In both cases (existing STM32 project vs. project created from the same .ioc) I start the debugger and let it stop as configured on the first line of code in main, so HAL_Init(), SystemClock_Config(), peripheral initialization, and application code are never executed. The existing project exhibits the "Target not responding, retrying..." console message within ~10 seconds, whereas the project created from the same .ioc never exhibits the "Target not responding, retrying..." console message after letting it sit idle for quite some time.

[rrooyen]

Correction: The previous reply stated that the "Target is not responding, retrying..." did not occur in the project derived from the .ioc file, however further testing has shown that it does appear in the derived project as well.