cancel
Showing results for 
Search instead for 
Did you mean: 

Error in initializing ST-LINK device. Reason: (4) No device found on target -- but STLink-Util flashing works.

SKled.1
Senior II

When I try to debug from CubeIDE, I get this error.

But I can connect with STLink-Util and flash a firmware just fine.

What does this claim there was "no device" on target, mean exactly?

The firmware has worked previously, but there is a bug now in my firmware that makes it hang after doing some expected things I see on the uart output, and I'd like to debug it - but that does not work now.

The firmware does not (explicitly) reconfigure the SWD pins or something like that.

3 REPLIES 3

>>What does this claim there was "no device" on target, mean exactly?

Means it can't communicate with the STM32 on the board, because of issues with the pins, power, or it is generally unresponsive to probing. Could be damaged, issues with power supply, or not wired up correctly.

If NRST pin is connected you can use "connect under reset" to try an wrestle control.

Similarly if BOOT0 is pulled High, it will execute ROM based code rather than errant user code.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
SKled.1
Senior II

What is the difference between the debugging and flashing scenario which could explain that flashing repeatedly works, while debugging continues not to?

Hrm, "connect under reset" is enabled. Guess I'll try another cable/connector to the target.

Edit: Replacing the most likely failing cable did not do anything.

I also see that it does reset when I try to debug - I get the system start message on the UART again, and then I get "No device found on target" again.

I found claims that a difference in the operation voltages between target and the 3V3 of the debugger could cause problems, without further elaboration.

Is that true? The circuit here has 3V3 nominally, though.

SKled.1
Senior II

Ok that's weird.

While I was also trying to revert to an older STLink firmware (see my other recent thread for why) and that did not work,

I changed to one of the front USB connectors on my PC, with a shorter cable, as that was my previous setup (vs. recently a long cable to the back of the PC),

just to be sure - as I have had problems with e.g. USB hubs and STLink before - but that did nothing.

I now explicitly set the lowest SWD frequency in CubeIDE / Debug Config, i.e. 140kHz, where it was on Auto before.

I now get a debugger connection *.

But... this is not restricted to a new board with the MCU I have here, I just had the same problem on an older board that worked with the previous settings (but also front USB port), not just the new PCB I tought may have a problem.

As a sanity check, I in between also successfully tried to debug a devboard of the same MCU series (L073) with its own STLink.

I don't get why my old board, that worked fine, now also had this problem. Both PCB layouts look the same between MCU and the debug connector - so there I'd expect same behavior - but the old used to work with "Auto", and "new" is always fishy at first 😉

The Nucleo devboard does still work on "Auto", it has the "V3J7..." firmware on its STLink.

STLink versions within my STLINk V3 SET that I'm using for the two mentioned custom PCBs also did not seem to matter - I tried V3J4..., V3J7 and V3J8 on them.

 ---

* Well, but as soon as the program on t he MCU prionts the UART message that it's in the Fault Handler, when I then want to stop the debugger, it doesn't work, and I get:

CM3 Failed to print all registers
FAILED to REGISTER Values from the target

Update:

I set the CubeIDE DebugConfiguration to use "1000" (kHz), that seems to work now.