- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
12-05-2016 08:49 AM - last edited on 07-25-2017 11:49 AM by Siliconlabs
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?
12-05-2016 10:47 AM
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.
03-04-2017 12:57 PM
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 launchpad.net. 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.
03-05-2017 03:06 PM
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 init targets reset reset halt poll flash probe 0 flash write_image erase emptyProject.hex sleep 1 reset run shutdown
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.
03-08-2017 08:21 PM
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
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.