[SOLVED] st-util & gdb worked once – now dies

After some helpful input from this forum and some trial and error with commands, I got st-util and gdb to work perfectly last night. But when I tried the same commands today, it fails miserably. I’m running Ubuntu 16.04. Here’s what I did:
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

Oops! The invocation of st-util is done as ./st-util, not ~/st-util. Sorry for the confusion.

Why was this marked solved?? All I did was clarify one line – a typo only. Nothing else changed.

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.

Maybe you could try my script that uses openocd instead of st-util.

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]

Thanks for your responses. Let me address the second one first.

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.

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.

[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

I have probably 4 or 5 different ways to run a gdb server with an stlink device. (st-util, stlink gdb server, openocd, eclipse, System workbench)

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.

Thanks for all the info! I really appreciate, but you can probably understand that I am now in drinking-from-a-firehose mode. Here’s my thinking:

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.

Per your suggestion (one of many), I downloaded and installed the Atollic tools from ST. It’s a 750MB download, but once installed, the gdb server works great! I had to update my ST-Link, but there’s a java jar for doing that. Use sudo, and it works fine also. With the ST-Link connected and running the Atollic gdb server, I connected with the arm-none-eabi-gdb, and successfully uploaded and debugged my 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!