I am trying to debug my daisy program but I can't get VSCode to program the device, even though it works from the command line.
When I do task program from the command palette I get
openocd -s /usr/local/share/openocd/scripts -f interface/stlink.cfg -f target/stm32h7x.cfg
-c "program ./build/PickupMachine.elf verify reset exit"
dyld[62640]: Library not loaded: /usr/local/opt/libusb-compat/lib/libusb-0.1.4.dylib
Referenced from: <2AF14ADF-FE69-3018-B458-47925DB060E7> /Library/DaisyToolchain/0.1.3-ARM/openocd/bin/openocd
Reason: tried: '/usr/local/opt/libusb-compat/lib/libusb-0.1.4.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/libusb-compat/lib/libusb-0.1.4.dylib' (no such file), '/usr/local/opt/libusb-compat/lib/libusb-0.1.4.dylib' (no such file), '/usr/local/lib/libusb-0.1.4.dylib' (no such file), '/usr/lib/libusb-0.1.4.dylib' (no such file, not in dyld cache)
make: *** [program] Abort trap: 6
I tried brew reinstall libusb
The same command works from the command line:
➜ PickupMachine git:(main) ✗ openocd -s /usr/local/share/openocd/scripts -f interface/stlink.cfg -f target/stm32h7x.cfg
-c "program ./build/PickupMachine.elf verify reset exit"
Open On-Chip Debugger 0.11.0
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
Info : clock speed 1800 kHz
Info : STLINK V3J7M2 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.297018
Info : stm32h7x.cpu0: hardware has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32h7x.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080005e0 msp: 0x20020000
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
** Programming Started **
Info : Device: STM32H74x/75x
Info : flash size probed value 128
Info : STM32H7 flash has a single bank
Info : Bank (0) size is 128 kb, base address is 0x08000000
Info : Padding image section 1 at 0x08011c50 with 16 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x08011c60 .. 0x0801ffff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked
The issue had to do with VSCode still using the old brew locations. If I install VSCode via brew (ironically) it looks for openocd, arm-none-eabi-gcc in the old /usr/bin folder. If I download VSCode using the Apple Silicon link at the visual studio site then it correctly uses the /opt/homebrew folder.
Related
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 am attempting to use openocd (STLINK-V2) to program a nrf device with both a soft device (bluetooth stack) and an application firmware (latest.hex).
This is the command I am using:
openocd -f interface/stlink.cfg -f target/nrf52.cfg -c init -c "reset init" -c halt -c "nrf5 mass_erase" -c "program btstack.hex verify" -c "program latest.hex verify" -c reset -c exit
It completes, but what I am not sure about is, is this the correct way of doing it ?
I have used esptool.py to flash esp devices and you need to specify the address that you want each hex file to be flashed to, but is this not necessary for openocd ? - does it know what to do automatically ?
The firmware runs, but the bluetooth does not appear to be active, and I was wondering whether the second hex file is overwriting the first one ?
This is the command that uses Segger programmer via nrfjprog (which I don't have)
nrfjprog --eraseall -f nrf52
nrfjprog --program drivers/bluetooth/s132_nrf52_6.0.0/s132_nrf52_6.0.0_softdevice.hex -f nrf52
nrfjprog --program build-pca10040-s132/firmware.hex --sectorerase -f nrf52
nrfjprog --reset -f nrf52
And there is an additional "--sectorerase" in this, what exactly is this doing and do I also need to add something similar into my openocd command ?
Also, there is an error: "set WORKAREASIZE 0" but if I set this as suggested, then it reports that there's not enough room and programming takes several minutes.
** Programming Started **
auto erase enabled
Info : Padding image section 0 at 0x00000a18 with 1512 bytes
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg/nrf52.cfg to disable it
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000001e msp: 0xfffffffc
wrote 155648 bytes from file btstack.hex in 7.037133s (21.600 KiB/s)
** Programming Finished **
** Verify Started **
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc
verified 151008 bytes in 0.529927s (278.281 KiB/s)
** Verified OK **
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000998 msp: 0x20000400
** Programming Started **
auto erase enabled
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg/nrf52.cfg to disable it
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000001e msp: 0x20000400
wrote 155648 bytes from file latest.hex in 7.042735s (21.583 KiB/s)
** Programming Finished **
** Verify Started **
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20000400
verified 154652 bytes in 0.462758s (326.364 KiB/s)
** Verified OK **
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.
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.
I'm trying to read the MCUs ADC register using GDB but I can't seem to find how it's done.
Using x\10x 0x40012708 in gdb just returns zeroes, as do any memory mapped peripheral register I try to read.
It this possible to do? If so, how is it done?
Thanks!
I would suggest to validate that your setup is functional first.
For example, you could try to read the CPUID register which is present on all Cortex-M0 processors - see section 4.3 of the Cortex™-M0 DevicesGeneric User Guide.
It is located at address 0xE000ED00, and it shall contain value 0x410CC200.
If you can read it, this would be a good sign.
You probably should try using J-Link commander first, then with GDB-Server and GDB. I ran the procedure hereafter on an Olimex board using an LPC1114/301 Cortex-M0. I was using J-Link software V5.10n, and arm-none-eabi-gdb version 7.10.1.20151217-cvs, which is part of Linaro gcc 5.2 for ARM Cortex-M processors package.
Start JLink.exe using the following options:
jlink.exe -if SWD -speed 4000 -AutoConnect 1 -device Cortex-M0
You should see something similar to:
SEGGER J-Link Commander V5.10n (Compiled Feb 19 2016 18:39:46)
DLL version V5.10n, compiled Feb 19 2016 18:39:11<br/>
Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware version: V8.00
S/N: [My J-Link EDU Serial Number]
License(s): FlashBP, GDB
OEM: SEGGER-EDU
Emulator has Trace capability
VTref = 3.313V
Device "CORTEX-M0" selected.
Found SWD-DP with ID 0x0BB11477
Found Cortex-M0 r0p0, Little endian.
FPUnit: 4 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl 0 # E00FF000
ROMTbl 0 [0]: FFF0F000, CID: B105E00D, PID: 000BB008 SCS
ROMTbl 0 [1]: FFF02000, CID: B105E00D, PID: 000BB00A DWT
ROMTbl 0 [2]: FFF03000, CID: B105E00D, PID: 000BB00B FPB
Cortex-M0 identified.
J-Link>
You can now read the CPUID register using the J-Link commander mem32 command, and verify the CPUID register does contain the expected value:
J-Link>mem32 0xE000ED00,1
You should get:
E000ED00 = 410CC200
If this is the case, I would say that your J-Link/Cortex-M0 setup is likely functional. We can now verify GDB Server and GDB are working fine too.
Launch JLinkGDBServerCL.exe with the following options: JLinkGDBServerCL.exe -if SWD -speed 4000 -device Cortex-M0
SEGGER J-Link GDB Server V5.10n Command Line Version
JLinkARM.dll V5.10n (DLL compiled Feb 19 2016 18:39:11)
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
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: Cortex-M0
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware: V8.00
S/N: [My J-Link EDU Serial Number]
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.31 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...
Keep the GDB server running, and start GDB in an other Windows console session:
arm-none-eabi-gdb
GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20151217-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
We can now connect to GDB server, and attempt to display the content of the CPUID register again:
(gdb) target remote localhost:2331
Remote debugging using localhost:2331
0xfffffffe in ?? ()
(gdb) monitor halt
(gdb) monitor reset
Resetting target
(gdb) x/1xw 0xE000ED00
0xe000ed00: 0x410cc200
(gdb)
If you are getting 0x410cc200 again, your J-Link/Cortex-m0/GDB Server/GDB setup should be functional, and you should now try again to read your ADC register using this command:
x/1xw 0x40012708
If you were able to read the CPUID register, but not the ADC register, and if the address for the ADC register is correct, I would not have an explanation for this behavior right now - knowing the exact brand/model for the MCU you are using could of course help further.
Please note that from now on, you should specify the exact model for your MCU as the argument to the -device J-Link Commander/GDB Server options instead of Cortex-M0. You can get the list by entering command ? on the J-Link Commander command-prompt.