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.
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 ?
@rev Hey Paul, let's just hope that whoever wrote those docs is just an IAR fan and the code works with gcc as well.
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
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.
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?
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!
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.
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.)
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?
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.
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.
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...
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:
c:/siliconlabs/simplicitystudio/v3/developer/toolchains/gnu_arm/4.8_2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: cannot find -lemdrv
c:/siliconlabs/simplicitystudio/v3/developer/toolchains/gnu_arm/4.8_2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: cannot find -lemlib
c:/siliconlabs/simplicitystudio/v3/developer/toolchains/gnu_arm/4.8_2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: cannot find -lwstk
c:/siliconlabs/simplicitystudio/v3/developer/toolchains/gnu_arm/4.8_2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: cannot find -lble_stack
c:/siliconlabs/simplicitystudio/v3/developer/toolchains/gnu_arm/4.8_2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: cannot find -llinklayer
c:/siliconlabs/simplicitystudio/v3/developer/toolchains/gnu_arm/4.8_2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: cannot find -lradio
Anyway the path is configured ("-L"C:/SiliconLabs/BluetoothSmartSDK/188.8.131.52-GA//modules/lib/"), but I didn't find the libs...
Last Post was not right:
I find the libs in the folder but the links doesn't find it...