ST Link Utility cannot detect target

[Nicolas Hell]

Posted on May 04, 2018 at 17:04

Hi everybody,

I'm currently struggling with flashing a binary file to a custom board including Murata LoRa module (type ABZ) which includes a STM32L0.

Indeed, I have a ST Link, I connect it to the board using SWD with this configurations (ST Link on the left):

   - Pin 4 -> GND

   - Pin 7 -> DIO

   - Pin 9 -> CLK

   - Pin 15 -> nRST

The board is externally powered on.

However, when I try to flash the binary file to the MCU, I have several issues. The first one is that I have the message 'Old ST Link firmware/St Link already used' under Target>Settings in ST Link Utility, when I disconnect the ST Link and reconnect it I don't have this message anymore but I have 'Detection fail' in the Target information section and if I try to change something, the Old ST Link... message comes back.

I tried to look at the logs and I found some weird behaviour (especially on voltage detected) and there's apparently also something to do with Read Out Protection.

Anyway, I search for a solution but did not found one that solve my problem so that is why I ask here if someone can help me.

I join some screenshots of ST Link Utility and the corresponding log traces.

If someone can help me, I would much appreciate it

[Tesla DeLorean]

Posted on May 04, 2018 at 17:11

For the stand-alone ST-LINK you need to provide VTarget to power the buffers in the pod.

You can't connect to a device that is not powered, or not functional, the scan chains don't work in these situations.

You must use the right pins, and the software on the device should not reconfigure the GPIO pins used by the debugger, or power down the device.

The most effective signs-of-life method to confirm the part is viable is to pull BOOT0 HIGH so it goes into the ROM System Loader, and from the serial port (nominally USART1 PA9/PA10) send an 0x7F byte at 9600 8E1 and check for the 0x79 response.

[Nicolas Hell]

Posted on May 04, 2018 at 17:45

Hi Clive One,

Thank you for your answer, for the powering of the board it is done, the board is plugged via USB to a computer so normally, I don't need to connect ST Link's VAPP.

I had found the solution consisting in pulling BOOT0 high, I just wanted to see if another solution was viable because in order to pull BOOT0 high on the board, I need to remove a welding on a resistor so always kinda risky.

I think I will try this solution but I thought that the option 'Connect under reset' would do the job and would allow me to erase the chip and load my program.

So where do you think the problem comes from? Is this related with the connection between ST Link or the board or more like something related to the board itself (like GPIO problem maybe) ?

[Tesla DeLorean]

Posted on May 04, 2018 at 17:58

The external stand-alone ST-LINK (not counterfeit or clone) should need power for it's target side drivers, it's not about powering the target, it's about driving the signals. The tools should report the voltage observed.

Don't really know, not party to your designs or procedures. The LoRa firmware examples where 'Low Power' has been enabled tend to turn off parts of the device you need to be working.

...

    DISABLE_IRQ( );

    /* if an interupt has occured after __disable_irq, it is kept pending

     * and cortex will not enter low power anyway  */

    if (State == LOWPOWER)

    {

♯ ifndef LOW_POWER_DISABLE

      LowPower_Handler( ); // GAME OVER

♯ endif

    }

    ENABLE_IRQ( );

When the debugger connects it has to let the part run as it tries to wrestle it into a HALTed state. If the code turns the chip off before the debugger can stop it you lose connectivity.

[Reema O]

Posted on May 04, 2018 at 22:40

I had the same issue couple of months back. Try this setting for ST- utility and see if it works.

Also, measure your voltage across Vcap1  and Vcap2.It should be 1.26V. If Vcap1/Vcap2 is <1.26, then your ST-link is unable to detect your target.