Part 4: Mac OS + Eclipse + OpenOCD + STM32 (ARM Cortex M3)

Intro
I really wanted to program and debug ARM processors from my Mac. This series of entries is a work in progress as I fine tune my setup for regular use.  Be sure to read the full story:
Part 1: Getting Started, what we are going to do and what parts we are going to use.
Part 2: Laying the Foundation, getting all the parts installed.
Part 3: Connecting the Plumbing, hook up all the pieces and run it.
Part 4: Finishing Touches, troubleshooting and final thoughts.

Finishing Touches
I know that established, commercial software can often have more start-up issues than we care to deal with, especially when dealing with external development hardware.  My experience is that open-source, home-grown, multiple-author, work-on-it-in-my-spare-time, no-warranty-expressed-or-implied solutions are even more difficult.  I hope to someday build an Eclipse plug-in automate all of the things so my company can use a low maintenance open toolchain, but it's not going to happen right now!  Instead, I will show you the troubles that I've seen and the solutions that worked for me.  Deal?  Deal.

OpenOCD External Tool Troubleshooting
Installing OpenOCD
I don't have any comments on installing OpenOCD since the MacPorts installation works so well.

External Tool Configuration Reminders
This setup is pretty easy from the Eclipse perspective since only one tab in the External Tools Configuration screen needs to be populated.  Just be sure that your Location path is absolute and correct for your machine.  Same goes for the paths used in Arguments fields.  If you aren't using an Olimex ARM-USB-TINY-H JTAG or STM32 then be warned that you may need different flags on Arguments command, and that you will need to find the necessary .cfg files for your setup.

Target Connection Errors
A common thing that I ran into initially was not having my target connected and/or powered so OpenOCD couldn't connect.  When running the OpenOCD External Tool from Eclipse I would get error messages in the Eclipse Console that looked like this:

Open On-Chip Debugger 0.4.0 (2011-07-22-14:08)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
1000 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Command handler execution failed
Warn : jtag initialization failed; try 'jtag init' again.
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
error: -100
Command handler execution failed

With a properly connected target you should see something less scary like:

Open On-Chip Debugger 0.4.0 (2011-07-22-14:08)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
1000 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1) 

You might also see this displayed when starting OpenOCD:

Error: JTAG-DP_STICKY_ERROR

This doesn't happen all the time, or very often at all, for me, but I have seen it, and it makes it impossible to start debugging when it does happen.  I found a page at TinCanTools that said it is related to an OpenOCD 0.4.0 bug and it can be fixed by simply relaunching OpenOCD (the method I stumbled on) or by changing the OpenOCD launch arguments from:

-f /opt/local/share/openocd/scripts/interface/olimex-arm-usb-tiny-h.cfg -f /opt/local/share/openocd/scripts/target/stm32.cfg -c "init" -c "reset"

to:

-f /opt/local/share/openocd/scripts/interface/olimex-arm-usb-tiny-h.cfg -f /opt/local/share/openocd/scripts/target/stm32.cfg -c "init" -c "reset init" 

I did that and it worked, but then I switched back to the original to test the theory and it still worked.  YMMV.

Debugger Troubleshooting
No source available for ""
This being displayed in the source file area of the Debug Perspective happens for any number of reasons, but its always when something prevented the program download or run from happening properly.  Go through your Console output and look for "Error:" messages.

Error: couldn't open test_rom.hex
This is thrown when the debugger can find your binary file (obviously).  One reason is because you haven't build your program yet, or you did but then you cleaned the project before running the debugger.  Another reason is that in your debugger configuration has the wrong path to your binary file in the "'Run' commands" section of the "Commands" tab.  Your run command should look like the block below, but you need to edit it to reflect the correct relative path to your binary output file.  The location is dependent on your project directory structure and the name of your output files which are dependent on what you called them and if your are compiling for Flash or RAM.  Notice that the "symbol-file" path doesn't require the same path information.  Why? I don't know right now. The two paths I'm talking about are in bold:

monitor soft_reset_halt
monitor wait_halt
monitor poll
monitor flash probe 0
monitor stm32x mass_erase 0
monitor flash write_bank 0 STM32Test2/test_rom.hex 0
monitor soft_reset_halt
symbol-file test_rom.elf
thbreak main
continue

Conclusion
This was fun and I hope you were able to use it for your own work.  Looking back it took quite a long time to figure out and a surprising amount of time to write about...there's a lot to do!  All of this stuff certainly helps you appreciate the simplicity of IAR Embedded Workbench for ARM.

In the future I want to show you how to use IAR sample projects in our new toolchain, and I want to develop a quick-install method or plug-in of some kind to automate all of this work, as well as make it easy to change JTAG and target processor types.  Should be fun!  Please feel free to put questions/corrections/etc in the comments and I'll try to reply quickly.