Being able to track down a bug in a mountain of source code is a skill in its own right, and it’s a hard skill to learn from a book or online tutorial. Besides the trial-by-fire of learning while debugging your own project, the next best thing is to observe someone else’s process. [Uri Shaked] has given us a great opportunity to brush up on our debugging skills, as he demonstrates how to track down and squish a bug in the Wokwi Arduino simulator.
A user was kind enough to report the bug and include the offending Arduino sketch. [Uri]’s first step was to reduce the sketch to the smallest possible program that would still produce the bug.
Once a minimal program had been produced, it was time to check whether the problem was in one of the Arduino libraries or in the Wokwi simulator. [Uri] compiled the sketch, loaded it onto a ATtiny85, and compared the behavior of the simulator and the real thing. It turns out the code ran just fine on a physical ATtiny, so the problem must have been in the Arduino simulator itself.
To track down the bug in the simulator, [Uri] decided to break out the big gun—GDB. What follows is an excellent demonstration of how to use GDB to isolate a problem by examining the source code and using breakpoints and print statements. In the end, [Uri] managed to isolate the problem to a mis-placed bit in the simulation of the timer/counter interrupt flag register.
If you’d like to see more of [Uri]’s debugging prowess, check out his dive into an ATtiny’s write protection and configuration fuses. If you’ve been wowed by the power of GDB and want to learn more, check out this quick tutorial!
I read this: “Running GDB in the Browser” by [Uri Shaked]:
https://blog.wokwi.com/running-gdb-in-the-browser/
This Wokwi Blog entry traces the very interesting development path for GDB in the browser. Yeah there’s the YouTube video too, but I think reading about something like this is far better than watching a YouTube video. Either way, I’m impressed with the result.
Thank you!
Why isn’t GDB still widely used in arduino?
GDB is an excellent debugger, but it requires platform support and memory to run. It is not practical to run it on Arduino in the same way as it runs on your PC when you are debugging from within your OS.
Usually embedded platforms use a small gdb server stub, talking to remote gdb on your computer, but even that is tricky to squeeze into an Arduino, and people just debug using blinking LEDs and print statements
What Uri did is brilliant because it leverages the emulator, so hardware limitations are gone and the interface is already in the browser so it’s less of a culture shock
I mean, even the tiniest of AVRs now support hardware debugging. In these situations, the debugger takes exactly zero resources on the target device. Breakpoints are set in special breakpoint registers, and when the program counter hits one of those addresses execution automatically stops and the device has all the time in the world to dump memory and registers to the attached PC. Debug symbols are also stored on the PC, so the debug build can be the exact same one released to production. I use GDB regularly with Cortex-M and serial-wire debug, but the tooling for AVR seems to be just a little behind. When done right, you can just set breakpoints in an IDE and click all the same buttons to watch values or step through lines of code.