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” 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!

Tags: , , , , , ,

8 Responses to “Notes to myself: Using EnergyMicro EFM32 with GCC open-source toolchain”

  1. Nice work.

    If you decide your time would be better spent developing your application instead of trying to put together a development environment, CodeSourcery (now Mentor Graphics) has already done the work for you and sells a complete development environment for embedded C/C++ development relatively inexpensively:

  2. Tim says:

    Apart from the path issues (which I expect are a temporary Eclipse Juno regression), most of the above stems from issues specific to the EFM32 example’s Makefile. I’m not sure how this tool would address them.

    Part of the beauty in sticking with FOSS tools is that if I publish a project built with these tools, anyone can freely replicate it, modify it, contribute back improvements, etc. Admittedly, porting between toolchains is not on the same scale as porting between target platforms, but it’s an entry barrier that can be easily avoided.

  3. Hi,

    Thanks for pointing out the issue with our Makefiles. We’re adding the strip directive to it, so others don’t end up doing the same work you did. The magic in the Makefiles is for automatically determining if Make is running on linux or windows and select the correct tooldir based on that. I think we need something else for non-default installs though.


  4. Tim says:

    @Marius: Thanks for looking into this! I don’t know if it’s due to your changes, but going through a couple of the application note examples (e.g. an0021_efm32_adc) downloaded yesterday went very smoothly – I didn’t have to do any Makefile monkeying beyond change the location of the tools (remove $(ProgramFiles) etc.) and update a few paths to reflect the chip family / devkit I was actually using.

    I’m currently beating my head against a fresh new wall (more on that later), but it’s not build- or makefile-related.

  5. Tim says:

    Again, mainly as a note to myself (and anyone else Googling the error message) for solving / working around debugger wonkiness:

    The “Verify failed” problem cited above, which spontaneously solved itself when I first was messing with this, spontaneously reappeared a couple days ago. But now, no amount of rebooting, plugcycling the dev kit, or varying the order of (plug devkit, start Eclipse, start gdbserver) makes any difference. The problem appears specific to the J-Link ‘gdbserver’ as other applications (e.g. Simplicity Studio -> Examples) can write to the device Flash without any problems. The version of the SEGGER tools installed by the Simplicity Studio installation (as of the date of the original post above) is “4.36e”.

    This is a rather old version. Unfortunately, installing the newest version (4.54a as of this writing) fixes the Flash write problem, but trades it for a new one: debugging crashes with the message:

    Target request failed: Could not fetch register “xPSR”; remote failure reply ‘E01’.

    with corresponding wall of log entries in J-Link GDB server:

    WARNING: Unsupported register (23)

    Unfortunately, I have found no published version that avoids both these problems (tested so far: 4.36e, 4.50m, 4.53e, 4.54a). A reply from an EFM32 tech support person mentions they are using 4.50l. Maybe I’ll try that in a bit.

    For now, using 4.50m still produces the identical errors (though fewer of them), but only in the console and not as a pop-up dialog box (wtf?!?! I don’t even want to know what internal voodoo makes this difference). Debugging seems to ‘work’ despite this, but I’m not sure how much I trust it yet.

    Sidenote: Starting a debug session with gdbserver 4.54a (Flash downloads verify OK, dies with the above-noted error), then quickly killing the gdbserver and switching to 4.36e, seems to “work” without errors, at least for a little while. Whatever changes exist between the two, the new version seems to “unlock” “something” relating to Flash writes on the chip, allowing the old version (with no “unsupported register” errors) to write to Flash. I can get this to work for a handful of debugger connect/disconnect cycles before the “Verify failed” issue comes back.

  6. Tim says:

    Aha! Solution (thanks Filip @ efm32 support!)

    “The issue you are experiencing is because gdbserver has an incorrect definition of the Cortex CPU registers. In the application note we have introduced the target-m3.xml file to fix this. However, this has since been fixed by segger in the newer versions. When using a newer version, you might have to remove this file again.”

    Short story: remove the ‘set tdesc filename target-m3.xml’ line from the gdb startup commands (Eclipse Debug Configurations -> Startup tab), and optionally delete the file. Now working for me without errors!

  7. kavi says:

    Currently I am breaking my head trying to solve the error “Type ‘uint32_t’ could not be resolved” in the blink example project. I am using Eclipse for the first time and I followed the steps as per the Application notes an0023. Initially I also encountered the Path not found issue but later i managed to solve it. But now I do not know how to remove this error. Help me!

  8. Douglas says:

    I found this especially helpful; it would be really nice if Energy Micro updated their AN0023 as it *does not work* with the “set tdesc filename target-m3.xml” (page 9) which is what I was using as a guide until I doing this site!!!

Leave a Reply