Windows7 64bit
With the Nucleo connected to USB port I was able to use ST-LINK Utility to download the hex file to the board successfully. But after execute the command:
..\bin\openocd.exe -f board\st_nucleo_f7.cfg
With st_nucleof7.cfg contains following lines:
source [find interface/stlink-v2-1.cfg]
transport select hla_swd
source [find target/stm32f7x.cfg]
reset_config srst_only
...and stlink-v2-1.cfg has:
interface hla
hla_layout stlink
hla_device_desc "ST-LINK/V2-1"
hla_vid_pid 0x0483 0x374b
...and Device Manager shows USB Device as "STLINK dongle" with Hardware lds Value as:
USB\VID_0483&PID_374B&REV_0100&MI_00
USB\VID_0483&PID_374B&MI_00
It seems all VID and PID are matched.
...but I got the following error. Could someone tell me what is wrong in my setup please?
GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-00113-g0f83948 (2017-01-24-
18:48)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results mi
ght differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Error: open failed
in procedure 'init'
in procedure 'ocd_bouncer'
Thanks,
Brian
I found the answer here:
https://www.eevblog.com/forum/microcontrollers/openocd-fail-to-open-stm32-nucleo-board/
Evidently OpenOCD cannot connect to USB 3.0 port. I switched to another port and it worked!!!
Why no one at OpenOCD instructs that it doesn't work with usb 3.0? I have spent a few days on this problem.
I still don't know how to tell which port has 2.0 or 3.0 version looking at the Device Manager.
Related
I'm using STM32Cube IDE which is based on Eclipse. Nothing fancy in my code just initializes an on board LED and turns it on in infinite loop. It built and debugged successfully the first time(the LED did turn on) but the second time it could build but cannot debug.
Here's the error I got.
>Open On-Chip Debugger 0.10.0+dev-00021-g524e8c8 (2019-06-12-13:13)
>Licensed under GNU GPL v2
>For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
>Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
>adapter speed: 8000 kHz
>adapter_nsrst_delay: 100
>Info : Listening on port 6666 for tcl connections
>Info : Listening on port 4444 for telnet connections
>Info : clock speed 8000 kHz
>Info : STLINK v2 JTAG v25 API v2 SWIM v0 VID 0x0483 PID 0x3748
>Info : using stlink api v2
>Info : Target voltage: 2.891943
>Error: init mode failed (unable to connect to the target)
>in procedure 'init'
>in procedure 'ocd_bouncer'
When I try st-info --probe (on linux) I got:
Found 1 stlink programmers
serial: 390069063058303044662143
openocd: "\x39\x00\x69\x06\x30\x58\x30\x30\x44\x66\x21\x43"
flash: 0 (pagesize: 0)
sram: 0
chipid: 0x0000
descr: unknown device
But before upload I got relevant data eg:
flash: 131072 (pagesize: 1024)
sram: 20480
chipid: 0x0410
descr: F1 Medium-density device
No way of uploading code into microcontroller any way again. When I try new board it works just for that one upload - after that board is killed and works no more :( First upload of program works even after restart (LED is still blinking), but does not report to the ST-LINK v2.
I tried reset to default settings but it didn't help either. Has anyone ran into similar problems?
Found solution on Stackexchange.
When you forget to configure your debug port in STM32CubeIDE and upload your code, ST-Link will stop working, because its waiting for debugger to attach, but its not defined.
You have to assign SYS debug port in IDE (Configuration file -> SYS -> Mode -> Serial Wire):
Setup image
You can make your STM32 work again by removing whole flash by ST-Link Utility (I tried that in linux but does not work because it does not support connect under reset). In ST-Link Utility go to Settings -> Mode -> Connect under reset. Then connect mcu with ST-Link and hold reset. After that click "connect to the target" in ST-link utility and you are ready to erase it.
Possibly a rogue breakpoint is causing GDB to mis-behave. Possible workarounds to get going again:
If you last built a debug build, try building a release build and load the code. Then delete/erase all breakpoints and reload your debug version
Without launching a debug session, from the Eclipse main menu select Run->Remove All Breakpoints
If you have a copy of ST-Link Utility installed, launch and erase your chip
Trying to debug my sample blink_led code on STM32L476 Nucleo-64 board but gdb can't connect to OpenOCD (connection drops almost instantly with error). I've read plenty of posts here and there but none of them helped. Tried adding commands to OpenOCD using -c but no change of behavior.
My code compiles both in Release and Debug config in Eclipse. I can flash the bin file using drag and drop (while the board has built-in STLink add-on) and looks the code runs perfectly on the board (LED blinks).
Cross compiling on Centos7 using the following versions:
Toolchain (gdb): gcc-arm-none-eabi-8-2018-q4-major
OpenOCD: 0.10.0-11-20190118-1134
As using eclipse didn't work I tried the command line,
(I'm not an experienced developer in this environment so I could not find any config file closer to my stm32l476 board than the stm32l4discovery.cfg, please let me know if there might be some issues using it)
./bin/openocd -f scripts/board/stm32l4discovery.cfg -c "init"
It starts,
GNU MCU Eclipse 64-bit Open On-Chip Debugger 0.10.0+dev-00462-gdd1d90111 (2019-01-18-11:37)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 500 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : clock speed 500 kHz
Info : STLINK V2J28M17 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.244386
Info : stm32l4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Then starting GDB:
./arm-none-eabi-gdb ~/eclipse-workspace/test-blink-led/Debug/test-blink-led.elf
then running the following command in gdb:
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
Remote connection closed
As it shows gdb connection drops instantly and OpenOCD prompts the following errors:
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080022e6 msp: 0x20017ff8
Info : device id = 0x10076415
Warn : STM32 flash size failed, probe inaccurate - assuming 1024k flash
Info : flash size = 1024kbytes
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected
Error: jtag status contains invalid mode value - communication failure
Polling target stm32l4x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
So from those geeks who do it on a similar platform on a daily basis, can anyone help and tell me where am I doing wrong. Does missing any compile-time flag might result in this problem?
I'm scratching my head for a couple of days now so please let me have your hints.
One of the reasons may be that your STLINK firmware seems pretty old (STLINK V2J28M17 as your log shows). I suggest downloading the STSW-LINK007 application to upgrade the firmware. The software is a multiplatform Java application. It works flawlessly in Debian GNU/Linux.
Currently, I use another gdb server texane/stlink for my debugging task with GDB without any problem on some Nucleo and also custom boards. I use target extended-remote command to join the port of the server. Maybe you can try to connect with this command also under OpenOCD.
Try
telnet localhost 4444
it worked for me, while 3333 didn't
I'm using a Blue Pill board (STM32F103CB with 128kB of flash according to st-info --probe) via a clone ST-Link/V2 like this one. I've also tested using a genuine ST-Link/V2 like this one. I get the same result, described below, with both programmers.
My system is Linux (Debian LXDE) and I've installed OpenOCD from Liviu Ionescu's releases here.
My OpenOCD installation is working. As well as the Blue Pill I have a ST-Nucleo-F103RB board, and I can connect to it using OpenOCD. The command
openocd -f board/st_nucleo_f103rb.cfg
using the standard .cfg file that ships with OpenOCD gives
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v18 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.271135
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
But I still haven't managed to connect to my Blue Pill using the ST-Link/V2 programmers. I've read everything I can find, including relevant sections of https://elinux.org/Category:OpenOCD and as much as I can personally digest of http://openocd.org/doc/. The following is where I've got to.
The .cfg file stm32f103c8_blue_pill.cfg doesn't work for me. It produces the output described below.
Based on what I've read I've prepared my own .cfg file at ../board/stm32f103.cfg. It says:
source [find interface/stlink.cfg]
transport select hla_swd
source [find target/stm32f1x.cfg]
#source [find board/stm32f103c8_blue_pill.cfg]
#reset_config srst_only
#reset_config none separate
Sources I've read suggest this should work, but it doesn't. Using my .cfg described above, it I can use either target/stm32f1x.cfg or board/stm32f103c7_blue_pill.cfg, and I still get the same output as described below. (In the case of both of those .cfg files I'm using the standard files, as shipped with OpenOCD.) I've tested with both of the reset_config variants shown above, and with neither. None of the combinations works.
The file interface/stlink.cfg that I'm using is modified. I've changed it to state the correct device_desc "ST-LINK/V2" and the correct vid_pid 0x0483 0x3748. (Both confirmed using lsusb.) So, ignoring commented lines, stlink.cfg reads
interface hla
hla_layout stlink
hla_device_desc "ST-LINK/V2"
hla_vid_pid 0x0483 0x3748
I've experimented with including the hla_serial of the programmer. Interestingly, lsusb can't find the full serial number. st-info --probe finds the serial number, but gives a slightly different number from the STLinkUpgrade firmware application. I've tried using both serial numbers. No difference.
Here's the command I give to OpenOCD:
openocd -s ~/stm32/openocd/scripts -f board/stm32f103.cfg
Notice that I have to set the path using -s for this command. With the ST-Nucleo-F103RB board, I don't have to do this. With the stm32f103.cfg file, however, if I don't set the path I get:
Error: Can't find board/stm32f103.cfg
in procedure 'script'
If I use the full command shown above, with -s to set the path, I get:
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
/[..]stm32/openocd/scripts/target/stm32f1x.cfg:47: Error: invalid command name "dap"
in procedure 'script'
at file "embedded:startup.tcl", line 60
at file "/[..]stm32/openocd/scripts/board/stm32f103.cfg", line 18
at file "/[..]stm32/openocd/scripts/target/stm32f1x.cfg", line 47
Here's the offending line 47 of stm32f1x.cfg:
dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu
I've searched for items on Stackoverflow/ similar about Error: invalid command name "dap". Using the OpenOCD documentation I understand that the dap create command exists, and roughly what it does. The most similar reported error I've found documented is at https://elinux.org/OpenOCD_Troubleshooting:_Invalid_Command_Name_JTAG, and the solution suggested there doesn't seem to be applicable because I'm not invoking interface/stlink.cfg from the command line.
I can't see what I'm doing wrong, and I'm now completely stuck. If someone can give me a steer I'd be really grateful. Sorry it's such a long post.
I just encountered this problem too. Officially there are no binaries provided, only source code. But there are two sites which release binaries was recommended by OpenOCD official:
1. Maintained by Freddie Chopin.
2. Maintained by Liviu Ionescu in Github.
I tried the latest version(OpenOCD 0.10.0 commit date: 2017-01-22 20:31:28 build date: 2017-01-23) released from Freddie Chopin's site, and I encountered this Error: invalid command name "dap" problem. But all *.cfg files I referenced had ran normally in my another computer with another OpenOCD binary(although I forgot where did I download that binary).
Not sure what went wrong, so I turned to the latest version(gnu-mcu-eclipse-openocd-0.10.0-11-20190118-1134-win64.zip) released by GNU MCU Eclipse(maintained by Liviu Ionescu), the error was gone, problem solved.
PS: I'm not saying there is a bug in Freddie Chopin's build, but if someone encountered this problem, maybe you can solve it by trying the version which is currently under actively maintained.
Agree with Wulfric, using standard install for OpenOCD
sudo apt install openocd
gave the "dap" error.
However the github version openocd-xpack worked correctly.
Using:
Linux clamps 4.15.0-66-generic #75-Ubuntu SMP ... as remote, Windows 8/10 as client target MIMXRT1010-EVK
On my Windows10, having stm32f407vg discovery boards I'm doing example: f4-blog-master
Then I got this error:
D:\Software\OpenOCD-20170821\bin\openocd.exe -c "tcl_port disabled" -s D:\Software\OpenOCD-20170821\share\openocd\scripts -f board/stm32f4discovery.cfg -c "program \"E:/EDA223_Real-Time-Systems/EDA223_CODE/STM32CubeMX/f4-blog-master/cmake-build-debug/f4-blog.elf\";reset init;"
GNU MCU Eclipse 64-bits Open On-Chip Debugger 0.10.0+dev-00404-g20463c28 (2018-0
1-23-12:30)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results mi
ght differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : STLINK v2 JTAG v29 API v2 SWIM v18 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 2.883666
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 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: 0x080004c8 msp: 0x20020000
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
** Programming Started **
auto erase enabled
Info : device id = 0x10076413
Info : flash size = 1024kbytes
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000046 msp: 0x20020000
wrote 16384 bytes from file E:/EDA223_Real-Time-Systems/EDA223_CODE/STM32CubeMX/
f4-blog-master/cmake-build-debug/f4-blog.elf in 0.788115s (20.302 KiB/s)
** Programming Finished **
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: 0x080004c8 msp: 0x20020000
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
Info : tcl server disabled
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333
Info : dropped 'gdb' connection
Code is uploaded, gdb get connection, but then debugger console says:
Truncated register 16 in remote 'g' packet
Debugger disconnected
How to fix it?
PS: My OpenOCD settings seems valid. Did not set anything in toolchain besides normal MinGW-w64. Cmake settings are default ones. In Debug config I target: UPLOAD, executable: f4-blog.elf.
When I do Tools-> Run OpenOCD, I got:
...
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
So OpenOCD seems fine, but gdb is crashing, why?
I had the same issue. To fix it, I first added a toolchain based on i686-w64-mingw32 (32-bit version of mingw-w64) in Settings > Build, Execution, Deployment > Toolchains like SapuSeven suggested, but it still did not work, so I also changed the "Debugger" of this toolchain to the arm-none-eabi-gdb.exe debugger of my ARM toolchain installation (C:\Program Files (x86)\GNU Tools ARM Embedded\7 2018-q2-update\bin\arm-none-eabi-gdb.exe on my computer) and it worked. Make sure to set this new toolchain as the default one by moving it up in the toolchains list.
Also I think that both the Target and Executable fields of the "OCD loop" run/debug configuration should be set to "< project_name >.elf" as shown in the CLion docs, rather than "UPLOAD".
Try installing the 32bit-version of MinGW. Don't forget to change the toolchain to this new version inside CLion - this helped in my case.
I am having trouble getting a reliable debugging setup.
I have seen other threads in some forums across the net with a similar title, but the circumstances seem different.
Setup:
Linux (Xubuntu) 64bit
Eclipse CDT, Neon 4.6.0
"GDB Hardware Debugging" plugin from eclipse "install new software", configured to reset & delay 3sec, halt; load symbols (all checkboxes, no custom commands)
arm-none-eabi-gcc 4.8.3 tool chain
OpenOCD, recently downloaded, running in an own console, configured for my exact MCU with script provided by them & the st-link
STM32L476RG MCU with hard float, which is used.
ST-Link V2 debugger (stand-alone)
Now, there is a sequence with which I am, after some struggle every time, able to connect with the debugger, but stepping and reading variables doesn't work so clearly reliable that I'd trust what I see for a second.
But to even get to that point where the call stack would not be full of obvious nonsense entries and only very few of them, is tiring.
Example:
Flash the device with the firmware. This usually works without trouble.
Start openocd.
Start debugging in Eclipse.
OpenOcd shows connection, then says: "undefined debug reason 7 - target needs reset"
I regardless press the "resume" button in Eclipse to make the program run past the bogus top stack frame it shows.
Press "suspend" (still bogus in callstack), then "terminate".
Ctrl+C out of OpenOcd.
Manually (hardware) reset the stm32 MCU.
Restart OpenOcd.
Start debugging in Eclipse again.
OpenOCD output:
GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-dev-00287-g85cec24-dirty (2016-01-10-10:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 500 kHz
adapter_nsrst_delay: 100
none separate
none separate
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : clock speed 480 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.192646
Info : stm32l4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x10076415
Info : flash size = 1024kbytes
undefined debug reason 7 - target needs reset
Now with some luck, I finally have a somewhat working debugger connection, for a while.
But this may as well need some repetitions.
Why the "press resume" in between when it's clear the connection is bad? Not sure, this seemed to increase the likelihood that in the next iteration I'll have the connection, a lot.
A maybe relevant note:
The MCU has an LCD connected to it and from that I can see when it resets.
For some reason, starting debugging in Eclipse will apparently not reset the device, although the reset checkbox is checked in the debug config.
If I open a telnet connection to OpenOCD in a terminal, and do "reset" there, the device does reset.
What could be causes for the odd behavior of my setup?
What OpenOCD client you're using? I made a mistake using the host gdb and I got this error. And after I modified my debugger path to the location of my arm-none-eabi-gdb in "Debug Configuration" of your eclipse the problem disappeared.
From your post you only mentioned you used arm-none-eabi-gcc toolchain, so don't know if you set your gdb to arm-none-eabi-gdb in "Debug Configurations", which is separate from project toolchain settings.
Another version of OpenOCD helped me. Met a similar issue with OpenOCD 0.10.0 from http://gnuarmeclipse.github.io. Initially it worked then the issue appeared. Removed it and installed the build from http://www.freddiechopin.info.