STM32L462 not found - ST-LINK V2 / V3 in STM32CubeIDE

[MI.3]

Hi,

I have STM32CubeIDE 1.7.0 issue whereby I can connect either ST-Link V2 or V3set to our custom board that has STM32L462RET6 MCU. Same with STM32 Cube Programmer - can't connect - target not found. Inside IDE, there's problem launching GDB server.

Please see attached images of the problems.

Whether I connect our board, power it on or disconnect it from ST-Link, it's the same results - either way, it can't find target board.

In Programmer, I noticed, whether Voltage: 0.0 (STLink V3) or Voltage 3.24 (STLink V2) is detected, STILL target can't be found.

How can I fix this issue?

Thanks for your help.

STMicroelectronics ST-LINK GDB server. Version 5.9.1

Copyright (c) 2021, STMicroelectronics. All rights reserved.

Starting server with the following options:

    Persistent Mode      : Disabled

    Logging Level       : 1

    Listen Port Number     : 61117

    Status Refresh Delay    : 15s

    Verbose Mode        : Disabled

    SWD Debug         : Enabled

Target no device found

Error in initializing ST-LINK device.

Reason: No device found on target.

[TDK]

> our custom board

> Voltage: 0.0 (STLink V3)

Would indicate the chip doesn't have power, or that it's not wired up to the debugger.

Most likely scenario is a hardware problem. Check voltage rails, VCAP voltages, verify correct orientation, verify SWD connections make it to the chip.

[Tesla DeLorean]

Not sure it's a software setting, more likely your board design or construction is wrong, and broken.

If not the board, then the wiring to the debug pod. Make sure headers aren't backward, or the pin numbering is consistent with standard connectors.

ST-LINK/V2 (authentic ones) needs/expects VTarget on pin 1 or 2

Check what NRST is doing.

Check currents drawn.

Check supplies especially VDDA, the grounds, VCAP voltages and capacitors.

Other signs-of-life methods are to pull BOOT0 High and use the ROM based System Loader, try to interact with that via the UARTs. See app note AN2606 and those describing the serial protocol.

Suggest sending the 0x7F bit pattern at 9600 8E1, and watching for a response.

The Pin 1 designator confuses some, check that the chip isn't on backward or sideways. VCAP pins are a good probing target.

[MI.3]

Hello,
Thanks for your reply. It was all my fault.
I had the V3 adapter board 180 degrees wrong way assembled to the main STlink board ☹ Someone looked more closely & saw that.
And I unknowingly plugged in the tag connect to the V2 on the STM8 connector because I borrowed it from someone to isolate V3 problem.
He had the interface board on the STM8 location instead on the STM32.
I’m new to this ST MCU, IDE, programmer, debugger so I learned GOOD LESSONS here.
I apologize for the bother to you.
MI

[SpinKernel]

I have the same problem. I've used this before to debug using CubeIDE, but with the latest versions it not longer functions (programming works fine using cube programmer). I CAN however use the STLink/v2 off a nucleo board to program and debug just fine. Voltages are read everything seems fine just I get the same GDB output. Tried reloading the firmware, didn't help.

[Tesla DeLorean]

ST-LINK/GDB integration has been a persistent point of failure.

If the stand-alone ST-LINK/V2 doesn't work, be sure the VTarget voltage is present and connected, as the authentic devices have buffers on the ST-LINK side POWERED by the TARGET. Check reporting of voltage in STM32 Cube Programmer, and that CUBE IDE is using most current ST-LINK DLLs, drivers, etc. Check the startup scripts.

[Terry Greeniaus]

I know you solved your problem, but one thing to be aware of is that if you are using low-power modes or sleep modes and the WFI instruction then the ST-LINK will be unable to attach to your firmware while it is in one of these low-power modes. The ST-LINK debug probes are keyed to only work with ST hardware by having the debug probe check for the existence of the DBGMCU peripheral when it tries to connect to the target MCU. However, in low-power or sleep modes (even just using WFI to stop the CPU clock without putting any other peripherals to sleep) the DBGMCU is inaccessible because the clocks needed to access it are stopped. This prevents the ST-LINK from verifying what type of ST MCU it is talking to and then prevents it from connecting to the target.

The DBGMCU peripheral does have some clock-enable bits that you can set before you go into sleep/low-power/WFI mode that will prevent the desired clocks from being disabled. You can do this without firmware support if you assert nRST, set the bits via the debug probe and then release nRST so that your firmware starts up under their influence. This will do things link change the power profile of your board, so you have to be careful not to have the bits enabled while testing your board's power consumption.

[Mr. AK]

I'm also facing the same issue (I'm using NUCLEO-H745ZI-Q). No target found on Device. When I try to debug from cube-IDE, its saying "Failed to start GDB server". I tried to connecting to the device using cube programmer but it is not able to and shows the following in the log:-

ST-LINK SN : 001F002A3137510E39383538

ST-LINK FW : V3J9M3

Board    : NUCLEO-H745ZI-Q

Voltage   : 3.28V

Error: No STM32 target found!

So the connection to STLINK is happening but it seems STLINK cannot communicate with the STM32H745ZIT6U.

I have noticed the option to make BT0 pin HIGH and use any one of the peripherals (USART1 RX & TX pins) . But I'm not getting a clear idea on it.

Is there any document on step-by-step description on resolving this issue? Please help!

[Tesla DeLorean]

This is a bit off-topic for this thread

>>Is there any document on step-by-step description on resolving this issue? 

The specific issues with H7 dual parts has been gone over repetitively. Perhaps look at the H745 / H747 DISCO board manuals.

If you mess up the LDO/SMPS settings you'll pretty much brick the part for normal operation.

One of the most successful recover techniques is to strap BOOT0 HIGH, and cycle the power multiple times until you can erase the broken user code from the device. The removal of power from H7's is key as they treat a power-on-reset differently to a pin reset.

[Terry Greeniaus]

If you connect while the H7 is held in reset, I would think that would work around any user code screwing up the LDO/SMPS settings. Since you have a NUCLEO board, I think you can just hold down the black "Reset" button and attempt to connect/flash it while you are holding the button down (the ST parts support establishing the SWD connection while the MCU is held in reset). Also, as I mentioned above if you are using any sleep modes then you will find it difficult to connect while the device is in sleep mode, and there again using the Reset button while trying to connect can help.