This is an old revision of the document!

ARM devboard debugging

ARM devboard debugging
founder: abyssal
depends on:
interested: -
software license: -
hardware license: -
status: active


This project is originally aimed at debugging Stellaris Launchpad board (ARM Cortex M4F), but can be applied to ARM-related and OpenOCD-supported devices as well.

OpenOCD debugger + Qt Creator

OpenOCD is on-chip-debugger project that allows one to debug code with a GDB-machine-interface frontend - like command-line GDB itself, Qt Creator or Eclipse.

Compilation for Stellaris Launchpad, required version of openocd 0.7.0-r1 (TI link for reference):

./configure --enable-maintainer-mode --enable-stlink --enable-ti-icdi

Add the usual “–prefix” before “make” and “make install”, just keep it somewhere in $PATH.

Connecting OpenOCD to Qt Creator

In one terminal, connect to on-chip-debugger (modify the path for configuration file depending on where you installed OpenOCD):

openocd --file ~/sat/share/openocd/scripts/board/ek-lm4f120xl.cfg

Now, from running Qt Creator, select from main menu Debug-Start Debugging-Attach To Remote Debug Server. Make sure to fill out Debugger to arm-none-eabi-gdb pointing to your toolchain's GDB debugger. Local executable should point at compiled ELF executable. Host:port combo will default to localhost:3333.

Select Window-Views-Debugger Log.

Write three commads to the debugger log (this could be likely automated using the startup script option):

monitor reset halt
monitor reset init

The monitor reset halt will halt execution, the load command will load your ELF binary, monitor reset init will restore program to beginning. Resume execution (F5 key by default) to run the program. You can e.g. set breakpoints now or pause execution:

Breakpoints and stepping

Breakpoints should work as usual, just don't forget “-g” flag and use no optimization “-O0” with gcc CFLAGS (last -ON flag “wins”).

Caveats - SIGTRAP, long "step over" delay

If you are getting “SIGTRAP” shown from Qt Creator, delete old breakpoints and restart the program anew - reset or physically disconnect Stellaris Launchpad.

If “step over” is taking way too long (tens of seconds or minutes), it may mean that you've tried to step over a cycle or an expanded macro. Temporary breakpoint is much faster. Nevertheless, you may watch console output of openocd to see that the program is actually running, showing the PC register and waiting the breakpoint to hit.

Hard fault interrupt encountered, possibly due to optimization (FaultISR)

This section briefly covers how to find out why your code ended in FaultISR - which is usually the default fault handler set in StellarisWare projects. Follow Diagnosing Software Faults in Stellaris Microcontrollers.

Example showing Imprecise bus fault

How to trigger an IMPRE fault (imprecise bus error) we'll show as an example. Look at blinky.c from StellarisWare, there is a “seemingly unnecessary line” with assignment to the ulLoop variable in the main() method:

// Enable the GPIO port that is used for the on-board LED.

// Do a dummy read to insert a few cycles after enabling the peripheral.
ulLoop = SYSCTL_RCGC2_R; // <--- !!! if commented out, may cause imprecise bus error with gcc's -O2 optimization !!!

// Enable the GPIO pin for the LED (PF3).  Set the direction as output, and
// enable the GPIO pin for digital function.

Try commenting out the line with assignment to ulLoop, compile with -O2 -g (e.g. add CFLAGSgcc=-O2 -g) to Makefile. If you used the same toolchain (linked above as “recommended toolchain”), nothing will blink. When you attach using OpenOCD, you'll see that you've ended up in FaultISR.

Getting code completion working for StellarisWare, DriverLib, UsbLib

Easiest way is to have StellarisWare open as project. From File-New File or Project, select Import existing project, then select StellarisWare directory. In the second step where the dialog asks you to check subdirectories to import, it's enough to select just driverlib', inc, usblib and utils.

The other option would be adding path to the relevant include files (see Project tab). You might have to explicitly define some of the make macros like -DTARGET_IS_BLIZZARD_RA1 under the Project tab to get ROM_ and MAP_ prefixed functions to resolve correctly, but it was not necessary in my case.

Stellaris Launchpad as simple logic analyzer

Given the clock speed of Stellaris Launchpad, it's fairly fast enough for snapping signals. With a bit of proper synchronization, can be used as a logic analyzer with short memory (alternatively direct download link for the tar.gz). In the comments towards the end, there is a version that uses more than 16 kB RAM, meaning longer time interval can be sampled.

The code turns Stellaris into SUMP-protocol compatible device, you can use OLS Logic Sniffer client to read from it. Any time a GPIO value on PORTB[0..7] changes, the capture starts. Note: PB0 and PB1 are limited to 3.6 V! All other pins of PORTB are 5 V tolerant.

First flash the sllogiclogger.bin image onto Stellaris you'll use for measurement. Then copy over the config file ols.profile-SLLogicLogger.cfg from sllogiclogger tarball to ols- directory (or whatever your version of OLS is).

Sample showing sllogiclogger for debugging ATSHA204 single-wire communication. One Stellaris controls the ATSHA204, the other Stellaris serves as sllogiclogger. PB6 and PB7 are used to read from, as the OLS screen shows.

You might want to change the line ols.profile-SLLogicLogger.cfg containing device.samplerates to make your measurement more precise. Since sllogiclogger uses raw for() cycle without interrupts and DMA, the actual sampling frequency highly depends on compiler and flags used when you compile the sllogiclogger.

For instance, I didn't need 10 MHz, I was okay with 1 MHz but longer captute. So after some measurements I've found out that using 1236000 Hz for device.samplerates and changing sllogiclogger.c divider SYSCTL_SYSDIV_27 in ROM_SysCtlClockSet call, it measures fairly accurately when it's compiled with -O2 flag with the recommended toolchain mentioned above.

Though for any more serious work, it's best to use a real logic analyzer, like Open Bench Logic Sniffer.

Open Bench Logic Sniffer with OLS client

First of all, it is absolely substantial to flash both FPGA and PIC firmware of Open Bench sniffer to make it work reliably with OLS client - see updates. Otherwise the triggers may not work reliably. Note that the flashing new FPGA/PIC firmware may not work the first time, try multiple attempts (also, Linux OLS updater depends on old libusb shared libraries). Links for quickstart and using triggers:

Udev rules file for fast copy-pasta (last line should sidestep potential issues with modem-manager):

#File /etc/udev/rules.d/55-ols.rules
#Rules for Open Bench Logic Sniffer
# Creates nice /dev/OpenLogicSniffer symlink writable even for users not part of dialout group
ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fc92", MODE="0666", SYMLINK+="OpenLogicSniffer"
ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fc92", ENV{ID_MM_DEVICE_IGNORE}="1"

PureJavacomm exceptions on Linux kernel 3.7+ for non-root users

If you are unable to capture data under non-root user despite having correctly set udev rules, you'll need PureJavacomm update. The exception message is:

java.lang.IllegalStateException: JTermios call returned -1 at class jtermios.JTermios JTermiosLogging line 489

Symptoms detailed:

Quick fix:

The fix for PureJavacomm is described in issues #133 and #159. Snapshot for OLS 0.9.7 contains the fix:

Sample photo: Open Bench Logic Sniffer debugging ATSHA204 on Stellaris Launchpad

Here is Open Bench Logic Sniffer showing communication from ATSHA204. Note that channel 0 contains different single-wire (not 1-wire!) communication for RX and TX separately as specified by ATSHA204 docs (203.4 and 166.6 kbaud). OLS screenshot comes from OLS 0.9.7 development snapshot.

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki