Developers love their macs, and if you look at the software that comes with it, it’s easy to see why. OS X is a very capable Unix-ey environment that usually comes on very capable hardware. There is one, huge, unbelievable shortcoming in OS X: the debugger sucks. GDB, the standard for every other platform, doesn’t come with OS X and Apple’s replacement, LLDB is very bad. After crashing Safari one too many times, [Brandon Edwards] and [Tyler Bohan] decided they needed their own debugger, so they built one, and presented their work at last weekend’s Shmoocon.
Building a proper tool starts with a survey of existing tools, and after determining that GDB was apparently uninstallable and LLDB sucked, their lit review took a turn for the more esoteric. Bit Slicer is what they landed on. It’s a ‘game trainer’ or something that allows people to modify memory. It sort of works like a debugger, but not really. VDB was another option, but again this was rough around the edges and didn’t really work.
The problems with the current OS X debuggers is that the tools used by debuggers don’t really exist. ptrace is neutered, and the system integrity protection in OS X El Capitan has introduced protected locations that can not be written to by root. Good luck modifying anything in /Applications if you have any recent Mac.
With the goal of an easy-to-use debugger that was readily scriptable, [Brandon] and [Tyler] decided to write their own debugger. They ended up writing the only debugger they’ve seen that is built around kqueue instead of ptrace. This allows the debugger to be non-invasive to the debugged process, inject code, and attach to multiple processes at once.
For anyone who has every stared blankly at the ‘where is GDB’ Stack Overflow answers, it’s a big deal. [Brandon] and [Tyler] have the beginnings of a very nice tool for a very nice machine.
We hope we’re not insulting you by suggesting this, but it’s possible that even the best among us may be faced with bugs in our embedded code from time to time. And while we’re great fans of
printf debugging over the serial port, and its high-speed equivalent — flipping a GPIO pin — there’s a time when your bug is so deep that having a real debugger is the best way to dig it out.
[slaff] has been doing some great work documenting C/C++ programming on the ESP-8266, mostly using Eclipse and some of the Arduino libraries. In the fourth part of his series of posts, he walks through using a couple debugger options for the ESP. What makes this all work is the ESP-gdbstub code from Espressif themselves. gdbstub looks great — it works both with the standard SDK as well as with FreeRTOS, so you can debug your ESP-8266 code whether it’s in an OS or on the bare metal. And all this just using the standard serial connection that’s used for programming.
Now, this still may not help with timing-related bugs. ESP-gdbstub uses the serial port, after all. But having the ability to set breakpoints and interactively inspect what’s going on in the chip’s memory is priceless, and doing so with no extra hardware connections is brilliant.
Continue reading “Squash Your ESP-8266 Bugs with ESP-gdbstub”
Are you tired of hammering out the same commands over and over again in GDB? If not, we highly encourage you take more advantage of The GNU Project Debugger, which is a fantastic way to poke around inside your microcontrollers while they’re running a program.
Back to the matter at hand. [Stef] put together a Python program that leverages GDB’s Remote Serial Protocol. He calls it pyrsp and the talk he recently gave about it can be seen below.
The core feature is the ability to add a callback in your C code that triggers the Python script. Think of this a little bit like a print statement, except you have so much more power since it’s Python and GDB doing the “printing”. Anything that can be done at a breakpoint in GDB can now be executed automatically. So if you need to check a group of registers at every loop execution for hundreds of loops your wrists are going to thank you. Better yet, you can use Python to do the sanity checks automatically, continuing when the data is good and alerting you when it’s not. Neat!
Continue reading “Scripting Debug Sessions: Python for GDB Remote Serial Protocol”
[Lee] wrote in to tell us about a Set Top Box he hacked. Before the cable industry lawyers get out their flaming swords… he’s not stealing cable, or really doing much of anything. This is a hack just for the adventure and thrill of making someone else’s hardware design do your bidding without any kind of instructions.
He posted about the adventure in two parts. The first is finding the JTAG header and identifying the pins. Arduino to the rescue! No really, and this is the type of Arduino use we love. Using a package called JTAGenum the board becomes a quick tool for probing and identifying JTAG connections.
The image above shows a different piece of hardware. From looking at it we’re pretty sure this is a Bus Blaster which is specifically designed for JTAG debugging with ARM processors. This is the beginning of the second part of his documentation which involves code dumping and stepping through lines code (or instructions) using OpenOCD and GDB. It’s a chore to follow all that [Lee] discovered just to write his name to the display of the box. But we certainly found it interesting. The display has a convoluted addressing scheme. We assume that there are cascading shift registers driving the segments and that’s why it behaves the way it does. Take a look for yourself and let us know what you think in the comments.
A simple resistive DAC is all you need to drive a VGA display. Combining that with an on-chip DAC for audio, the STM32F405RGT6 looks like a good choice for a DIY game console. [Makapuf’s] Bitbox console is a single chip gaming machine based on the STM32 ARM processor.
We’ve seen some DIY consoles in the past. The Uzebox is a popular 8 bit open source game system, and [makapuf] was inspired by its design. His console’s use of a more powerful 32 bit processor will allow for more complex games. It will also provide more colors and higher quality audio.
One of the keys of the Uzebox’s success is the development tools around it. There’s a full emulator which allows for debugging with GDB. [Makapuf] has already built an SDL based emulator, and can debug the target remotely using GDB. This will certainly speed up game development.
After the break, check out a demo of the first game for the Bitbox: JUMP. Also be sure to read through [makapuf]’s blog for detailed information on the build.
Continue reading “The Bitbox Console: an Open Source Gaming Rig”
As your embedded applications get more complicated an On-Chip Debugger will save you a lot of time when things don’t run quite right. On-Chip Debugging (OCD) is just what it sounds like — a way to run your program on the target chip that lets you pause execution to examine values and change them if need be. The Arduino has no built-in method of using OCD, but the AVR chips used by the boards do. The caveat is that you need a proper AVR programmer to access the Debug Wire protocol, or a JTAG interface for some of the larger chips. In this case I’m going to be using an STM32 Discovery Board to give you an overview of OCD. But this will work the same way for any chip that has hardware debugging capabilities. Many IDE’s have debugging support built right in so that you can use a nice GUI as you work. But often these are just a front end for the command line tools I’ll be using. Join me after the break and we’ll get started.
Continue reading “Beginner’s look at On-Chip Debugging”