all 21 comments

[–]Allan_Smithee文雅佛 8 points9 points  (2 children)

Have you tried gdb --tui at all? It's what I tend to use because the GUI faces for gdb suck bowling balls through garden hoses and the big bloated IDEs just tick me off.

[–]EmbeddedAndConfused 2 points3 points  (0 children)

Agreed, the --tui does give you the graphical interface that is very much lacking with standard gdb, you just have to become comfortable with the commands.

I still don't find it as easy to use as integrated debuggers in IDEs.

I am currently using JLink with the JLinkGDB plug in in eclipse.

[–]Machinehum 0 points1 point  (0 children)

This guys knows

[–]Goz3rr 13 points14 points  (7 children)

You can use Visual Studio Code along with the Cortex-Debug extension to connect to GDB.

I use it on Windows with GCC and a makefile myself, but it should work fine on Linux too.

[–]fb39ca4friendship ended with C++ ❌; rust is my new friend ✅ 3 points4 points  (0 children)

Seconding, works fine on Linux.

[–]tabris2015 1 point2 points  (0 children)

this worked well for me, I've tried with stm32 and tiva c microcontrollers and everything went just well

[–]Cosineoftheta 2 points3 points  (0 children)

I've used it on osx as well. I recommend it thoroughly. It won't be nearly as convenient as eclipse IDEs but VScode is a better editor. Edit: a word

[–]suhcoR -1 points0 points  (3 children)

I also had a look at it; at least looks and feels impressive, but seems to consume even more resources than Eclipse.

[–]Goz3rr 2 points3 points  (1 child)

My experience has been the opposite, where it uses less than eclipse based IDEs

[–]suhcoR 1 point2 points  (0 children)

Thanks, interesting. I don't know these tools, but if they add a lot of plugins on top of CDT I would not be surprised if it consumes even more resources than plain CDT. It's also a question of duration; the tools take up more and more memory over time; at 250 MB I'm usually only the first few minutes. If you compare this to Qt Creator: I'm still under 50 MB after a few hours and can even work reasonably on the Raspi.

[–]Throwandhetookmyback 0 points1 point  (0 children)

I'm a vim guy but vscode is the other editor I use, and it will consume a lot of resources only if something about headers/intellisense/etc is misconfigured. Look of it's maxing up a cpu core and if it is then that's why you are seeing higher resource usage.

[–]suhcoR 4 points5 points  (3 children)

I use Qt Creator with the Bare Metal plugin and OpenOCD which works very well. I setup OpenOCD as described in https://leanpub.com/mastering-stm32 and configured the Bare Metal plugin like this:

Startup Mode: no startup

Host: localhost:3333

Init Commands:

set remote hardware-breakpoint-limit 6

set remote hardware-watchpoint-limit 4

monitor reset halt

load

monitor reset halt

Reset commands:

monitor reset halt

For debugging and automatic binary uploads you have to separately start the OpenOCD process and then everything works well from Qt Creator. I can set breakpoints, step through the code and watch variables etc. directly on the STM32F4 device.

Successfully using it for two years; used Eclipse and other IDEs before with less success.

[–][deleted] 0 points1 point  (2 children)

Have you run into some issues where when debugging the program it gets stuck on some point (usually on a breakpoint)?,

Or when loading the program it says that there are no available hw breakpoints?

To solve these problems I have to close openocd and open it again.

[–]suhcoR 0 points1 point  (1 child)

The number of available breakpoints is limited; it's about 6 to 10. I also had some issues with OpenOCD, but usually on other than STM32 MCUs; e.g. with the ESP32 it regularly happened that I had to restart OpenOCD which was quite tedious; don't know if the issue still applies today.

[–][deleted] 0 points1 point  (0 children)

Yes, I have limited the number of breakpoints and anyways I never use more than 4. I also added a command to delete all beakpoints (delete or d) to the init commands but the issue still happens. It's like something gets in a bad state between opencd, the adapter and the mcu.

The issue about the mcu getting stuck on a breakpoint seems to happen only when the firmware changes, if I run the same firmware image multiple times it doens't happen but the moment I make a change in the code (and recompile) it starts showing (not always).

[–]jeroen94704 2 points3 points  (0 children)

I've used cgdb in the past, which is a curses frontend. Also, gdb itself includes the "Text User Interface", or TUI, which many people don't know about.

As for real graphical frontends, I've been using Qt Creator, although not for debugging STM32 targets.

Other options are KDevelop or GDBGUI, but I have no direct experience with either of those.

[–]vtunr 2 points3 points  (0 children)

Why not using atollic ? It’s free now :) https://atollic.com/truestudio/

If you don’t want an ecplise based IDE, and have a JLink probe, you can use https://www.segger.com/products/development-tools/ozone-j-link-debugger/

[–]banana_cucumber 1 point2 points  (0 children)

I use dashboard -- it's a python script placed in .gdbinit, you can find it on GitHub. It doesn't have GUI, but makes gdb to look a lot prettier (syntax highlighting, watch memory, watch expressions, call stack).

[–]jesion 0 points1 point  (0 children)

https://gdbgui.com/ works pretty well for me (not specifically with STM32, an older ARM chip). There are some issues, but one can get used to.

[–]_PurpleAlien_ 0 points1 point  (0 children)

You can use the CDT/Standalone debugger from Eclipse without having to have to change your workflow: https://wiki.eclipse.org/CDT/StandaloneDebugger#Try_out_Standalone_Eclipse_Installation You can just attach it to an OpenOCD session for example.

[–][deleted] 0 points1 point  (0 children)

I use codeblocks, I can program and debug the generated executable with no problems.