debugging

The BeagleBoneBlack is a SoC of choice for many hackers – and quite rightly so – given its powerful features. [abhishek] is majoring in E&E from IIT-Kharagpur, India and in 2014 applied for a project at beagleboard.org via the Google Summer of Code project (GSoC). His project, BeagleLogic aims to realize a logic analyzer using the Programmable Real-Time units on board the AM335X SoC family that powers the BeagleBone and the BeagleBone Black.

The project helps create bindings of the PRU with sigrok, and also provides a web-based front-end so that the logic analyzer can be accessed in much the same way as one would use the Cloud9 IDE on the BeagleBone/BeagleBone Black to create a new application with BoneScript.

Besides it’s obvious use as a debugging tool, the logic analyzer can also be a learning tool that can be used to understand digital signals. BeagleLogic turns the BeagleBone Black into a 14-channel, 100Msps Logic Analyzer. Once loaded, it presents itself as a character device node /dev/beaglelogic. In stand-alone mode, it can do binary captures without any special client software. And when used in conjunction with the sigrok library, BeagleLogic supports software triggers and decoding for over 30 different digital protocols.

The analyzer can sample signals from 10Hz upto 100MHz, in 8 or 16 bits and up to a maximum of 14 channels. Sample depth depends on free RAM, and upto 320MB can be reserved for BeagleLogic. There’s also a web interface, which, once installed on the BeagleBone, can be accessed from port 4000 and can be used for low-volume captures (up to 3K samples).

[abhishek] recently added the BeagleLogic Cape which can be used to debug logic circuits up to 5V safely. Source files for BeagleLogic as well as the Cape are available via his github repos. [abhishek] blogged about his project on his website where there’s a lot more information and links to be found. Catch a video of BeagleLogic after the break.

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.

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!

Energia is a tool that brings the Arduino and Wiring framework to Texas Instruments’ MSP430 microcontrollers and the MSP430 Launchpad development board. This allows for easy development in an Arduino-like environment while targeting a different microcontroller family.

One problem with Energia and Arduino is the difficulty of debugging. Usually, we’re stuck putting a Serial.println(); and watching the serial port to trace what our program is doing. Other options include blinking LEDs, or using external displays.

Code Composer Studio, TI’s official development tool, allows for line-by-line debugging of applications. You can set breakpoints, watch the value of variables, and step through an application one instruction at a time.

The good news is that the latest version of Code Composer Studio supports importing Energia sketches. Once imported, you can step through the code and easily debug your application. This is a huge help to people developing more complex software using Energia, such as libraries.

TI gives us an overview of the new feature in a video after the break.

In proper, high-dollar embedded development environments – and quite a few free and open source ones, as well – you get really cool features like debugging, emulation, and profiling. The Arduino IDE doesn’t feature any of these bells a whistles, so figuring out how much time is spent in one section of code is nigh impossible. [William] came up with a clever solution to this problem, and while it doesn’t tell you exactly how much time is spent on a specific line of code, it’s still a good enough tool to be a great help in optimization.

[William]’s solution is to create a ‘bin’ for arbitrary chunks of code – one for each subroutine or deeply nested loop. When the profiler run, you end up with a histogram of how much time is spent per block of code. This is done with an interrupt that runs at about 1 kHz, with macros sprinkled around the code. Each time the interrupt ticks, the macro runs and increases a counter by one. Let the sketch run for a minute or so, and you get an idea of how much time is spent in a specific area of code.

It’s a bit of a kludge, but when you’re dealing with extremely minimal tools, any sort of help in debugging is sorely needed and greatly appreciated.

A serial monitor is an easy way to debug your projects. As we step through code, it’s nice to see a “Hey! I’m working, moving to next thing!” across the monitor, and not so nice to see nothing – the result of a bug that needs debugging. This has always meant needing a PC loaded with your favorite serial terminal program close at hand.

Most of the time this is not an issue, because the PC is used to compile the code and program the project at hand. But what if you’re in the field, with a mission of fixing a headless system, and in need a serial monitor? Why lug around your PC when you can make your own External Serial Monitor!

[ARPix] built this fully functional serial monitor based on an Atmega328 and a 102 x 64 LCD display. While it doesn’t have a keyboard port like this microcontroller based serial terminal, tact switches allow access to the user interface to start and stop the reading and set the baud rate. The Atmega328 has 2K of SRAM, which is needed for the project. Apparently, 1K was not enough to handle all the data. All code, schematics and a very well done parts layout are available, making this sure to be your next weekend project!

We’ve already seen an open source tool used to flash binary images to the TI ARM board. But that can’t be used with GDB. With the recent inclusion of USB-based ICDI in the OpenOCD development branches we gain all the features that come with the package. We’re quite happy hear about this as we use OpenOCD for many hardware architectures and this makes development for this board feel more like normal.

Our Stellaris Launchpad hasn’t just been sitting in the closet since we got it. We’ve learned a lot by using the lm4tools to program the chip as we work our way through the online workshop. We’re really beginning to like the Stellarisware peripheral library that has been provided. For us it works in a much more intuitive way than the one that STM uses with their ARM Discovery boards. We’d recommend taking a look at the workbook PDF (which is basically a verbose listing of what’s in the video series) and the library reference (called SW-DRL-UG-9453.pdf) which is in the docs folder of the Stellarisware package.

It looks as though Texas Instruments are really reaching out to the hacker community with their new ARM-powered Stellaris dev board. On the Stellarisiti forums, a member asked about the debugging options for the Stellaris board. The Stellaris already features an In-Circuit Debug Interface (ICDI), but unfortunately it’s a little hard to get working in Linux-ey environments.

Right now, OpenOCD support for the Stellaris is still incomplete, but there is an project up on the Gits that allows for multi-platform development for TI’s new board.

Needless to say, getting everything up and running is still a chore. That’s not really a concern, though; the Stellaris has only been around for a few months and it takes devs time to put all the required tools into nice, neat packages. We’re just glad TI is being so forthcoming with the relevant documentation, lest development becomes a million times harder.