My test program (sketch if you must) is built in Arduino. This creates the directory in /tmp that has the .elf.
I start st-util from the stLink directory with: ~/st-util -s 2.1 -p 2468. It starts with appropriate messages and waits for gdb.
I start gdb from another command window with: gdb [ArduiinoFile].ino.elf. No problem.
But then: target extended-remote :2468 and things fall apart.
Here’s part of the output. Before this, the messages look fine. After it comes more LIBUSB time outs.
2018-07-20T16:46:33 INFO /local/data/work/stm32/repo/stlink/src/gdbserver/gdb-server.c: Listening at *:2468...
[!] send_recv send request failed: LIBUSB_ERROR_TIMEOUT
[!] send_recv STLINK_DEBUG_FORCEDEBUG
[!] send_recv send request failed: LIBUSB_ERROR_TIMEOUT
[!] send_recv STLINK_DEBUG_RESETSYS
[!] send_recv send request failed: LIBUSB_ERROR_TIMEOUT
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
[!] send_recv send request failed: LIBUSB_ERROR_TIMEOUT
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2018-07-20T16:47:37 INFO /local/data/work/stm32/repo/stlink/src/gdbserver/gdb-server.c: Found 9 hw breakpoint registers
[!] send_recv send request failed: LIBUSB_ERROR_TIMEOUT
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
The problem is still the same! I just didn’t want anyone to think there was a trivial solution.
Please remove the SOLVED marker.
Thanks.
I noticed in other posts you seem to be trying to debug an STM32L0 chip so you will have to change these line:
...
openocd ${DEBUG_FLG} -f interface/stlink.cfg -f target/stm32l0x.cfg \
-c "program ${HEX_FILE} verify reset exit"
...
-e openocd -f interface/stlink.cfg -f target/stm32l0x.cfg &
...
[doctek – Sat Jul 21, 2018 12:06 am] –
I start gdb from another command window with: gdb [ArduiinoFile].ino.elf. No problem.
This is the wrong command to run. This runs the gdb associated with your desktop (most likely intel and linux) you need to run:
$ arm-none-eabi-gdb -ex ‘target extended-remote:2468’ [ArduinoFile].ino.elf
I haven’t run st-util in a long time, it still seems to have issues with finding the source and working properly. Which is why I switched to openocd.
[Edit] I went and found the st-util from the stm32duino tools package directory and it seems to work fine [/Edit]This is the wrong command to run. This runs the gdb associated with your desktop (most likely intel and linux) you need to run:
Yes, another typo. I am using the arm-none-eabi version, or it would never have worked at all. As I mentioned, it has worked perfectly.
Thanks for checking st-util. When I try to run it, it won’t work at all if I select port 1234. Seems to work with port 2468, but even then, it often fails to correctly identify my processor chip and instead identifies the st-link chip (a F-103, I think). What really bugs me is that I have seen it work perfectly with the same setup and the same commands. Arrgh!
Regarding your first post, you are correct about the chip. I’m working with an STM32L053R8 on a NUCLEO. My goal is to use the 32L031G6U, but I want to learn to stumble before I try to fall.
While I really like the approach you’ve created, I was hoping to get the debugger working without having to do additional setup and downloads. I’m fine with all that, but I wanted a minimal overhead approach for those who aren’t used to command line, etc. Also, I’d like to understand WHY the st-util approach is failing. Otherwise, I’m afraid I’ll end up having a more complicated setup that still won’t work.
Again, thanks so much for your assistance and suggestions.
[doctek – Sat Jul 21, 2018 8:29 pm] –
While I really like the approach you’ve created, I was hoping to get the debugger working without having to do additional setup and downloads. I’m fine with all that, but I wanted a minimal overhead approach for those who aren’t used to command line, etc.
If you want the least overhead way to go you should look at using black magic probe. It only requires arm-none-eabi-gdb. Nothing else.
Here is what I do to upload and launch debugging with BMP:
platform.txt wrote:# blackmagic probe+debug
tools.bmp_debug.port=/dev/ttyACM0
tools.bmp_debug.speed=115200
tools.bmp_debug.path=
tools.bmp_debug.cmd=arm-none-eabi-gdb
tools.bmp_debug.upload.params.verbose=
fools.bmp_debug.upload.params.quiet=-q
tools.bmp_debug.upload.pattern=xterm -bg #ffffe0 -fg #000000 -T ‘Arduino Debugger’ -e “{path}{cmd}” -cd={build.path} -ex “file {build.project_name}.elf” -n {speed} {upload.verbose} -ex ‘set pagination off’ -ex ‘set confirm off’ -ex ‘set mem inaccessible-by-default off’ -ex “target extended-remote {port}” -ex “monitor swdp_scan” -ex “attach 1” -ex “layout split” -ex “load” -ex “tb setup” -ex “run” {build.project_name}.elf
However, If you want something that is really supported you should download and install the latest free Atollic TrueSTUDIO. This formerly expensive commercial quality development tool was acquired by ST Microelectronics at the end of last year. It used to support a wide variety of arm vendors. ST had them yank out support for anything not ST and then the made it free and unlimited.
However you don’t have to run the Atollic IDE to use its gdb server. To start it up run:
$ bash /opt/Atollic_TrueSTUDIO_for_STM32_x86_64_9.0.0/Servers/ST-LINK_gdbserver/ST-LINK_gdbserver.sh
You can then connect to it with:
$ arm-none-eabi-gdb -ex ‘target remote:61234’ Blink.ino.elf
Runs nice and fast, and just works.
I’m convinced that using st-util is a bad plan. That’s out.
I really like the look of your approach modifying the Arduino environment. However, I’m a little concerned by your comment
arm-none-eabi-gdb and openocd are part of the samd core. It doesn’t seem like they have kept it up to date though. It doesn’t have the newer configs for the stlink-v2.1 or the stm32l0x chips.
Does that mean that your Arduino approach won’t work for the chips I want to use?
I’m going to look into the Black Magic probe. I have an old ST Discovery board with stLink version 1 that was converted to be a Black Magic probe some years ago. I’m going to look into updating that if possible.
Seems like the Atollic gdb server could be the best plan. I’m going to try to find and install it.
Finally, you observe:
99.9% of Arduino users don’t care about debugging, they think that the Serial port was made for debugging.
While it’s true that 99.9% only use printf debugging, very few will be willing to admit they don’t care about on-chip debug if it’s possible. No one wants to ride a bike with training wheels. So they’ll want the capability even if they never use it. I’m not sure how that will play out.
[doctek – Sun Jul 22, 2018 12:49 am] –
I really like the look of your approach modifying the Arduino environment. However, I’m a little concerned by your comment
arm-none-eabi-gdb and openocd are part of the samd core. It doesn’t seem like they have kept it up to date though. It doesn’t have the newer configs for the stlink-v2.1 or the stm32l0x chips.
Does that mean that your Arduino approach won’t work for the chips I want to use?
If you install openocd using apt linux utilities, it support everything.
My comment was more about what you get by default when installing cores from the Arduino library manager. The arduino openocd binary is way behind the lastest openocd code.
Can’t thank you enough for all the help! Next I want to look more into using your Arduino / OpenOCD tools. But for now, I can get on with my project.
You can mark this one as solved now!