Notes to myself: Using EnergyMicro EFM32 with GCC open-source toolchain

The EFMs can be used with many different toolchains after installing EnergyMicro’s “Simplicity Studio” package, which includes board/chip support packages and some code examples.

EnergyMicro’s application note AN0023 has an overall good overview of setting up an Eclipse + GCC (CodeSourcery) toolchain. Nevertheless, in attempting to replicate this process on my Win7 system (work PC; not my first choice of OS) I ran into a few particular time-wasting issues. The appnote recommends to find and install specific (“old” / current at the time of writing) versions and see it work, then take the risk of updating versions – I just installed the current version of everything (including Eclipse). This might be part of my problems. Installing toolchain components to a slightly unexpected location (i.e. not on the C:\ drive, let alone “C:\progra~1”) may add a bit of uncertainty too.

Some quick notes / “problemlet” observations:
The Simplicity Studio code examples install to one of your OS/version-specific “home” folders, regardless of where you told it to install the application proper. On Win7 there are many variations of a “home” folder; they get installed to the Windows “%appdata%” path (which expands to something like C:\Users\yourname\AppData\Roaming). Assuming you’ve performed the necessary voodoo to bring back some kind of ‘Run’ dialog / command line in Win7, you should be able to type %appdata% at the prompt and thereby obtain the actual path it expands to on your flavor.

During installation of Simplicity Studio you are prompted to install the SEGGER J-Link (JTAG / debug client emulator) drivers. In my case, I was prompted to install them about 30 times (wtf?). After the first installation appeared to succeed, I canceled out of the numerous repeat prompts (holding down ESC key works well for this) without any apparent ill effects.

Otherwise, installation and setup of Simplicity, Eclipse and the various other bits went pretty smoothly, up until…

