Sysprogs forums › Forums › VisualGDB › STM32 connection issues
Tagged: connection, Debug, stm32
- This topic has 11 replies, 2 voices, and was last updated 5 years, 6 months ago by support.
-
AuthorPosts
-
February 25, 2019 at 06:11 #23964surahmanParticipant
Hi,
I’m running into issues connecting to my STM32F412ZG board through ST-Link v2.1 where ST-Link Utility is able to connect to the board just fine but VGDB is giving me connection errors below:
AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c "gdb_port 38386" -c "telnet_port 38387" -f interface/stlink-v2-1.cfg -c "transport select hla_swd" -f target/stm32f4x.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"
Open On-Chip Debugger 0.10.0 (2018-12-12) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/
stlink-v2-1.cfg is deprecated, please switch to interface/
stlink.cfg
hla_swd
Info :The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
Info :clock speed 2000 kHz
Error: open failed
in procedure 'init'
in procedure 'ocd_bouncer'
Command Line:
-f interface/stlink-v2-1.cfg -c "transport select hla_swd" -f target/stm32f4x.cfg -c init -c "reset init"
Startup GDB Commands:
set remotetimeout 60
target remote :$$SYS:GDB_PORT$$
mon halt
mon reset init
load
The tutorial I am using to set up the project is here: https://visualgdb.com/tutorials/arm/stm32/
- This topic was modified 5 years, 8 months ago by surahman.
February 25, 2019 at 19:24 #23980supportKeymasterHi,
This looks like an incompatibility between OpenOCD and your USB driver. Please try replacing the OpenOCD executable in %LOCALAPPDATA% with this one: http://sysprogs.com/files/tmp/openocd.exe
If it doesn’t work, please share an updated OpenOCD output.
February 26, 2019 at 03:43 #23985surahmanParticipantHi,
I updated the OpenOCD executable and I’m now getting this error:
AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c "gdb_port 41975" -c "telnet_port 41976" -f interface/stlink-v2-1.cfg -c "transport select hla_swd" -f target/stm32f4x.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" Open On-Chip Debugger 0.10.0 (2019-02-25) [https://github.com/sysprogs/openocd] Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg hla_swd Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD adapter speed: 2000 kHz adapter_nsrst_delay: 100 none separate Info : clock speed 2000 kHz Error: open failed: jtag_libusb_open() returned error -4
Thanks,
February 26, 2019 at 06:40 #23988supportKeymasterThanks for the update. We have updated the temporary build to include more logging. Please try this one (same link): http://sysprogs.com/files/tmp/openocd.exe
February 26, 2019 at 06:47 #23989surahmanParticipantNo worries, here is the updated run:
AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c "gdb_port 43497" -c "telnet_port 43498" -f interface/stlink-v2-1.cfg -c "transport select hla_swd" -f target/stm32f4x.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" Open On-Chip Debugger 0.10.0 (2019-02-25) [https://github.com/sysprogs/openocd] Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg hla_swd Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD adapter speed: 2000 kHz adapter_nsrst_delay: 100 none separate Info : clock speed 2000 kHz Info : libusb reported 7 devices Info : USB descriptor mismatch for device #1 (1b21/1242) Info : USB descriptor mismatch for device #2 (8086/a12f) Info : USB descriptor mismatch for device #3 (0a12/1004) Info : USB descriptor mismatch for device #4 (046d/c52b) Info : USB descriptor mismatch for device #5 (05ac/12a8) Info : USB descriptor mismatch for device #6 (13fd/1340) Info : STLINK V2J33M25 (API v2) VID:PID 0483:374B Info : Target voltage: 3.259843 Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints Info : Listening on port 43497 for gdb connections Info : Unable to match requested speed 2000 kHz, using 1800 kHz Info : Unable to match requested speed 2000 kHz, using 1800 kHz adapter speed: 1800 kHz target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0805cb6c msp: 0x20002d68 Info : Unable to match requested speed 8000 kHz, using 4000 kHz Info : Unable to match requested speed 8000 kHz, using 4000 kHz adapter speed: 4000 kHz VisualGDB_OpenOCD_Ready Info : Listening on port 6666 for tcl connections Info : Listening on port 43498 for telnet connections Info : accepting 'gdb' connection on tcp/43497 Info : device id = 0x30006441 Info : flash size = 1024kbytes Info : dropped 'gdb' connection (error -400) shutdown command invoked
At the end of the test, the result indicated success but the 2nd last line in the output seems to indicate failure.
February 26, 2019 at 07:18 #23992supportKeymasterThe second last line can be ignored. It just means that VisualGDB closed the connection without issuing the proper shutdown command and it shouldn’t matter for connection tests.
This time it actually looked like a successful test, so you should be able to debug your project now, although all we changed in that build was adding extra logging, so the problem might reoccur later.
April 19, 2019 at 03:48 #24713surahmanParticipantThe issue has resurfaced now that I’ve switched to VS2019 with VGDB5.4-R5.
AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c "gdb_port 30455" -c "telnet_port 30456" -f interface/stlink-v2-1.cfg -f target/stm32f4x.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" Open On-Chip Debugger 0.10.0 (2019-02-10) [https://github.com/sysprogs/openocd] Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'. Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD adapter speed: 2000 kHz adapter_nsrst_delay: 100 none separate Info : clock speed 2000 kHz Error: open failed
If I use the old executable provided above I get the following error:
AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c "gdb_port 30440" -c "telnet_port 30441" -f interface/stlink-v2-1.cfg -f target/stm32f4x.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" Open On-Chip Debugger 0.10.0 (2019-02-25) [https://github.com/sysprogs/openocd] Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'. Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD adapter speed: 2000 kHz adapter_nsrst_delay: 100 none separate Info : clock speed 2000 kHz Info : libusb reported 6 devices Info : USB descriptor mismatch for device #0 (046d/c318) Info : USB descriptor mismatch for device #1 (1b21/1242) Info : USB descriptor mismatch for device #2 (8086/a12f) Info : USB descriptor mismatch for device #3 (046d/c52b) Info : USB descriptor mismatch for device #4 (05ac/12a8) Info : USB descriptor mismatch for device #5 (13fd/1340) Error: open failed: jtag_libusb_open() returned error -4
- This reply was modified 5 years, 6 months ago by surahman.
April 19, 2019 at 03:52 #24715supportKeymasterHi,
It looks like the OpenOCD is not able to find the ST-Link instance (no device with a VID of 0x0483 is listed). Please double-check that you can see the ST-Link in Device Manager and that it’s not hijacked by VMWare or USB-over-Network software that would hide it from the regular programs like OpenOCD.
April 19, 2019 at 03:56 #24716surahmanParticipantI can connect to the device using the STM32 ST-LINK Utility just fine, so I think that OpenOCD should be able to connect to the device. I can also see ST-Link Debug in the Device Manager under Universal Serial Bus devices.
- This reply was modified 5 years, 6 months ago by surahman.
April 19, 2019 at 04:54 #24718supportKeymasterThanks for the update. Most likely this is caused by an incompatibility between the libusb library used by OpenOCD and a specific USB host controller, or a specific driver version. The best workaround would be to try using the Segger J-Link firmware for ST-Link. J-Link uses its own driver and its own gdb stub, so it should not trigger any bugs that are specific to OpenOCD.
April 19, 2019 at 06:13 #24719surahmanParticipantIf I set Debug using under debug methods to SEGGER J-Link with USB-Auto I get the following:
SEGGER\JLink_V644g\JLinkGDBServerCL.exe -select USB -device STM32F412ZG -speed auto -if SWD -port 2028 SEGGER J-Link GDB Server V6.44g Command Line Version JLinkARM.dll V6.44g (DLL compiled Apr 18 2019 17:12:10) Command line: -select USB -device STM32F412ZG -speed auto -if SWD -port 2028 -----GDB Server start settings----- GDBInit file: none GDB Server Listening port: 2028 SWO raw output listening port: 2332 Terminal I/O port: 2333 Accept remote connection: localhost only Generate logfile: off Verify download: off Init regs on start: off Silent mode: off Single run mode: off Target connection timeout: 0 ms ------J-Link related settings------ J-Link Host interface: USB J-Link script: none J-Link settings file: none ------Target related settings------ Target device: STM32F412ZG Target interface: SWD Target interface speed: auto Target endian: little Connecting to J-Link... Connecting to J-Link failed. Connected correctly? GDBServer will be closed... Shutting down... Could not connect to J-Link. Please check power, connection and settings.
If I manually supply the USB serial number, which I’ve double checked is correct, I get the following:
SEGGER\JLink_V644g\JLinkGDBServerCL.exe -select USB=066EFF333036434B43015523 -device STM32F412ZG -speed auto -if SWD -port 2021 SEGGER J-Link GDB Server V6.44g Command Line Version JLinkARM.dll V6.44g (DLL compiled Apr 18 2019 17:12:10) Command line: -select USB=066EFF333036434B43015523 -device STM32F412ZG -speed auto -if SWD -port 2021 -----GDB Server start settings----- GDBInit file: none GDB Server Listening port: 2021 SWO raw output listening port: 2332 Terminal I/O port: 2333 Accept remote connection: localhost only Generate logfile: off Verify download: off Init regs on start: off Silent mode: off Single run mode: off Target connection timeout: 0 ms ------J-Link related settings------ J-Link Host interface: USB J-Link script: none J-Link settings file: none ------Target related settings------ Target device: STM32F412ZG Target interface: SWD Target interface speed: auto Target endian: little Could not select J-Link with specified S/N (66). GDBServer will be closed... Shutting down... Could not connect to J-Link. Please check power, connection and settings.
If I use the USB Devices I only see ST-Link v2.1, I have installed SEGGER J-Link as well as installed the
Digitally signed USB driver for ST-Link/V2, ST-Link/V2-1 and STLINK-V3 on Windows7, Windows8 and Windows10, 32 and 64 bits. [stsw-link009]
The error persists. It works fine out of the box on my laptop.
- This reply was modified 5 years, 6 months ago by surahman.
April 19, 2019 at 17:33 #24724supportKeymasterThanks for the update. If both OpenOCD and J-Link don’t recognize a specific device on a specific machine, it’s likely caused by some low-level USB driver issues. We understand that the ST-Link tool works with it, however it might be using a slightly different underlying API. Generally, using a different machine, or connecting the device to a different USB port/host controller should work around the issue.
-
AuthorPosts
- You must be logged in to reply to this topic.