Sysprogs forums › Forums › VisualGDB › STM32 OpenOCD cannot connect to ST Link V2
- This topic has 5 replies, 3 voices, and was last updated 5 years, 12 months ago by support.
-
AuthorPosts
-
November 29, 2018 at 07:44 #22949canaanavParticipant
My VisualGDB project seems to configure and compile correctly. I’m even able to use the STM32 CubeProgrammer to load and run the generated .bin compiled by VisualGDB.
I get the following error while trying to debug though.
C:\Users\mdric_000\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c "gdb_port 54619" -c "telnet_port 54620" -f interface/stlink-v2.cfg -c "transport select hla_swd" -f C:/Users/mdric_000/AppData/Local/Temp/tmp62F7.tmp -c "debug_level 3" -c "echo VisualGDB_OpenOCD_Ready" Open On-Chip Debugger 0.10.0 (2018-09-03) [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.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 trst_and_srst separate srst_nogate trst_push_pull srst_open_drain connect_assert_srst User : 37 144 command.c:544 command_print(): debug_level: 3 Debug: 38 144 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_echo VisualGDB_OpenOCD_Ready Debug: 39 186 command.c:143 script_debug(): command - echo ocd_echo VisualGDB_OpenOCD_Ready User : 41 203 command.c:780 jim_echo(): VisualGDB_OpenOCD_Ready Info : 42 229 server.c:311 add_service(): Listening on port 6666 for tcl connections Info : 43 237 server.c:311 add_service(): Listening on port 54620 for telnet connections Debug: 44 238 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_init Debug: 45 241 command.c:143 script_debug(): command - init ocd_init Debug: 47 242 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_target init Debug: 48 243 command.c:143 script_debug(): command - ocd_target ocd_target init Debug: 50 244 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_target names Debug: 51 245 command.c:143 script_debug(): command - ocd_target ocd_target names Debug: 52 245 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_stm32f4x.cpu cget -event gdb-flash-erase-start Debug: 53 246 command.c:143 script_debug(): command - ocd_stm32f4x.cpu ocd_stm32f4x.cpu cget -event gdb-flash-erase-start Debug: 54 247 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_stm32f4x.cpu configure -event gdb-flash-erase-start reset init Debug: 55 248 command.c:143 script_debug(): command - ocd_stm32f4x.cpu ocd_stm32f4x.cpu configure -event gdb-flash-erase-start reset init Debug: 56 259 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_stm32f4x.cpu cget -event gdb-flash-write-end Debug: 57 276 command.c:143 script_debug(): command - ocd_stm32f4x.cpu ocd_stm32f4x.cpu cget -event gdb-flash-write-end Debug: 58 277 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_stm32f4x.cpu configure -event gdb-flash-write-end reset halt Debug: 59 280 command.c:143 script_debug(): command - ocd_stm32f4x.cpu ocd_stm32f4x.cpu configure -event gdb-flash-write-end reset halt Debug: 60 280 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_stm32f4x.cpu cget -event gdb-attach Debug: 61 281 command.c:143 script_debug(): command - ocd_stm32f4x.cpu ocd_stm32f4x.cpu cget -event gdb-attach Debug: 62 282 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_stm32f4x.cpu configure -event gdb-attach halt Debug: 63 284 command.c:143 script_debug(): command - ocd_stm32f4x.cpu ocd_stm32f4x.cpu configure -event gdb-attach halt Debug: 64 285 target.c:1374 handle_target_init_command(): Initializing targets... Debug: 65 289 hla_target.c:357 adapter_init_target(): adapter_init_target Debug: 66 291 semihosting_common.c:97 semihosting_common_init(): Debug: 67 293 command.c:364 register_command_handler(): registering 'ocd_target_request'... Debug: 68 294 command.c:364 register_command_handler(): registering 'ocd_trace'... Debug: 69 294 command.c:364 register_command_handler(): registering 'ocd_trace'... Debug: 70 294 command.c:364 register_command_handler(): registering 'ocd_fast_load_image'... Debug: 71 295 command.c:364 register_command_handler(): registering 'ocd_fast_load'... Debug: 72 295 command.c:364 register_command_handler(): registering 'ocd_profile'... Debug: 73 296 command.c:364 register_command_handler(): registering 'ocd_virt2phys'... Debug: 74 296 command.c:364 register_command_handler(): registering 'ocd_reg'... Debug: 75 297 command.c:364 register_command_handler(): registering 'ocd_poll'... Debug: 76 307 command.c:364 register_command_handler(): registering 'ocd_wait_halt'... Debug: 77 309 command.c:364 register_command_handler(): registering 'ocd_halt'... Debug: 78 311 command.c:364 register_command_handler(): registering 'ocd_resume'... Debug: 79 312 command.c:364 register_command_handler(): registering 'ocd_reset'... Debug: 80 312 command.c:364 register_command_handler(): registering 'ocd_soft_reset_halt'... Debug: 81 312 command.c:364 register_command_handler(): registering 'ocd_step'... Debug: 82 313 command.c:364 register_command_handler(): registering 'ocd_mdd'... Debug: 83 314 command.c:364 register_command_handler(): registering 'ocd_mdw'... Debug: 84 316 command.c:364 register_command_handler(): registering 'ocd_mdh'... Debug: 85 316 command.c:364 register_command_handler(): registering 'ocd_mdb'... Debug: 86 318 command.c:364 register_command_handler(): registering 'ocd_mwd'... Debug: 87 319 command.c:364 register_command_handler(): registering 'ocd_mww'... Debug: 88 320 command.c:364 register_command_handler(): registering 'ocd_mwh'... Debug: 89 320 command.c:364 register_command_handler(): registering 'ocd_mwb'... Debug: 90 320 command.c:364 register_command_handler(): registering 'ocd_bp'... Debug: 91 321 command.c:364 register_command_handler(): registering 'ocd_rbp'... Debug: 92 321 command.c:364 register_command_handler(): registering 'ocd_wp'... Debug: 93 322 command.c:364 register_command_handler(): registering 'ocd_rwp'... Debug: 94 322 command.c:364 register_command_handler(): registering 'ocd_load_image'... Debug: 95 323 command.c:364 register_command_handler(): registering 'ocd_dump_image'... Debug: 96 324 command.c:364 register_command_handler(): registering 'ocd_verify_image_checksum'... Debug: 97 324 command.c:364 register_command_handler(): registering 'ocd_verify_image'... Debug: 98 326 command.c:364 register_command_handler(): registering 'ocd_test_image'... Debug: 99 327 command.c:364 register_command_handler(): registering 'ocd_reset_nag'... Debug: 100 327 command.c:364 register_command_handler(): registering 'ocd_ps'... Debug: 101 328 command.c:364 register_command_handler(): registering 'ocd_test_mem_access'... Debug: 102 328 command.c:364 register_command_handler(): registering 'ocd_report_flash_progress'... Debug: 103 330 command.c:364 register_command_handler(): registering 'ocd_run_until_stop_fast'... Debug: 104 341 command.c:364 register_command_handler(): registering 'ocd_wait_for_stop'... Debug: 105 341 hla_interface.c:109 hl_interface_init(): hl_interface_init Debug: 106 341 hla_layout.c:83 hl_layout_init(): hl_layout_init Debug: 107 341 core.c:1612 adapter_khz_to_speed(): convert khz to interface specific speed value Debug: 108 342 core.c:1615 adapter_khz_to_speed(): have interface set up Info : 109 345 stlink_usb.c:1941 stlink_speed(): Unable to match requested speed 2000 kHz, using 1800 kHz Debug: 110 346 core.c:1612 adapter_khz_to_speed(): convert khz to interface specific speed value Debug: 111 346 core.c:1615 adapter_khz_to_speed(): have interface set up Info : 112 347 stlink_usb.c:1941 stlink_speed(): Unable to match requested speed 2000 kHz, using 1800 kHz Info : 113 347 core.c:1394 adapter_init(): clock speed 1800 kHz Debug: 114 347 openocd.c:142 handle_init_command(): Debug Adapter init complete Debug: 115 351 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_transport init Debug: 116 352 command.c:143 script_debug(): command - ocd_transport ocd_transport init Debug: 118 353 transport.c:239 handle_transport_init(): handle_transport_init Debug: 119 353 hla_transport.c:152 hl_transport_init(): hl_transport_init Debug: 120 354 hla_transport.c:169 hl_transport_init(): current transport hla_swd Debug: 121 354 hla_interface.c:42 hl_interface_open(): hl_interface_open Debug: 122 355 hla_layout.c:40 hl_layout_open(): hl_layout_open Debug: 123 355 stlink_usb.c:2010 stlink_usb_open(): stlink_usb_open Debug: 124 355 stlink_usb.c:2024 stlink_usb_open(): transport: 1 vid: 0x0483 pid: 0x3744 serial: Debug: 125 355 stlink_usb.c:2024 stlink_usb_open(): transport: 1 vid: 0x0483 pid: 0x3748 serial: Debug: 126 357 stlink_usb.c:2024 stlink_usb_open(): transport: 1 vid: 0x0483 pid: 0x374b serial: Error: 127 504 stlink_usb.c:2038 stlink_usb_open(): open failed Debug: 128 505 hla_layout.c:47 hl_layout_open(): failed Debug: 129 505 command.c:642 run_command(): Command failed with error code -4 User : 130 509 command.c:705 command_run_line(): in procedure 'init' in procedure 'ocd_bouncer' Debug: 131 513 command.c:642 run_command(): Command failed with error code -4 User : 132 518 command.c:705 command_run_line(): Debug: 133 526 target.c:1983 target_free_all_working_areas_restore(): freeing all working areas Debug: 134 528 hla_interface.c:117 hl_interface_quit(): hl_interface_quit
Firmware for the STlink has been updated, WinUsb Driver has been updated, I’ve tried switching USB cables and ports, several command line options have been tinkered with; no noticeable effect.
I used the VisualGDB properties page to download the OpenOCD drivers, and it say that the version 0.10.0. The OpenOCD website says that 0.10.0 isn’t stable yet, so maybe there’s something with that. I tried overwriting the openocd.exe and .dll’s with version 0.9.0, but VisualGDB wasn’t happy with that so I had to put it back to 0.10.0.
Note: I am currently running an Evaluation Version of VisualGDB, maybe that’s the issue?
November 30, 2018 at 06:54 #22954supportKeymasterHi,
This looks like some sort of driver incompatibility between OpenOCD and ST-Link. Unfortunately, as a free tool, OpenOCD sometimes doesn’t work with some USB controller/device combinations.
Generally, if you are looking for a hardware solution that works 100% reliably, please consider trying Segger J-Link. It is more expensive than ST-Link, but comes with its own equivalent of OpenOCD that is fully covered by Segger’s support and is compatible with more devices. VisualGDB fully supports it as well as OpenOCD.
Alternatively, please try the OpenOCD-based setup on a different machine (i.e. with a different USB host controller), or try reinstalling the ST-Link drivers.
November 30, 2018 at 09:21 #22955parsec67ParticipantI’m using ST-Link V2 and it works great with OpenOCD 0.10.0.
In the first line of your debug log there is a switch “-f C:/Users/mdric_000/AppData/Local/Temp/tmp62F7.tmp”
I don’t know if this is significant but comparing to my working setup I have “-f target/stm32f4x.cfg”
So maybe verify in VisualGDB Project properties/Debug settings window that “Debugged device” is set to your MCU type?
Also in the Debug settings options, try changing JTAG/SWD debugger option to ST-Link V2.1
HTH
November 30, 2018 at 19:51 #22957supportKeymaster@parsec67, thanks for your input. We will try to clarify what is going on below.
Based on the log file, the error happens during the USB connection phase, before the target script takes any effect:
hla_layout.c:47 hl_layout_open(): failed
The .tmp script is used when you modify the JTAG/SWD frequency via settings for device scripts (such as STM32F4) that have it hardcoded. In that case, VisualGDB will create a temporary copy of the script, edit the frequency there and pass it to OpenOCD.
OpenOCD generally works well with ST-Link v1, v2 and v2.1. We have internal tests checking it and many of our customers are successfully using it. Based on the input we have collected in the past years, in ~0.1% of the cases, it would simply fail to recognize the USB device. This has been previously caused by:
- 3rd-party USB-over-network software
- VMWare USB virtualization not releasing the device properly (normally it works with VMWare)
- A USB host controller by a non-mainstream vendor that was not compatible with libusb
- Unidentified problem with Windows USB drivers that got resolved by uninstalling the device drivers and reinstalling them from scratch
Given the the issue occurs very rarely and is located in an external component (libusb) and seems to be triggered by a different set of factors each time, unfortunately it’s hard for us to suggest any specific diagnostic steps other than trying a different computer (assuming that the issue happens from the very beginning with the default settings). We mentioned J-Link because it comes with its own USB driver and software and does not rely on libusb.
Hope this explains and sorry we couldn’t suggest anything more specific.
December 22, 2018 at 08:52 #23143canaanavParticipantI ordered the J-Link. No issues. I think it all has something to do with my base USB drivers for windows or my BIOS (2nd Gen Thinkpad Yoga 14). I decided not to mess with my machine and gambled on buying J-Link. Again, ST-Link doesn’t work, Segger works with absolutely no adjustments. Thanks Sysprogs for helping troubleshoot a product that isn’t even yours. I bought VisualGDB based on this experience and it debugs great.
December 24, 2018 at 08:51 #23151supportKeymasterHi,
No problem and thanks for the kind words. If you encounter any further issues, don’t hesitate to create another thread.
-
AuthorPosts
- You must be logged in to reply to this topic.