Archive for ARM

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

Comments (1)

Luminary Micro Lm3S811 ARM Cortex Microcontroller

I think I have finally settled down on the embedded system that will be used for the robotics course. At the sensor processing/integration level, the PSOC CY8C29466, either with the evaluation board that Cypress sells, or my own custom board. At the machine learning/interface to MS Robotics Studio level, the Luminary Micro LM3S811 ARM Cortex M-3 Microcontroller, with their evaluation board.

I am still debating whether to move to C compiler for the PSOC (up to now I have been teaching the M8C assembly language). With the addition of the LM3S811, with its own set of (free) C compiler tools, I am tempted to standardize on C for both microcontrollers. On the other hand, teaching assembly language is worthwhile I believe, for future roboticists.

 My first step is to get the two microcontrollers talking to teach other, most likely using I2C. Will post more once that is accomplished.

Comments off

Robotics Makeover

This year I am revamping both web development and robotics courses I teach during the summer.

  • Web Development
    • Up until now I have been using Plone/Zope/Python for both the course website and teaching web development. Lately though I have been examining Visual Web Developer, ASP.Net, and C#. While I think Plone/Zope has its advantages, clearly ASP.Net is more popular, and its feature set (especially with 3.5) is getting to be pretty comprehensive. What has finally convinced me to migrate is the fact that ASP.Net pages can now be written in IronPython, the .Net implementation of CPython.
    • IIS seems to have its issues, however, so I am looking into reverse proxies that will hide IIS and Plone/Zope behind it.
  • Robotics
    • I have been using Parallax BASIC Stamps, Sumobots, and Cypress Semiconductor PSOCs. While the Sumobot is a very nice hobby robot, the computational power of the BASIC Stamp that is at its core leaves a lot to be desired.
    • Microsoft has the Robotics Studio, a .Net platform for robotics work. It has gained sufficient support that I think it is a viable platform on which to teach my course. It requires an interface on the robot that is too much for the Sumobot (although there is sample code for the BOEBot, which is similar). I have been looking at the ARM series of microcontrollers for some time now, and have decided to have a hybrid solution, where a PSOC handles all the low-level sensor/motor interfaces, and the new ARM Cortex M3 handles the AI/machine learning as well as the interface to the Robotics Studio.
    • I purchased the Olimex STM32-P103 prototyping board, based on the ST STM32F103RBT6 Cortex 32-bit microcontroller. It has the following features, from the Olimex website.
    • ARM 32 bit CORTEX M3â„¢ with 128K Bytes Program Flash, 20K Bytes RAM, USB, CAN, x2 I2C, x2 ADC 12 bit, x3 UART, x2 SPI, x3 TIMERS, up to 72Mhz operation.
    • I think I have gotten spoiled by the rich set of peripherals available on the PSOC, because while the set of peripherals the Cortex has is reasonable, by itself it will not be able to manage all the sensors and hardware of a robot.
    • I am thinking of using a new chassis for the robots, I need to do a full engineering preliminary design before I can commit to that course of action.

After much reading and searching I have finally managed to burn, run and debug a sample LED blinking program on the STM32-P103. The beauty of open source development tools is obviously the cost and the frequent updates, but the disadvantage is the lack of good documentation or manual. I have been able to piece together bits and pieces through a lot of trial and error, and will be posting everything I have learned so far soon, with sample code.

Comments off

PSOC and ARMs

It would not come as much of a shock to most if I said engineers in general get comfortable with particular tools of the trade (microcontrollers, languages, chips, etc.) and resist change as much as possible. This is not without some good reason, as all the time spent getting familiar with the published and unpublished “features” of a particular system are sunk costs that precludes one from examining more than a few alternatives.

 I am like this, and my comfort zone currently in terms of embedded systems is the Cypress PSOC. I like its design tools (PSOC Designer, not the PSOC Express), like the analog/digital blocks that can be reconfigured, and even the much maligned M8C core. (Its assembly instruction set is very similar to my all-time favorite, the 6502)

 However, even Cypress has realized that the M8C 8 bit core is a little underpowered. Apparently they have been designing the next generation (PSOC3) chip that utilizes an ARM Cortex M3 core, (and another version with an 8051 core). I’ve heard good things about the ARM series, but since they were 16/32 bit systems with a huge development suite, I resisted. Not to mention the cost of a beginning development board/system was much higher than for the PSOC.

With Cypress’s move to the ARM architecture, however, I have decided to sit down and learn more about ARMs. PSOC3’s haven’t come out yet, but I am thinking of getting an ARM SAM7 board from my favorite PCB fab company, Olimex. The SAM7-EX256 board looks pretty feature-full, and it even includes a color LCD to boot (this year’s mobile robotics course has taught me the necessity of having an LCD for debugging purposes).

The price is a bit steep ($199) but I think well worth it. Fortunately, there is an open source development suite, the WinARM that includes gcc, Eclipse, and a gdb/insight based debugger. All in all a “professional” development environment. I don’t have enough time to learn yet another assembly language, so being able to use a (free) C compiler is practically a requirement.

More on my ARM adventures once I get the board.

Comments off