I’m not a big fan of using printf() in embedded applications, but I have to admit that in some cases it is very useful. One problem in debugging embedded systems debugging is getting values or information off the target: because of the limited resources this can be very challenging.
So why not doing this with the debugger in an automated way? And here dynamic printf breakpoints can help: it adds printf()-style output on-the-fly to your program without the need to recompile or restart your program, without the need to run printf() on the target:
Sometime I’m pretty sure I wrote about a topic I can find or refer to, and I was pretty sure I did write about ‘attaching to a running target’ using MCUXpresso IDE in an article, but Google does not find it? The only rational outcome is that I can blame Google and I have to come up with a potential duplicate ;-).
Anyway: attaching to a running target is such an essential life saver it deserves a dedicated article.
Using the debugger to inspect the application data is a very convenient thing. But if the data grows and if the data set is large, it makes more sense to dump the data to the host and process it offline. GDB is the de-facto debugger engine and includes a powerful command line and scripting engine which can be used in Eclipse too.
New ‘things’ start to pop up, useful or not: From smart bulbs (Philips Hue), thermostats (Nest), smart TV (Samsung and others) up to voice assistants (Alexa, Cortana, Google). You might even have installed one of these, right? What about temperature and humidity sensors? Probably there is nothing wrong with that?
But what would you think if one morning you find a strange unknown device installed under your working desk, connected to the cloud and internet?
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…
Error while launching command: arm-none-eabi-gdb –version
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:
No Source Available, debugging in assembly
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: