Failed to get status, Target is not responding

HiSt · ‎2025-09-30

Hello together,

like many others here, I have the problem that after a short time, the debugger closes with the error message “Failed to get status,..”.

The board is the nucleo-F767ZI.

It has already been mentioned in the forum that it could be due to the USB cable. But the
same cable works with an nucleo-H755ZI-Q fine.

It was also written that it could be due to the settings or by the code self.

Therefore i did a test and sets a breakpoint direct after start:

When standing at the breakpoint, the debugger still terminates after a few seconds.

Stm32Device, pollAndNotify running...

Warning: Ignoring a '-' sent by client....

GDB session, device event: 4

GDB session, device event: 2

NVIC_DFSR_REG = 0x0000000B

Stm32Device, getHaltReason, code: 4

GDB session, device event: 1

ST-LINK device status: Failed to get status, Target not responding, retrying... 3

Target is not responding, retrying...

ST-LINK device status: Failed to get status, Target not responding, retrying... 19

Target is not responding, retrying...

ST-LINK device status: Failed to get status, Target not responding, retrying... 19

Target is not responding, retrying...

ST-LINK device status: Failed to get status, Target not responding, retrying... 19

When I stop with the red button and try to start again, i got:

Then i could load again.

As long as the debugger is stopped on line 64 “ bl SystemInit,” no code is running and the settings have not yet been made.

What could be the cause then?

Thank you and best regards,

HiST

HiSt · ‎2025-10-01

addendum:

Using the oscilloscope, I was able to measure that at the moment the debugger exits, the NRST signal from the debug MCU on the board is shortly pulled down.

So, the problem was caused by the debug mcu (U2, STM32F103CBT6) on the nucleo board.

I have no idea what triggers it. I have updated bevor the debug mcu with ST-LinkUpgrade to the actual version.

No i tried to use a external ST-LINK / V2 debug probe and this
works without problems.

Best regards,

HiST

EXUE.2 · ‎2025-10-26

generally, it maybe caused by overload protection of board, did you check the Power and COM leds status? if the Power led change to red, it indicate overload.

HiSt · ‎2025-10-29

Hello EXUE.2,

thank you for your reply.

I'm currently working on another task, but as soon as I'm back working with STM32F767, I'll check this out. I seem to recall that the power LED remaines in green-state.

Normally, however, a notebook should be able to provide enough power for the Nucleoboard, provided that, as in my case, no large consumers are connected to the board.

Best regards,

HiST

Andrew Neil · ‎2025-10-29

@HiSt wrote:
Normally, however, a notebook should be able to provide enough power for the Nucleoboard,

Not necessarily; eg, see this solution.

See Also: How to solve connection errors when connecting and programming the STM32 target board.

And: How to solve debugger connection issues.

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.