GDB supports a mode which allows the GDB debug client to read memory while the target is running. This allows features like ‘live variables’: that way I can see the variables refreshed and changing over time without halting the target. Another functionality which comes with that feature is to check stopped threads or to see all threads in the system.
Open Source software has been around for decades. But open source on hardware especially microcontroller is not much a reality these days. But there is something which might change this: RISC-V is a free and open RISC instruction set architecture and for me it has the potential to replace some of the proprietary architectures currently used. RISC-V is not new, but it gets more and more traction in Academia (no surprise).
I wanted to play with RISC-V for over a year, but finally a week ago I did one of these “hey, let’s buy that board” thing again. Sometimes these boards get on a pile to wait a few weeks or longer to get used, but that one I had to try out immediately :-).
Three years ago I published “Debugging Failure: Check List and Hints” and unfortunately this article is one of the most popular ones: obviously debugging problems are very common. Debugging with GDB works usually fine, but if things are failing, then it can be hard to find the cause for it. Recently I have been asked to check some failures, so here are two more hints about what could go wrong…
Sometimes it happens that arm-none-eabi-gdb complains about “no source file named” in the GDB console view in Eclipse when I debug a project with GDB:
When working and debugging a bootloader, debugging can be a challenge: During debugging the bootloader, a new binary gets loaded into the microcontroller address space which is unknown to the debugger. As soon as I step into the newly loaded binary, I only see assembly code, with that ugly “No source available” in Eclipse:
But wait: GDB is able to do pretty much everything you can imagine, so here is how to debug multiple binaries with GDB and Eclipse, and to turn the above into something which is easy to debug:
Recently I have been running into the following error message in Eclipse when I started the GDB debugger:
Sometimes things don’t go well, especially with bringing up a new board design. I always sweat blood that first minute when I try to connect with the debugger to a new design: Will it work? After the optical inspection, performing electrical tests (no shortcuts? voltage levels ok?) the inflection point is when I’m connecting the first time with the debugger to the new board: either it will properly connect and program the device (hurrah!) or it will fail and potentially difficult hours of investigations have to follow.
The reset and signal line of a microcontroller is probably the most important signal to a microcontroller. And if things go wrong, then a first thing to check is the reset line. So having control over reset is an important aspect for embedded development. You would think that if you download a program to a microcontroller, the debug probe would put the device into reset at the start with a short pulse like this:
In “A Processor Expert Component to Help with Hard Faults” I’m using a C handler with some assembly code, created with Processor Expert, to help me with debugging hard faults on ARM Cortex-M. Inspired by a GNU gdb script here, I have now an alternative way. As this approach is using the GDB command line approach, it works both with an Eclipse GUI and with using GDB in command line mode only :-).