Posts: 19
Registered: ‎01-10-2016

EFM32 development/debug on Raspberry Pi

Greetings. I have a raspberry pi 3 (standard raspbian OS) in which it would be extremely useful to utilize as a development platform to be able to develop C code, cross-compile/build binaries, download, and debug on a EFM32 gecko microcontroller.


I was wondering if this is feasible, or if anyone has recommendations? I want it to be a standalone platform (for example: no remote terminaling into a more powerful Windows/Linux machine). It'd be very nice as well if I could use the established programming/debugging interface (SWD/ gecko eval kit set to debug out mode), but I am also willing to do custom bootloaders and such if necessary.


I don't suppose I can just install Simplicity Studio on the RP3? 

Posts: 2,736
Registered: ‎02-07-2002

Re: EFM32 development/debug on Raspberry Pi

You will not be able to run Simplicity Studio (AFAIK). You can see if you want to try Eclipse, but it might be too slow to work with on the RPi. Maybe another editor will work better, maybe Eclipse will be good enough. I suggest to try it out.


You should be able to install a GCC cross-compiling toolchain. If you're willing to use a Makefile you should certainly be able to build your project.


For downloading and debugging, I don't think an STK in debug out mode will work. But there is also OpenOCD which supports this. And on an RPi you can easily connect some of its pins to your target SWDIO & SWCLK and let OpenOCD use sysfs gpio to handle the SWD protocol.



Posts: 19
Registered: ‎01-10-2016

Re: EFM32 development/debug on Raspberry Pi

That sounds great. Thanks for pointing me towards a solution. I may come back with some questions as I experiment with this.

Posts: 19
Registered: ‎01-10-2016

Re: EFM32 development/debug on Raspberry Pi

I've been working on this in my spare time off and on for the last few months, and I have finally made a little bit of progress. I thought I'd share my findings in case anyone wants to do something similar:


Building GCC cross compiler: I originally tried downloading/building the official GNU ARM Embedded Toolchain for cortex-M  from The instructions were pretty straight forward, and it compiled the toolchain for like 8 hours (no exaggeration). Every time I tried it, however, it would fail in a different way (failing to build certain pieces of code, or telling me that perl or python wasn't installed, which it was). Someone online suggested I modify the memory allocation between CPU and GPU, concerned that the RPi3 was running out of memory. I tried this, but no luck. I tried to do a fresh OS reinstall, but it didn't help. I then went a different approach: ArmInArm. They have their own arm-toolchain-build-scripts and I noticed in the revision history that it mentioned updates specific to raspberry pi. I tried it, and it compiled (and took maybe an hour max)! I tried two things, and I'm not sure if one or both were required to make it work: Downloading the toolchain scripts, and downloading the ArmInArm software itself. When you run the ArmInArm software, there was a menu option saying "Install ARM Toolchain". I have no idea if this is exactly the same as the toolchain scripts, but some combination of these steps worked.


Makefile style project: I am no makefile/linker script savant, so I did this the cheater way: I just grabbed a simple project from simplicity studio on my Windows machine, copied it to the RPi3, and modified all the linker scripts to have the correct paths to the library locations. I believe I also just copied most of the required library source files from the simplicity studio folder on my Windows machine, as I wasn't quite sure how to download them directly.


So as of now, I am generating bin files from source code. The next step is to check out OpenOCD and try to program a gecko.

Posts: 19
Registered: ‎01-10-2016

Re: EFM32 development/debug on Raspberry Pi

It didn't take me very long to get openocd to program the gecko, because I shamelessly copied pieces of example configuration scattered throughout the web. Note that I tested this on a Raspberry pi zero instead of a raspberry pi 3. I believe a website mentioned that you would just use the string "raspberrypi2-native" instead of "raspberrypi-native" in the following cfg file. This was the openocd.cfg file I used:


source [find interface/raspberrypi-native.cfg]
transport select swd

bcm2835gpio_swd_nums 25 24
bcm2835gpio_srst_num 18

set CHIPNAME efm32
source [find target/efm32.cfg]

reset_config srst_nogate

adapter_nsrst_delay 100
adapter_nsrst_assert_width 100

reset halt
flash probe 0
flash write_image erase emptyProject.hex
sleep 1
reset run

then run the command 'sudo openocd' in the same directory as openocd.cfg. After that, my uC was programmed and LEDs were blinking. 


This was the wiring connection for the Raspberry Pi GPIO Header:


        3.3V  - 3.3V   - pin 1
	SWCLK - GPIO25 - pin 22
	SWDIO - GPIO24 - pin 18
	SRST  - GPIO18 - pin 12
	GND   - GND    - pin 14


 The next item for me to tackle is to use a debugger to step through code.

Posts: 19
Registered: ‎01-10-2016

Re: EFM32 development/debug on Raspberry Pi

I now have a rudimentary debugger running by the virtue of GDB/openOCD (in which everything was already setup, installed, and ready to go from my previous steps). I've never touched openOCD or GDB (not directly, anyway), so I was surprised at how quick I got these things working.


Here's how I did it:


1) Change the openocd.cfg file to end with "reset halt" instead of "reset run/shutdown"

2) start openOCD with 'sudo openocd'

3) in the directory containing your *.afx file (should be an output file in the same location as your build *.hex/*.bin), issue the command 'arm-none-eabi-gdb -ex "target remote localhost:3333" empty_project.axf -tui`


This should bring up a terminal based source code viewer and gdb console window.


4) break empty_project.c:main

5) continue

6) step ...


I'm no gdb expert, so I'm sure there's plenty left for me to figure out. On the other hand, I might do some digging to search for a higher level gdb wrapper which will bring me up to my normal "gui-style" debuggers: clicking things to set break points, F5,F10,F11, printf output window, variable watch window, etc.