The basic GCC example worked well on Windows 7 x64. The following links may be helpful for installing Cygwin and GCC.
NOTE: Did not need to perform step 3 (Download, Build and Install the Latest GCC)
For everyone's information: this also works on MAC OS.
Just extract the zip to /Applications/Simplicity Studio.app/Contents/Eclipse/developer/stacks/ble/v220.127.116.11/app/bluetooth_2.0, then open the terminal and navigate to /Applications/Simplicity Studio.app/Contents/Eclipse/developer/stacks/ble/v18.104.22.168/app/bluetooth_2.0/GCC/Example/gcc and run 'make' twice. The second run will generate a *.bin file which you can load using SS Flash Programmer.
I got it to build and MOSTLY run on the EFR32 Blue Gecko starter kit (SLWSTK6020A), which has a EFR32BG1P instead of an EFR32BG1B. Distressingly, there are two serious problems:
- stack.a in the BLE stack lib directory is not a static library (per the name), but an object file. It took me a while to figure out why I could look at it with nm and objdump, but not ar.
- There are several device-specific object files linked in which I had to remove with objcopy; I stripped EMU*, CMU*, INT* and System* and added the device-appropriate emlib files to my project to replace them. Without this step, the init routines would bug out because the struct sizes for the EFR32BG1B appear to be larger, and they live at the top of the stack, so it immediately tried to access out-of-bounds memory.
So I have something that compiles and runs. Unfortunately, something seems wrong with the stack; the gecko_evt_system_boot_id message never seems to get received after init. It seems like something is wrong with the gecko_wait_event() function, because the assembly it steps into is garbage for what it should be doing:
000071dc: strb r1,[r0,#0x1c]
000071de: movs r1,#0x0
000071e0: str r1,[r0]
000071e2: bx lr
I'll keep hacking on it. It's progress, anyway!
Oh, I see. stack.a is just a pile of addresses that point to absolute locations in binstack.o and the like, and I wasn't using the included linker script which kept binstack and binbootloader in the correct locations. What a mess. This isn't a great way to provide a library, for what it's worth. I know you want to strip the symbol names, but must be better ways of doing that.
Well, I get an executable that's much closer to the right size when I add the binstack and binbootloader sections into the linker script appropriate for my part. However, I get the feeling that the bootloader may not be 100% compatible with my part, since it never seems to make it to main(). I haven't bothered stepping through to see where it's getting hung up, though it doesn't appear to be getting stuck on a HardFault or anything of the like. Is there a reason the bootloader is necessary? I rather like to see how my chip is getting initialized.