- 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
02-23-2016 06:25 PM - last edited on 08-09-2016 03:10 AM by Siliconlabs
Why does every EFR32 document start with asking me to install IAR? Could the default, gcc-based toolchain not produce code that is suitable for the EFR32? If possible, I'd very much prefer to use gcc.
02-24-2016 02:38 AM
Hi Timur, it appears that IAR is the only compiler that can be used for C programming.
Now if thats the case that is not good news.
Maybe someone from silabs can clarify ?
02-24-2016 03:35 AM
My thoughts are that it is only available for IAR at the moment but will be available for gcc.
Unless silabs is going to give us free unlimited licences for IAR.....dont think so
Lets see what happens
02-24-2016 07:03 AM
IAR is only needed for the BLE stack we have on the EFR32.
The GCC support is on the roadmap.
If you need BLE support on EFR one free option is the BGScript.
02-25-2016 09:12 AM
I find this to be a particularly good question.
We were evaluating the 8051-based BLE113 module just last year and I understood why I had to buy an IAR compiler license for that ancient processor...nobody else supported it. So we bit the bullet, bought that (IMO, horrible) IAR workbench software from the 90s and moved on.
But when I saw that the BGM111 module was ARM-based, I got all excited. Finally! We can use gcc under Eclipse and life will be great again.
Sadly, that's not the case. As the OP stated, every document I open starts with "Install IAR EWARM 7.30". Why!? The gcc compiler has perfectly good ARM support. So I don't understand the reasoning yet.
Also, it's great that gcc support is on the roadmap, but where? Are we talking a short drive around the corner or are we talking a trek across the US? What kind roadmap are we looking at here?
02-25-2016 10:15 AM
Okay, so I've experimented a little bit. I don't have my WSTK with me now, so I'm not actually sure if this method could produce code that actually runs on the EFR32 or not, but here it goes:
The BLE stack has 6 closed binaries: ble_stack.a, emdrv.a, emlib.a, linklayer.a, radio.a, wstk.a and accompanying header files. What each blob does exactly is documented in an accompanying pdf file. Examining these .a files with readelf tells me that they use the ARM EABI, so there is a chance that GCC might understand them as well.
Trying to use this .a files with GCC produces some cool error messages, but the only real issue here is that ble_stack.a contains symbols that collide with those of the startup files (startup_efr32devicename.S and system_efr32devicename.c). Let's examine ble_stack.a with our trusty friend ar:
ar t ble_stack.a
Which gives us the shocking result that somebody mistakenly complied the startup files of the EFR32MG1P device into ble_stack.a, because it contains a system_efr32mg1p.o and a startup_efr32mg1p.o file. At this point I'm not sure how this could work with any compiler, since it surely contains symbols that collide with the startup file of the device.
Let's get rid of the offending files, note that this will modify the ble_stack.a file, fixing the mistake of bundling the startup files in it!
ar d ble_stack.a system_efr32mg1p.o ar d ble_stack.a startup_efr32mg1p.o
After doing this, GCC doesn't have any complaints linking all six static libraries of the BLE stack to a simple "hello world" style application.
Unfortunately I can't test right now whether or not the code that I can produce this way actually runs on the device, because I'll only get my WSTK back next week. Until then, hope this helps!
02-25-2016 10:26 AM
Very interesting. I have only just opened my first project in simplicity, so I haven't had time to dig all that deeply yet. I do recall one of the main hurdles in linking the BLE libraries for the BLE113 module with anything other than IAR had to do with some proprietary formatting that only IAR supported. If that's not the case here, then that's intriguing to say the least. Like you, I'm not sure what that means just yet, though. Could it be that those startup routines included in the BLE library do something "special" with the SoC to enable some stuff that the standard routines do not (I'm thinking license checks here to enable functionality in the rest of the library, for example)? No way to know without testing.
Regardless, given the project I'm working on, we will likely hold out for official gcc support which, according to the response I got from support, is slated sometime this summer-ish. Until then...do we buy an IAR license or do we stick with BLE113 for now...that's the big question for us.
02-25-2016 10:34 AM
I believe IAR also has a 30-day free license. So that may be an option. (Or take a look at the CC2640 which documentedly supports GCC, I'm not sure if I'm allowed to say that on this forum.)
03-01-2016 03:44 AM
I'm starting from scratch with Blue Gecko Dev-Kit WSTK and I also want to use *only* GCC for compile applications for the SoC (using the BLE_stack). I do not install or buy the IAR workbench. I figured out the I can you the AppBuilder in Simplicity Studio to generate project file based on example (i tried smartPhone-example). My toolchain is set "unspecified" at first, but when the project is generated, I can change the Toolchain in "Project" --> "Build Configurations" --> "Manage" and choose "New" to configure the GNU ARM toolchain and set to "active". So good until this point, now the problem:
The project starts to compile and misses all the "gattdb_*" - Symbols. The "gatt_db.c" and ".h" are empty. May suppose is that the toolchain doesn't generate the "gattdb_*"- symbols from the XML-Gatt-profile-file (i.e. "ble_soc_cattdb.bgproj") as it should maybe there is a special pre-processing command to do that which is set normally when you use IAR Workbench. Anyway the description in "UG126.pdf" says it will "gererated". But anyway it should be possible in GNU ARM makefile, too. Probably it's not a big deal...
Does anyone has experiances how to generate "gatt_cb.c" and ".h" from ".bgproj"-File?
03-01-2016 03:49 AM
Hi Mario, as stated at the moment you cannot use GCC.
Maybe download the IAR eval version if you want to try it.
Other option is to wait for silabs to add the gcc support.
03-01-2016 06:49 AM
Read AN975. It talks about IAR but has some useful information. It talks about the "bgbuild" tool which can generate those files for you. It's located at:
It can turn a .bgproj file into those .c and .h files.
03-01-2016 07:51 AM
thanks for the advice with AN975. I figured out to generate the gattdb_*.*-Files. But anyway the project is not really "generated" and there are several further still missing dependencies (i.e. " ubt/bg_gattdb_def.h") which are not really generated from the AppBuilder in the Project tree if I don't have IAR....
Hopefully GCC-Support will come soon...
03-01-2016 08:10 AM
I figured out the problem with missing "ubt/bg_gattdb_def.h.". The problem was a different location of the file in the SDK so I changed to "bg_gattdb_def.h" and it compiles without a problem...
Now I hang on the linker:
Anyway the path is configured ("-L"C:/SiliconLabs/BluetoothSmartSDK/188.8.131.52-GA//
03-01-2016 09:09 AM
The solution for the linker problem is easy:
Go to your linker settings:
- Right-click the project
- C/C++ Build
- GNU ARM C Linker
Add the location of the .a files to Library search path (-L)
Then, add the libraries (-l), prefixed with a colon (
03-01-2016 10:11 AM
I followed your instruction and now the linker recognizes the libs, great!!
But now it also generates new error messages... (see image)
My suppose is the the libs are compiled with IAR compiler, right? so maybe I have to first figure out how to compile the libs with GNU Toolchain probably...
03-02-2016 02:22 AM
At this point I'm not entirely sure what the problem is, but I suggest that you try the thing I suggested in a previous post of mine (removing the startup and system object files from ble_stack.a using ar, but also make sure you keep a backup of the original ble_stack.a), and then include the startup and system files in the project that are meant for GCC.
03-02-2016 11:24 AM
At the end of the day there are still two functions that ble_stack calls which are called __iar_vla_alloc2 and __iar_vla_dealloc2. These have to do with IAR's VLA (variable-length array) implementation and are not documented (at least google doesn't find anything useful).
So it seems that we are stuck, unless someone can dig up some information about how these functions should be implemented.
03-08-2016 01:16 AM
Anyway it's a good exercise to figure out a workaround for IAR, but in time is running so finally I got a license for IAR. Now everything compiles...
Thanks Timur for help! Anyway hopefully GNU GCC support will come soon...
Next part is to understand the ble_stack-API.
09-01-2016 07:04 AM
Hi, it's been a while now since this thread started and summer should just about be over for the US now, so how is the progress on GCC going? Do we have a date yet?
We're using Nordic chips until Silabs decide to give gcc support.
There are tools for that and we don't want to change until they make it easy for us.
We've done quite a number of BLE projects on Nordic since the blue gecko came out.
We do a lot of other stuff with EFM's and EZR's but can't convince them to change until the tools are ready to go in SStudio with GCC.
Silabs is missing opportunities here, tick-tock.
09-19-2016 08:30 AM
The same for my company. We're evaluating both tghe Nordic and the Blue Gecko device family to become our next low-end platform for various projects we intend do be doing in the next couple of years, but using IAR is probably a no-go.
09-22-2016 12:08 PM
Hey, that's great. Have the instructions for command-line building been posted yet? I haven't seen them on the forum. I'm currently trying to get at least SOMETHING to build because our IAR trial license just expired. I have significant experience both building with the GNU toolchain by hand and manipulating Eclipse environments, but the generation process from the .isc file is a bit of a mystery to me.
09-27-2016 05:21 AM
GCC example for our BLE stack was just released as knowledgebase article, see following link:
09-27-2016 03:01 PM
I have tested this on Linux Mint 17.3 and it works fine!
Then I have tried configuring the empty_ble example to compile from Simplicity IDE.
I had to add include directories containing missing .h files (C/C++ General > Paths and Symbols > Includes > GNU C):
I had to add Symbols (C/C++ General > Paths and Symbols > Symbols > GNU C):
I had to add Other objects to Linker (C/C++ Build > Settings > GNU ARM C Linker > Miscelaneous)
I had to deselect No startup or default libs (-nostdlib) checkbox in C/C++ Build > Settings > GNU ARM C Linker > General so that linker stopped complaining about missing _start symbol.
Then I just had to provide an empty main() function and the build was successful. I'm still not sure if this produces a runnable code, some compiler and linker settings might be suboptimal. Will try to build a more real example tomorrow.
11-17-2016 04:48 PM
I also had some luck with getting the same project to work (Win7) , but when it tries to assemble, I get this
Problem Event Name: APPCRASH
Application Name: as.exe
Application Version: 0.0.0.0
Application Timestamp: 57e95fd0
Fault Module Name: as.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 57e95fd0
Exception Code: c00000fd
Exception Offset: 0002f049
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 0c9b
Additional Information 2: 0c9b4cfad3e83f2687d35bcb9ca3c38b
Additional Information 3: 34b6
Additional Information 4: 34b6eed33f0d3ff727324b9da6887c36
Happens when the startup file "startup_efr32bg1b.S" is included in the project
01-30-2017 04:45 PM
Hi, I tried your suggestions, and added some missing files from "emlib", but I still get these errors from the linker:
Description Resource Path Location Type
make: *** [soc-ibeacon_2.axf] Error 1 soc-ibeacon_2
undefined reference to `gecko_cmd_msg' soc-ibeacon_2 line 2687, external location: /Applications/SimplicityStudio.app/Contents/Eclips
undefined reference to `gecko_handle_command' soc-ibeacon_2 line 2631, external location: /Applications/SimplicityStudio.app/Contents/Eclips
undefined reference to `gecko_handle_command' soc-ibeacon_2 line 2687, external location: /Applications/SimplicityStudio.app/Contents/Eclips
undefined reference to `gecko_handle_command' soc-ibeacon_2 line 2718, external location: /Applications/SimplicityStudio.app/Contents/Eclips
undefined reference to `gecko_handle_command' soc-ibeacon_2 line 2755, external location: /Applications/Simplicity Studio.app/Contents/Eclipse/developer/stacks/ble/v
undefined reference to `gecko_init' main.c /soc-ibeacon_2 line 180
undefined reference to `gecko_wait_event' main.c /soc-ibeacon_2 line 186