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.
One of the devs for the Open On-Chip Debugger was already talking with TI to get the ICDI spec released for the Stellaris board. TI released the info, and after quite a bit of work, everything is open for all to see.
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.
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”
This is a simple iOS debugging tool that will take no time to solder together. There’s even a chance that you already have everything you need on hand. The hack simply connects an RS232-to-USB converter to a breakout board for an iPod connector.
The hardware is aimed not at stock iOS systems, but as an aid to those who wish to run alternative operating systems on them. When the OpeniBoot package is run on an iPod Touch or iPhone it enables a serial terminal on pins 12 and 13. The FTDI breakout board takes these as RX and TX and makes them available to your terminal program of choice via USB. Speaking of USB, you may already have noticed the black cable leaving the right side of the image. Using the terminal doesn’t limit your ability to use the device’s USB functions.
The Bus Pirate is a fantastic development tool. It does an amazing job at a lot of different things. And as it has matured, community support has driven it to new areas beyond the original design. This is where its hardware holds back performance a little bit. For instance, as an I2C or SPI sniffer it has limited capture speed. That’s the type of thing that this board could improve upon. It’s a debugging tool based on an STM32 F4 microcontroller. That’s an ARM Cortex-M4 chip which runs at 168 MHz, and has 192 KB of SRAM.
[TitanMKD] has been working on the design but it is still just in digital form. Since there’s no prototype there is also no firmware for the device. That’s a tall mountain to climb and it’s one of the reasons we’re featuring the project now. [Titan’s] plan is to model this after the Bus Pirate interface. We think it’s a good idea since a lot of folks have already learned the syntax. We didn’t see a contact form on his site, but if you’re interested in contributing to the project you might want to leave a comment here or on his project page (linked above).
First off, if you’re looking at that title and thinking it’s flame-bait, please hold off. What [Ihsan Kehribar] is working with is another way to get some feedback for what’s going on with your Arduino project. Or really any AVR project that uses an ISP connection. He’s added text output for AVR programs similar to the printf function used for a lot of non-embedded C development.
So, we’d bet you’re asking yourself why he’s not just using outright debugging? The AVR line supports many different types of it. But that can be complicated, and usually requires a proper programmer. If you just want to watch to see what values are changing, and when functions are being executed, this isn’t a bad solution. He uses the computer to continually poll the chip. Whenever the sketch calls the his print library it answers back with the payload to be displayed in the terminal. The overhead shouldn’t be too high, and if you’re smart about it this can be flagged as a debug option at the top of the program file.
If you are in the market for a PIC microcontroller programmer, you may want to consider a model with an In-Circuit Debugger (ICD). [Rajendra] put together a great tutorial on using an ICD when debugging PIC firmware, which makes a pretty convincing argument for owning one.
In his tutorial, he happens to be using a MikroElektronika PICflash2, but he says that there are plenty of other ICDs out there if you are not keen on this particular model. The PICflash2 not only acts as an ICD, but as the name suggests it works as an ICSP as well.
[Rajendra] walks us through a short debugging session using some simple code that reads data from an LM34DZ temperature sensor, displaying the results on an LCD screen. While he isn’t actually hunting for bugs, he does show how easy it is to step through the PIC’s code one statement at a time, evaluating variables and registers along the way.
[Rajendra] does point out that using an ICD does occupy a few I/O pins while running, limiting your resources just a bit. We think that being able to debug code as it runs is pretty reasonable tradeoff if you don’t necessarily need each and every pin available for use.
If you haven’t done any debugging with microcontroller programs [Kphlight] posted a follow-along guide for debugging MSP430 chips. You can see above that he’s using the TI Launchpad and has chosen the free (but code limited) IAR Embedded Workbench that is one of the IDE’s that TI provides for the kit. The example builds a Pomodoro timer with just five LEDs and one resistor. You’ll flash the code to the chip, step through each line of the firmware, and learn how to manipulate register data during code execution.
It’s a great primer for the uninitiated, and we’d love to see one using open-source tools like DDD and GDB. If you do write one, don’t forget to send us a tip about it. If you want to give open source a try with this hardware check out our own tutorial.