Execution Tracing on Cortex-M3 Microcontrollers

The higher-power ARM micros have a bunch of debugging tools for program and data tracing, as you would expect. This feature – CoreSight Trace Macrocells – is also found in the lowly ARM Cortex M3 microcontroller. The Cortex M3 is finding its way into a lot of projects, and [Petteri] wondered why these debugging tools weren’t seen often enough. Was it a question of a lack of tools, or a lack of documentation? It doesn’t really matter now, as he figured out how to do it with a cheap logic analyzer and some decoders for the trace signals.

There are two trace blocks in most of the Cortex M3 chips: the ITM and ETM. The Instrumentation Trace Macrocell is the higher level of the two, tracing watchpoints, and interrupts. The Embedded Trace Macrocell shows every single instruction executed in the CPU.  Both of these can be read with a cheap FX2-based logic analyzer that can be found through the usual outlets for about $10. The problem then becomes software, for which [Petteri] wrote a few decoders.

To demonstrate the debugging capability, [Petteri] tracked down a bug in his CNC controller of choice, the Smoothieboard. Every once in a great while, the machine would miss a step. With the help of the trace tool and by underclocking the micro, [Petteri] found the bug in the form of a rounding error of the extruder. Now that he knows what the bug is, he can figure out a way to fix it. He hasn’t figured that out yet. Still, knowing what to fix is invaluable and something that couldn’t be found with the normal set of tools.

Turn your BeagleBoneBlack in to a 14-channel, 100Msps Logic Analyzer

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.

Continue reading “Turn your BeagleBoneBlack in to a 14-channel, 100Msps Logic Analyzer”

Scripting Debug Sessions: Python for GDB Remote Serial Protocol

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”

Proper Debugging for Energia Sketches

Moving a sketch from Energia to Code Composer Studio

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.

[Thanks to Adrian for the tip!]

Continue reading “Proper Debugging for Energia Sketches”

Profiling An Arduino


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.



Serial Monitor Without a PC


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!




How to build OpenOCD with Stellaris Launchpad support

The stable version of OpenOCD (an open source On-Chip Debugging software package) doesn’t have support for the ICDI protocol used by the Stellaris Launchpad board. But it is pretty easy to build your own OpenOCD from source after patching it to use the protocol.

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.

[via Dangerous Protoypes]