2017-04-28 04:54 PM
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:
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:3333Error 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 debuggingI 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-systemworkbench2017-04-28 05:58 PM
Perhaps a schematic, and wiring diagram from your header to the 20-pin JTAG header of the ST-LINK V2?
2017-04-29 03:49 AM
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
2017-04-29 07:21 AM
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.
2017-04-30 10:18 AM
2017-04-30 10:27 AM
>>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.
2017-04-30 11:54 AM
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
2017-04-30 12:56 PM
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
2017-04-30 05:02 PM
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
2019-01-22 06:18 AM
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!