Debugging The Stellaris With OpenOCD

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.

19 thoughts on “Debugging The Stellaris With OpenOCD

  1. I wish people would stop releasing shit without proper dev backup for the masses. This is what makes the Arduino win, they could’ve released the DUE last year, but noooo, they perfected it first.

    Now all this needs is some OpenRitalin.

    1. The way open source tends to work is that people release shit and other people join the effort to make the shit less shitty in their opinion.

      I wish people would help make lots of shit less shitty.

      stevo, come join the effort and work on the “dev backup for the masses”, whatever that means. :)

      Yes, the JTAG/SWD USB interface on the launchpad uses the GDB protocol mostly verbatim, but of course with some tweaks.

      The USB interface uses the vendor specific device class, thanks to inspiration of brilliance by TI engineers.

      And for Windows users: The TI Stellaris Launchpad ICDI USB driver package installs the Microsoft WinUSB kernel driver, meaning that software such as OpenOCD and lm4flash which uses libusb-1.0 works out of the box on Windows, in parallell with the TI programs, without dealing with kernel drivers at all. Very well done, TI! I’ve put an lm4flash Windows binary at (32-bit, built with mingw, statically linked with libusb-1.0 git code. It has been tested and is confirmed to be working.)

      1. I should say that the FOSS community has responded very fast – it has only been 3 weeks since I got the board and yesterday, I was able to dump Windows and get my board working in a 100% GNU/Linux environment!

    1. The stub seems relatively complete with one notable exception — ^C isn’t handled so there’s no way to interrupt a running process. The following work

      — load, step, read variables/registers (didn’t test write), disassemble.

      I’m not too sure breakpoints work, but I’ve only tried on a blinking lights demo which is pretty spartan

  2. I’m really interested in stellaris launchpad. i want to learn more from ARM microprocessors and it’s great to see TI’s commitment to create a rich platform. I know how to program MSP430 and if it is at least half as easy to program the stellaris launchpad compared to MSP, i think getting started with this board will be pretty easy

  3. A GDB stub over a USB bulk interface? Strange… :P

    But at least it’s relatively uncluttered, runs on the same chip, and even has a command for some DFU mode. This could be interesting.

    At least it’s 100 times better similar cheap on-board debug solutions I have seen

    1. Putting a gdb stub in the debugger interface makes perfect sense, but there’s really no justification for bulk usb — better that it looked like a virtual comm port. Speed isn’t really an issue — the performance limiter is ultimately flash speed.

      I just wish the other vendors would see the light and use the remote gdb protocol.

      Glad to see there’s already activity on fixing the flaws in the released (sample) code.

      1. Using the vendor specific class 0xff is actually an excellent choice, since it allows trivial programming from userspace in a reliable, unified, cross-platform way, and it requires no kernel drivers beyond those created by Microsoft. In the future there is even some hope for Windows users to have real plug and play with the device, if Microsoft decides to push out a Windows Update to add the WinUSB driver class to the registry so that devices with Microsoft-specific USB descriptors can automatically bind to WinUSB also on Windows systems older than Windows 8. Let’s see how that goes.

        Since the GDB protocol implemented by the firmware isn’t completely standard it would only cause problems to use a CDC ACM USB interface class, and anyway that device class is (as you may know) specifically for AT-command modems, and certainly not a generic serial port device class, even if many believe so, and even if many devices abuse it for that purpose.

        Of course it’s sad that USB is yet again reduced to simply be a byte stream transport, and that the structured communication it offers isn’t taken full advantage of, but at least there’s no stupid, over-priced, FTDI chip. Baby steps. :)

    2. Note that the ICDI is actually running on a separate LM4F chip. The Stellaris Launchpad has two of them, one implements the ICDI, the other is the target device. You could of course cut the board in half, and have *two* LM4F120 development boards for the price of one, but you’d have zero debuggers then. :)

      1. That was the idea. Since it’s running on the same type of chip it might be possible to use the DFU mode to upload a better firmware to it.

        I’m still in the process of getting a USB stack created, but I guess someone with better USB skills than me shouldn’t have many problems creating a bulk interface that simply passes a simple set of, perhaps FTDI MPSSE-like, commands to the SWD pins.

        That should make creating an OOCD adapter type a breeze, right?

      2. Yes, I expect that the debugger chip can be reprogrammed via DFU. Keep in mind that you only have one try to get it right though, or you will need another debugger chip to resurrect. Would need two boards for development.

        There is a USB stack included in the StellarisWare package, but it unfortunately does not have the BSD license like the rest of StellarisWare. Sad face. I suppose that TI bought all the IP from someone and can’t relicense it.

        Do not mimic the FTDI crap whatever you do. Do something better instead. I would suggest to port the Black Magic code, which also implements a GDB server in firmware, and has a fairly well abstracted SWD-on-GPIO-in-CortexM3-implementation.

        The key is to move the lowest level ADIv5 transport out of the PC since it does not belong there under any circumstances. It needs to run close to the target.

        OpenOCD is not equivalent to stupid FTDI interfaces, they are just common and simple for people to clone^Wcreate, and using FTDI chips allows people to avoid learning anything about USB, so of course they are very popular.

        OpenOCD actually supports a couple of more clever interfaces already, one of them is the Versaloon open source hardware+firmware+software, and another is the closed STLinkv2. Besides ongoing work to support the TI ICDI firmware.

  4. Well, I reflashed the stlink on some of my discovery boards with blackmagic. If there is interest, I can export my changes at github. At some point, blackmagic for the stellatis launchpad might be an option…

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.