Tuesday, September 6, 2011

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 TroubleshootingInstalling 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:

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:

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

Debugger TroubleshootingNo 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:

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.

4 comments:

Thats a very helpful post. Thank you :)I'm a graduate student at UC Boulder. I came across this post while looking for a head start with learning ARM development. I had a few questions, is there a way I can contact you? It would be very helpful to me.Thanks again.

About Me

I'm a Christian, husband, electrical engineer, Mac guy, dirt bike freak, dog owner, and photographer. One of my classic statements about any given project is "I could have done this in high school if I spent enough time reading (and hacking)." Sometime in the last couple years I realized that this really is true, but I'd have to spend about 10 years reading and hacking to do it. Oh, wait, that's what I did.

Over those 10 years of reading and hacking I've been listed as co-inventor on 10+ patents; architected new embedded communication and data encoding schemes; taken multiple PCB projects from napkin sketches to preproduction shipments including power, high voltage, analog, and digital circuitry; designed, wrote, and sell software for automated industrial machines; published an iPhone app; and hacked Apple mobile device hardware and software.

I publish these articles because I fully agree with Brett Victor's Method of Learning infographic. I may be an average engineer, but I'm an above average internet searcher, if nothing else. With this in mind I'm starting to understand that if it took me hours/days/weeks of research to learn then there are many people out there who could save hours/days/weeks because of some of these articles.