Problem #1: Broken handling of PATH in Eclipse (Juno)
Attempting to build the ‘blink’ example, eclipse barfs out the following error:
program “cs-make” not found in path
So, dig down to Windows Environment Variables, confirm the path to the build tools has been correctly added…sure enough, there it is. Open a command prompt (defaults to C:\Users\myusername) and type cs-make … Windows can find it too, apparently. Just for fun, copy the CodeSourcery build tools’ path from the system path variable to the *user* path variable, close and re-open Eclipse… same problem. Finally, digging deep in the Eclipse build setup (Project -> Settings -> C/C++ Build -> Environment and manually adding the $path$ variable to the Eclipse-specific environment variables shows that it appears to have taken the “user” environment path, and injected several Java-related paths, apparently overwriting the first several path entries (including the one for the build tools). Manually adding the OS-provided “path” variable here (it expands to a plain text string once added) and hand-adding the build tool path (in my case, “d:\CodeSourcery\Sourcery_CodeBench_Lite_for_ARM_EABI\bin”) is ugly, but it works and I don’t have a better idea.

Problem #2: Install Path Assumptions; Wide Open Spaces
As mentioned earlier, I installed Eclipse and the build tools to my dedicated non-installed-by-the-IT-department-by-default apps partition, D:\. Apparently that is a minor nono – the Makefiles in the Simplicity Studio examples have a hard-coded expectation that you installed everything in “C:\Program Files\” (or your OS-flavor equivalent). After hacking around in the blink example’s makefile a bit to remove all traces of this assumption, I ran into the 2nd problem:

cs-make: *** [build/system_efm32lg.o] Error 1

This incredibly helpful error message from cs-make means that a failure occurred in some upstream tool. Clicking on the ‘Console’ tab at the bottom of the Eclipse window discloses the actual problem:

11:37:58 **** Build of configuration Default for project blink ****
cs-make all
“Building file: ../../../../../Device/EnergyMicro/EFM32LG/Source/system_efm32lg.c”
“D:/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI /bin/arm-none-eabi-gcc”
(…etc, etc…)
The system cannot find the path specified.
cs-make: *** [build/system_efm32lg.o] Error 1

Note the two, yes two, superfluous and unwanted spaces in the middle of the GCC path string, between “Sourcery_CodeBench_Lite_for_ARM_EABI” and “/bin/arm-none-eabi-gcc”. I have absolutely no idea where those are coming from (they aren’t in any of the strings used to build this path string in the Makefile), or whether this is a specific bug of cs-make, Windows ports of make, or make in general. Lacking any kind of better idea, I “solved” this by wrapping every possible piece of data that may be used to generate a path with the makefile ‘strip’ directive (discovered via yet more googling in circles, yay), e.g. a string definition blah becomes $(strip blah), and $(QUOTE)$(TOOLDIR)/bin/arm-none-eabi-gcc$(QUOTE) becomes $(QUOTE)$(strip $(TOOLDIR))$(strip /bin/arm-none-eabi-gcc)$(QUOTE), etc. Note that it appears any piece of string variable which has already been ‘strip’ped must again be re-‘strip’ped when using it to build another string (e.g. in the above, I’ve already defined TOOLDIR = $(strip $(WINDOWSCS)) , and WINDOWSCS = $(strip D:/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI) , to no apparent effect.

Once every susceptible substring in the Makefile has been flushed out and dealt with (this may take a few builds), eclipse builds the project without failures and produces a .bin file. Whee!

Now, the next step is to actually download this fresh new executable to the target board and run it. As I understand it, this requires cooperation of several tools. GDB (GNU Debugger) is used to (besides debug) interact with the vendor-specific JTAG device and actually burn code onto a device. There is also some sort of TCP/IP loopback server (gdbproxy? J-Link apparently performs this function) in the mix somehow.

Aside: This is where everything seemed to sh*t the bed when I tried to set up a similar Eclipse+GCC toolchain for msp430 microcontrollers – building went smoothly, but the whole matryoshka of uneasy agreements between gdb, gdbproxy, and the proprietary binary-blob (.dll) JTAG tool could only be jostled into working occasionally, with a lot of gdb-related process-killing and potentially rebooting between build attempts.

Sure enough, the next problem occurs here.

‘Launching blink Default’ encountered a problem

Error creating session
Cannot run program “arm-none-eabi-gdb”: Launching failed
Cannot run program “arm-none-eabi-gdb”: Launching failed
Cannot run program “arm-none-eabi-gdb”: Launching failed

As a quick sanity-check, typing arm-none-eabi-gdb at a command prompt successfully launches GDB, so this is probably more Eclipse-specific path BS. Since I don’t have infinite time to burn on this, another hacky ‘solution’: manually ‘Browse’-ing to and thus hardcoding the path to arm-none-eabi-gdb in Eclipse’s debug configuration dialog, under (green ‘bug’ button dropdown arrow) -> Debug Configurations -> Debugger. This done, launching debug dumps a healthy amount of gibberish (raw GDB commands and responses) to the console, along with several errors/warnings from gdb and several inexplicable red lines of text (that do not, outwardly, appear to be error messages, but rather echoes of send commands), but the gdb stream seems to suggest that bytes were successfully pushed to the dev board.

Success! I think. I guess. Maybe.
Switching over to the “Segger J-Link GDB Server” program (remember, the appnote says to start this before Eclipse and leave it running) shows GDB “Connected to 127.0.0.1” along with another green mark, which it did not before. Good sign, I suppose.

…OK, maybe not. Attempting to set a breakpoint and run the application does nothing. Attempting to restart the “Debug” process from the beginning just causes Eclipse to hang. With some dicking about (close Eclipse, manually kill all *gdb processes in Windows task manager, restart) I can get as far as “Starting target CPU…” and “4 KB downloaded” appearing in J-Link, but no apparent activity on the target board. But, uploading the freshly built ‘blink.bin’ binary using the ‘energyAware Commander’ DOES work! So, at least the compiler / build environment is sane. Something is going wonky between Eclipse/J-Link/GDB/board. If “Show log window” and “Verify download” are enabled in J-Link GDB Server, download lines have “Verify failed” after them.

After a reboot and starting over with the recommended versions of Eclipse (2.7.3 / Indigo) and its plugins… it works! Then switching back to the current version… it works! It is possible the PC and/or board were just in a wonky state and fixed by a good old-fashioned powercycle. Aaaanyway, downloading code to the development board thru Eclipse seems to be OK now.

Last little niggles:

• Upon starting a debug session, a large page shows up with the following in bright red scary text: No source available for “__cs3_interrupt_vector_em() “. This is not any kind of error message, really. It just means that the interrupt vector table(?) (which it wants to show you for some reason) has no source code available to show you. (You are instead given the option to view an assembler dump.)
• The “EmbSys Registers” tab shown in the appnote screen shots does not appear. Solution: This tab is not enabled by default – enable it using Window->Show View->Other->Debug->EmbSys Registers

. Once this is done, the tab will appear with a note to set your chip. Now go into Window -> Preferences -> C/C++ -> Debug -> EmbSys Register Viewer and select the appropriate architecture/vendor/chip. For the EFM32LG-STK3600 (Leopard Gecko Starter Kit), this is ARM3, EnergyMicro, and EFM32LG990F256, respectively. Close out of there and the EmbSys tab should contain a list of viewable registers in a folder hierarchy by association (e.g. those associated with the ADC, WDT, etc.).

• Unresolvable symbol errors: On my setup, several error messages appear under “problems” when debugging is started: “Symbol ‘cmuClock_CORE’ could not be resolved” and “Type ‘uint32_t’ could not be resolved”, for example. They don’t seem to be hurting anything (and I have not found/ looked for any fix for this), but I’d bet real money that this is a stupid paths problem again.

Well, Future Tim, there you have it. Working EFM32 debugging on an open-source toolchain!