Debugging ARM Cortex M3 LM3S811 evaluation board on Eclipse with GNU ARM tools

The title is quite a mouthful, but I wanted to record what it takes to get debugging working in the Eclipse IDE for the ARM Cortex M3, specifically the Luminary Micro LM3S811 evaluation board.

Unfortunately, the state of Cortex M3/LM3S811 support by OpenOCD is not yet at the point where it is smooth. I think the underlying problem is that resetting the LM3S811 is not happening as expected.

  1. Go to the YAGARTO website and download/install the components. Note that the website itself states that YAGARTO does not support cortex m3 yet, we are using this site to get most of the other components, including Eclipse and the Zylin CDT extension.
  2. Go to the CodeSourcery website and download the Lite (free) version of their GCC compiler (EABI platform). It is a set of command line tools, but we will be integrating them into Eclipse.
  3. Go to this site and get the “software-package Version 20080409”. This is the version of OpenOCD that actually works for the LM3S811. The OpenOCD version on the YAGARTO site, although newer, did not work in the following steps. This site is actually very informative and remains the best site for Cortex M3/GNU ARM toolchain info. Unfortunately, it does not talk about Eclipse integration.
  4. Configuring Eclipse is complicated by the fact that several sources of information (YAGARTO, etc.) all say slightly different things. I will eventually list out the exact steps, but for the most part follow the HOWTO’s on the YAGARTO site.
  5. […more to follow on Eclipse configuration…]
  6. I am assuming at this step you can successfully program the main.bin file. The debug step is a bit more complicated, as it is a two part process
    • Run OpenOCD from the External Tools menu, using the .cfg script that is specifically for debugging (as opposed to programming.
    • Run GDB from the Debug menu. Note this was the most confusing part.
      1. Create a configuration under the “Zylin Embedded debug (Native)” option.
        • Main Tab: The C/C++ Application is the main.bin file that was created (from an .elf file) from the build process using a Makefile.
        • Debugger Tab: Browse for the CodeSourcery GDB file. The default location is C:\Program Files\CodeSourcery\Sourcery G++ Lite\bin\arm-none-eabi-gdb.exe
        • Commands Tab: Here is the key part. Use the following commands, taken from a variety of sources. Again, since resets don’t work properly for the LM3S811, most lines other than the first and last are useless. Note the symbol-file command should be to the .elf file, not the .bin or .sym file.
          • Initialize: target remote localhost:3333
            monitor reset
            monitor sleep 500
            monitor soft_reset_halt
            symbol-file “C:\\PATH\\main.elf”
          • Run: hbreak main.c:38
        • What is going on in the hbreak command is that a hardware breakpoint is being set at a particular line number in main.c. Hardware because software breakpoints don’t seem to work on embedded targets (I could be wrong here). This ugly manual setting is because the reset/halt/init mechanism doesnt work, so without manually setting a break point “Debugging” programs actually lets the program run without stopping.
        • Note this means you need a separate Debug configuration for every subproject/program. This is definitely a pain, but as far as I know the only way you can start debugging at an arbitrary point in the source code. Note that single stepping works well, if slowly.

BTW, the errors involved in resetting and halting the LM3S811 are shown below


Open On-Chip Debugger 1.0 (2008-04-09-14:00) svn:
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
Error: jtag.c:927 jtag_add_reset(): BUG: transition of req_tlr_or_trst and req_srst in the same jtag_add_reset() call is undefined
Warning: jtag.c:1197 jtag_check_value(): value captured during scan didn't pass the requested check: captured: 0x0f check_value: 0x01 check_mask: 0x0f
Warning: jtag.c:1157 jtag_read_buffer(): in_handler reported a failed check
Error: jtag.c:927 jtag_add_reset(): BUG: transition of req_tlr_or_trst and req_srst in the same jtag_add_reset() call is undefined
Warning: jtag.c:1197 jtag_check_value(): value captured during scan didn't pass the requested check: captured: 0x0f check_value: 0x01 check_mask: 0x0f
Warning: jtag.c:1157 jtag_read_buffer(): in_handler reported a failed check
User: target.c:382 target_process_reset(): Timed out waiting for halt after reset

1 Comment

  1. jeff Said,

    May 18, 2009 @ 8:33 pm

    I know this is an old post, but I was wondering if you had any plans to update this with complete info. thanks