stlink_usb.c:773 stlink_usb_init_mode(): target voltage may be too low for reliable debugging

[Valerio1]

Posted on April 29, 2017 at 01:54

I made a board with an STM32F405RGT6V, I follow the 'getting started design guide', the datasheet and the Reference Manual plus other documentations for ADC accuracy and so on.

So now I have my board with VDDA paired to VDD and VSSA to the analog GND that for these tests are coupled with the digital GND.

The SWD connector is:

1. VDD
2. SWCLK
3. GND
4. SDIO
5. NRST
6. SWO

and simple code like GPIO toggle works well with correct rises and falls on the SWDIO and NRST pin during programming through a broken Nucleo Board as a STLINKV2-1.

Trouble begins with the enabling of NVIC or other peripherals even if the code comes from the STexample projects. It simply does nothing and stuck at the reset values.

The logical successive step is to take a look at the debugger but SystemWorkbench on Eclipse on Linux tells me this:

Error in final launch sequence

Failed to execute MI command:-target-select remote localhost:3333

Error message from debugger back end:

localhost:3333: Connection timeout.localhost:3333: Connection timeout.

After some internet scraping, I found that the udev rules didn't comply with openocd requests, but also that my openocd installation in SystemWorkbench miss the 'shared/_and_sub' folder and files with wich I could patch my udev rules. To work around this lack I paste an 99-openocd.rules like this:

♯ Copy this file to /etc/udev/rules.d/

ACTION!='add|change', GOTO='openocd_rules_end'

SUBSYSTEM!='usb|tty|hidraw', GOTO='openocd_rules_end'

♯ Please keep this list sorted by VID:PID

♯ opendous and estick

ATTRS{idVendor}=='03eb', ATTRS{idProduct}=='204f', MODE='664', GROUP='plugdev'

♯ Original FT232/FT245 VID:PID

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='6001', MODE='664', GROUP='plugdev'

♯ Original FT2232 VID:PID

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='6010', MODE='664', GROUP='plugdev'

♯ Original FT4232 VID:PID

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='6011', MODE='664', GROUP='plugdev'

Original FT232H VID:PID

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='6014', MODE='664', GROUP='plugdev'

♯ DISTORTEC JTAG-lock-pick Tiny 2

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='8220', MODE='664', GROUP='plugdev'

♯ TUMPA, TUMPA Lite

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='8a98', MODE='664', GROUP='plugdev'

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='8a99', MODE='664', GROUP='plugdev'

♯ XDS100v2

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='a6d0', MODE='664', GROUP='plugdev'

♯ Xverve Signalyzer Tool (DT-USB-ST), Signalyzer LITE (DT-USB-SLITE)

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='bca0', MODE='664', GROUP='plugdev'

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='bca1', MODE='664', GROUP='plugdev'

♯ TI/Luminary Stellaris Evaluation Board FTDI (several)

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='bcd9', MODE='664', GROUP='plugdev'

♯ TI/Luminary Stellaris In-Circuit Debug Interface FTDI (ICDI) Board

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='bcda', MODE='664', GROUP='plugdev'

♯ egnite Turtelizer 2

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='bdc8', MODE='664', GROUP='plugdev'

♯ Section5 ICEbear

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='c140', MODE='664', GROUP='plugdev'

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='c141', MODE='664', GROUP='plugdev'

♯ Amontec JTAGkey and JTAGkey-tiny

ATTRS{idVendor}=='0403', ATTRS{idProduct}=='cff8', MODE='664', GROUP='plugdev'

♯ TI ICDI

ATTRS{idVendor}=='0451', ATTRS{idProduct}=='c32a', MODE='664', GROUP='plugdev'

♯ STLink v1

ATTRS{idVendor}=='0483', ATTRS{idProduct}=='3744', MODE='664', GROUP='plugdev'

♯ STLink v2

ATTRS{idVendor}=='0483', ATTRS{idProduct}=='3748', MODE='664', GROUP='plugdev'

♯ STLink v2-1

ATTRS{idVendor}=='0483', ATTRS{idProduct}=='374b', MODE='664', GROUP='plugdev'

♯ Hilscher NXHX Boards

ATTRS{idVendor}=='0640', ATTRS{idProduct}=='0028', MODE='664', GROUP='plugdev'

♯ Hitex STR9-comStick

ATTRS{idVendor}=='0640', ATTRS{idProduct}=='002c', MODE='664', GROUP='plugdev'

♯ Hitex STM32-PerformanceStick

ATTRS{idVendor}=='0640', ATTRS{idProduct}=='002d', MODE='664', GROUP='plugdev'

♯ Amontec JTAGkey-HiSpeed

ATTRS{idVendor}=='0fbb', ATTRS{idProduct}=='1000', MODE='664', GROUP='plugdev'

♯ IAR J-Link USB

ATTRS{idVendor}=='1366', ATTRS{idProduct}=='0101', MODE='664', GROUP='plugdev'

ATTRS{idVendor}=='1366', ATTRS{idProduct}=='0102', MODE='664', GROUP='plugdev'

ATTRS{idVendor}=='1366', ATTRS{idProduct}=='0103', MODE='664', GROUP='plugdev'

ATTRS{idVendor}=='1366', ATTRS{idProduct}=='0104', MODE='664', GROUP='plugdev'

♯ J-Link-OB (onboard)

ATTRS{idVendor}=='1366', ATTRS{idProduct}=='0105', MODE='664', GROUP='plugdev'

♯ Raisonance RLink

ATTRS{idVendor}=='138e', ATTRS{idProduct}=='9000', MODE='664', GROUP='plugdev'

♯ Debug Board for Neo1973

ATTRS{idVendor}=='1457', ATTRS{idProduct}=='5118', MODE='664', GROUP='plugdev'

♯ Olimex ARM-USB-OCD

ATTRS{idVendor}=='15ba', ATTRS{idProduct}=='0003', MODE='664', GROUP='plugdev'

♯ Olimex ARM-USB-OCD-TINY

ATTRS{idVendor}=='15ba', ATTRS{idProduct}=='0004', MODE='664', GROUP='plugdev'

♯ Olimex ARM-JTAG-EW

ATTRS{idVendor}=='15ba', ATTRS{idProduct}=='001e', MODE='664', GROUP='plugdev'

♯ Olimex ARM-USB-OCD-TINY-H

ATTRS{idVendor}=='15ba', ATTRS{idProduct}=='002a', MODE='664', GROUP='plugdev'

♯ Olimex ARM-USB-OCD-H

ATTRS{idVendor}=='15ba', ATTRS{idProduct}=='002b', MODE='664', GROUP='plugdev'

♯ USBprog with OpenOCD firmware

ATTRS{idVendor}=='1781', ATTRS{idProduct}=='0c63', MODE='664', GROUP='plugdev'

♯ TI/Luminary Stellaris In-Circuit Debug Interface (ICDI) Board

ATTRS{idVendor}=='1cbe', ATTRS{idProduct}=='00fd', MODE='664', GROUP='plugdev'

♯ Marvell Sheevaplug

ATTRS{idVendor}=='9e88', ATTRS{idProduct}=='9e8f', MODE='664', GROUP='plugdev'

♯ CMSIS-DAP compatible adapters

ATTRS{product}=='*CMSIS-DAP*', MODE='664', GROUP='plugdev'

LABEL='openocd_rules_end'

SystemWorkbench doesn't be moved from localhost:3333: timeout

and now my path conducted me here to ask how could is it possible that openocd from cli tells me that:

Info : 253 25 stlink_usb.c:555 stlink_usb_check_voltage(): Target voltage: 0.003173

Error: 254 25 stlink_usb.c:773 stlink_usb_init_mode(): target voltage may be too low for reliable debugging

I rechecked VDD and VDDA from pins, not from trace, and all seems to be ok.

At this link:

http://www.openstm32.org/forumthread705

the user Bardi said:

I was using 3pin SWO connection and the problem was lack of MCU power on STLINKV2. Connecting pin1 to pin19 of 20 pin JTAG fixed it.

Can you help me to solve this puzzle?

thank you,

Valerio

#openocd-stlink-linux #stm32f4-debug-systemworkbench

[Tesla DeLorean]

Posted on April 29, 2017 at 02:58

Perhaps a schematic, and wiring diagram from your header to the 20-pin JTAG header of the ST-LINK V2?

[Valerio1]

Posted on April 29, 2017 at 10:49

Hi Clive, thanks for the quick reply.

My STLINKV2-1 is a Nucleo board without the jumpers CN2 and with out the nucleo board attached, I broken the programmer from the board, also I desoldered the 0 Ohm resistors: NRST, RX, TX, SWO                                                                                                                    

Protocol is SWD not JTAG

[Tesla DeLorean]

Posted on April 29, 2017 at 14:21

In that case I would disconnect the VDD, and just use a common GND.

I'm not familiar with the design of your custom board, provide a schematic.

Check the components and voltage on the VCAP pins of the STM32F4.

Check the state of the NRST pin, voltage, or High/Low state.

[Valerio1]

155793CGIL4

[Tesla DeLorean]

Posted on April 30, 2017 at 17:27

>>Do you mean to disconnect the VDD pin from the SWD connector?

If both boards have their own supply there is no requirement to bond them. The common ground will suffice.

[Valerio1]

Posted on April 30, 2017 at 18:54

This is an interesting info, without the VDD connection all have the same behaviour, only GPIO code run, enabling other peripherals break the execution and stuck at reset values.

Openocd find too low voltage

[Tesla DeLorean]

Posted on April 30, 2017 at 19:56

Any chance you can test with the ST-LINK Utilities instead of third-part tools? Not sure the NUCLEO/DISCO implementation measures the target voltage.

Schematic looks reasonable from a quick scan, the 1.25V on both VCAP pins suggests power is ok, and orientation of part is correct.

The pull-up on NRST should have you a lot closer to 3V3

[Valerio1]

Posted on May 01, 2017 at 02:02

Soo, debugger in CoIDE under windows 7 is better configured and it works!

The board works, breakpoints works, NUCLEO works!

Fantastic

If someone could explain this openocd behaviour, finally it is the base of SystemWorkbench and the Voltage measurements in an SWD debugger is quite unexpected

[ihouses ihouses]

​Hello,

I just passed throw the same pain. The same error. At the end the problem is that voltage (+3.3V) is checked in the PA3 of the programmer (U2), but the +3.3V are coming from the part of board that we separate, therefore when you break the board there is not the 3.3V anymore. You need to connect one end of the R23 to +3v3_st_link and.... magic! works as expected!