ryankurte / efm32-base Goto Github PK

The above error occurs with all of the chips that I've tested. The full output is included below.

yay@proton:~/efm32-base/build$ make
Scanning dependencies of target device
[ 1%] Building ASM object device/CMakeFiles/device.dir/EFR32MG22/Source/GCC/startup_efr32mg22.S.obj
[ 3%] Building C object device/CMakeFiles/device.dir/EFR32MG22/Source/system_efr32mg22.c.obj
arm-none-eabi-gcc: fatal error: cannot read spec file 'nano.specs': No such file or directory
compilation terminated.
make[2]: *** [device/CMakeFiles/device.dir/build.make:89: device/CMakeFiles/device.dir/EFR32MG22/Source/system_efr32mg22.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:495: device/CMakeFiles/device.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

Hello guys, i tried to update to 5.13.X by myself and kinda run into problems linking bluetooth enabled projects.

I've uploaded the whole SDK with my changes to my repo and would like to contribute at least to updates of the sdk. I also would appriciate some help fixing the CMake files, especially the bluetooth part if this is possible.

Within the repo a simple "soc-empty" project from the SDK is included to try and test the compilation.

When using the default source file provided, only modified to use a different port/pin for the LED on this chipset and to have the printf + stdio removed, results in the device catching in the default handler (efm32-base/device/EFM32ZG/Source/GCC/startup_efm32zg.S:267) and hanging. This was tested on a custom board running a EFM32ZG108F8 MCU. Monitor reset halt does not work just traps in the handler, running a jump using the reset handler results in the same behavior. Please find attached the output if make VERBOSE=1 as well as the very basic modifications I made to this source file just in case I introduced the problem.
make.txt

main.c.txt

Hello Ryan,

I'm trying to print a simple %f in sprintf, but %f is yielding an empty string for %f:
sprintf(s, "test: %f", 1.234);
This line sets s to "test: " but %f is unpopulated.

Thinking it was a problem with printf, I found a function that uses math functions like log10(), pow(), and exp() from here: https://stackoverflow.com/a/7097567/14055985

but then I got linker errors:

CMakeFiles/space-ham.dir/main.c.obj: In function `dtoa':
/home/zeke/src/space-ham/main.c:104: undefined reference to `log10'
/home/zeke/src/space-ham/main.c:114: undefined reference to `pow'
/home/zeke/src/space-ham/main.c:125: undefined reference to `pow'
/home/zeke/src/space-ham/main.c:129: undefined reference to `floor'

I know I need to add "-lm" to the linker line so I updated my CMAKE_EXE_LINKER_FLAGS as follows (note the -lm at the end):
set(CMAKE_EXE_LINKER_FLAGS "${COMMON_DEFINITIONS} -Xlinker -T${LINKER_SCRIPT} -Wl,-Map=${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_PROJECT_NAME}.map -Wl,--gc-sections -Wl,-v -lm")
but that didn't change the undefined reference problem. Where should I add the -lm ?

If I copy/paste the super-long GCC command line generated by cmake that is displayed to the screen upon error, and add -lm to the output, then I get this:

opt/gcc-arm-none-eabi-7-2018-q2-update/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v8-m.main/fpv5-sp/hard/libm.a(lib_a-w_log10.o): 
In function `log10':
w_log10.c:(.text.log10+0xbe): undefined reference to `__errno'
w_log10.c:(.text.log10+0xc8): undefined reference to `__errno'
w_log10.c:(.text.log10+0xda): undefined reference to `__errno'

While I will eventually need math functions, the current issue is just getting sprintf() to format strings with floats. Is there a way to fix this without switching to some external 3rd-party stdio/stdlib/math library?

Thanks for your help!

-Eric

In preparation for submitting a PR for bluetooth support I'd like to refactor the directory structure of sdk components into a single subdirectory. There's a couple of reasons for this.

1. The directory names are different e.g. cmsis vs CMSIS
2. It better supports a copy script that we could make to easily update the sdk sources for future sdk releases (assuming SILabs doesn't do any major refactoring). For the last PR I was doing this manually which kind of sucked.

I have the bluetooth/rail sample working, but I need to clean some things up before submitting that PR. Here's the branch that has all the current changes I'm proposing.

andrew@mega:~/work/efm32-base$ tree -L 2 sdk
sdk
├── app
│   └── bluetooth
├── hardware
│   ├── CMakeLists.txt
│   ├── kit
│   └── module
├── platform
│   ├── base
│   ├── bootloader
│   ├── CMSIS
│   ├── Device
│   ├── emdrv
│   ├── emlib
│   ├── halconfig
│   ├── hwconf_data
│   ├── micrium_os
│   ├── middleware
│   ├── radio
│   └── release-highlights.txt
└── protocol
    ├── bluetooth
    └── flex

I'm working on integrating a BGM13P22F512GA device (BGM13P22 Blue Gecko Module Radio Board BRD4306A) and I'm running into an issue regarding the linker script. Well probably more than just the linker script. There are different linker scripts depending on the device and I didn't want to duplicate the entire BGM13P directory just to change the linker script.

Do you have any suggestions for the best approach here or am I missing something?
I'm also wondering about the sdk/hardware subdirectory. Is the intent of this repository to just support chips and not modules or kits?

Hello
I am looking for a software engineer to complete a Zigbee 3.0 home automation sensor project using the EFR32MG22 device. I note that you have experience with the SiLabs devices and wondered if you would be interested in quoting for this project.
David

This is a question. I'm using the project as a submodule (so I don't want to alter any files from it).

I'd like to define some symbols (-DARM_MATH_CM4=1) and flags (-mfpu=fpv4-sp-d16 -mfloat-abi=hard) that are used by the MCU SDK (e.g. in CMSIS) to enable use of the FPU unit found in some boards. How can I pass them to both my project's source files and the MCU SDK?

I'm currently using cmake -DCMAKE_BUILD_TYPE=Release -DOPTIONAL_DEBUG_SYMBOLS="-DARM_MATH_CM4=1 -mfpu=fpv4-sp-d16 -mfloat-abi=hard" .. and it seems to be working, but I don't think OPTIONAL_DEBUG_SYMBOLS from toolchain/efm32-base.cmake is meant to be used for these purposes.

Hello Ryan,

I'm having trouble getting simple LED blink tests to work in the EFR32MG21. I have your test main.c blink working using portB, but only sometimes because I think the bootloader is jumping to somewhere in memory that happens to work if I get lucky, but it isn't consistent when I change a line of code so it hardfaults. Please correct me if I'm wrong on my assumptions below, this is based on what I've scraped together from PDFs online:

The series2 devices jump to flash at 0x00000000 to start the application and it looks like efm32-base starts with the vector table at 0x4000.

From here: https://www.yic-electronics.nz/datasheet/a0/EFR32MG12P132F512GM68-CR.pdf?page=6

On newer devices (EFR32xG12 and later), the bootloader resides in the bootloader area in the Information Block
• Application @ 0x0
• First stage bootloader @ 0x0FE10000
• Main bootloader @ 0x0FE10800

Note that we are using the G21 not the G12, but I'm guessing the bootloader process is the same---or at least I've not yet found anything to the contrary.

Currently my _mainCRTStartup is at 0x4174, though t may change with global values and such. The vector table points the reset at 0x4ddd, shortly after which it jumps to 4174.

How can I write a preamble that starts at 0x0 to jump to 0x4174---or better yet, have the preamble read 0x4004 which is the reset PC location and jump there, which is 4ddd in this example?

Thank you for your help!

-Eric

Hi Ryan,

It looks like BLE_LIB is only defined once and never referenced:

efm32-base]$ git grep -i BLE_LIB
CMakeLists.txt:    # set(BLE_LIB EFR32BG13P)

Is it used? If so, how?

We're going to play with BLE so if you have any pointers or know of other projects that have used BLE with efm32-base then it would be nice to have a look.

This is the efm32-base project we have been working on and here is a presentation about it, if you're curious.

-Eric

Thank you for writing the efm32-base package! We are trying to build on centos and silabs' studio is only targeted at ubuntu.

It looks like the hardware/kit/common/bsp/bsp.h from the SDK is not included in your efm32-base project. Is this generic enough to include? It would enable building samples like this one: https://github.com/SiliconLabs/peripheral_examples/blob/master/series2/gpio/gpio_conf/src/main_gpio_conf_s2.c

The 5.1.2 version of bsp.h is here, do you have easy access to the 5.8 version?

https://github.com/SiliconLabs/Gecko_SDK/blob/v5.1.2/hardware/kit/common/bsp/bsp.h

-Eric

What would one have to do to add additional chipset support? If we can document the process I can start adding support for the various EFR32 chipsets for the BLE support.

The variable FLASH_START set in efm32-base.cmake is only used in flash.in to flash the binary image to the MCU using the JLink programmer. But the application is always linked with the Silicon Labs provided linker script for the device, which sets start of flash to 0x0. Right now I'm manually modifying the linker script to set my own memory addresses, which gets overwritten every time the build files are generated. Would there be an easy way of defining flash and ram addresses and sizes somewhere in the cmake files, so that these override the default values from the linker scripts?

I tried using this to work with a EFM32G890F128 but for all other chips it will simply say

efm32-base/device/EFM32G/Source/system_efm32g.c:34:23: fatal error: em_device.h: No such file or directory
 #include "em_device.h"
                       ^
compilation terminated.

This will happen for all chips besides the EFM32GG990F1024, The instructions say you just have to change the device name, is this a bug or is there a missing step? Seems like the probelm is in the device/device.cmake on how it includes other family header files.

I seem to be having some problems getting the sample blinky program to run on this board I created a new repo and added efm32-base as the submodule, copied the CMakeList file and updated it to use the EFM32HG322F64 device and updated it to point to the new efm32-base location. I copied over the source directory and only modified the macros to look like:

#ifndef LED_PIN
#define LED_PIN     4
#endif
#ifndef LED_PORT
#define LED_PORT    gpioPortF
#endif

which should be the EFM32HG kits correct port and pin for one of the two led's. I then created a build directory ran cmake .. followed by make and make flash (using the Jlink configuration) and it uploads to the board; the problem is however is the board will not blink the light as expected.
Cmake:

➜  build git:(master) ✗ cmake ..
CMake Deprecation Warning at /usr/share/cmake-3.7/Modules/CMakeForceCompiler.cmake:69 (message):
  The CMAKE_FORCE_C_COMPILER macro is deprecated.  Instead just set
  CMAKE_C_COMPILER and allow CMake to identify the compiler.
Call Stack (most recent call first):
  efm32-base/toolchain/arm-gcc.cmake:15 (CMAKE_FORCE_C_COMPILER)
  CMakeLists.txt:20 (include)


CMake Deprecation Warning at /usr/share/cmake-3.7/Modules/CMakeForceCompiler.cmake:83 (message):
  The CMAKE_FORCE_CXX_COMPILER macro is deprecated.  Instead just set
  CMAKE_CXX_COMPILER and allow CMake to identify the compiler.
Call Stack (most recent call first):
  efm32-base/toolchain/arm-gcc.cmake:16 (CMAKE_FORCE_CXX_COMPILER)
  CMakeLists.txt:20 (include)


-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/arm-none-eabi-g++
Device: EFM32HG322F64
Processor: EFM32HG322F64
Family: EFM32HG
No FLASH_START defined. Using default: 0x00000000
-- Configuring done
-- Generating done
-- Build files have been written to: /home/brandon/workspace/temp_tracker/build

make:

➜  build git:(master) ✗ make
Scanning dependencies of target emlib
[  2%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_acmp.c.obj
[  4%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_adc.c.obj
[  7%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_aes.c.obj
[  9%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_assert.c.obj
[ 11%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_burtc.c.obj
[ 14%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_cmu.c.obj
[ 16%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_crc.c.obj
[ 19%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_cryotimer.c.obj
[ 21%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_crypto.c.obj
[ 23%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_dac.c.obj
[ 26%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_dbg.c.obj
[ 28%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_dma.c.obj
[ 30%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_ebi.c.obj
[ 33%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_emu.c.obj
[ 35%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_gpio.c.obj
[ 38%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_i2c.c.obj
[ 40%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_idac.c.obj
[ 42%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_int.c.obj
[ 45%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_lcd.c.obj
[ 47%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_ldma.c.obj
[ 50%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_lesense.c.obj
[ 52%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_letimer.c.obj
[ 54%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_leuart.c.obj
[ 57%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_mpu.c.obj
[ 59%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_msc.c.obj
[ 61%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_opamp.c.obj
[ 64%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_pcnt.c.obj
[ 66%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_prs.c.obj
[ 69%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_rmu.c.obj
[ 71%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_rtc.c.obj
[ 73%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_rtcc.c.obj
[ 76%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_system.c.obj
[ 78%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_timer.c.obj
[ 80%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_usart.c.obj
[ 83%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_vcmp.c.obj
[ 85%] Building C object CMakeFiles/emlib.dir/efm32-base/emlib/src/em_wdog.c.obj
[ 88%] Linking C static library libemlib.a
[ 88%] Built target emlib
Scanning dependencies of target device
[ 90%] Building ASM object CMakeFiles/device.dir/efm32-base/device/EFM32HG/Source/GCC/startup_efm32hg.S.obj
[ 92%] Building C object CMakeFiles/device.dir/efm32-base/device/EFM32HG/Source/system_efm32hg.c.obj
[ 95%] Linking C static library libdevice.a
[ 95%] Built target device
Scanning dependencies of target temp_tracker
[ 97%] Building C object CMakeFiles/temp_tracker.dir/source/main.c.obj
[100%] Linking C executable temp_tracker
collect2 version 5.4.1 20160919
/usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/bin/ld -plugin /usr/lib/gcc/arm-none-eabi/5.4.1/liblto_plugin.so -plugin-opt=/usr/lib/gcc/arm-none-eabi/5.4.1/lto-wrapper -plugin-opt=-fresolution=/tmp/cc2w5dHs.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lg_nano -plugin-opt=-pass-through=-lc_nano -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc_nano -X -o temp_tracker /usr/lib/gcc/arm-none-eabi/5.4.1/armv7-m/crti.o /usr/lib/gcc/arm-none-eabi/5.4.1/armv7-m/crtbegin.o /usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/lib/armv7-m/crt0.o -L/usr/lib/gcc/arm-none-eabi/5.4.1/armv7-m -L/usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/lib/armv7-m -L/usr/lib/gcc/arm-none-eabi/5.4.1 -L/usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/lib -T/home/brandon/workspace/temp_tracker/build/efm32hg.ld -Map=temp_tracker.map --gc-sections -v CMakeFiles/temp_tracker.dir/source/main.c.obj libdevice.a libemlib.a -lgcc -lc_nano -lnosys -lgcc -lc_nano -lnosys --start-group -lgcc -lg_nano -lc_nano --end-group --start-group -lgcc -lc_nano --end-group /usr/lib/gcc/arm-none-eabi/5.4.1/armv7-m/crtend.o /usr/lib/gcc/arm-none-eabi/5.4.1/armv7-m/crtn.o
GNU ld (2.27-9+9) 2.27
   text	   data	    bss	    dec	    hex	filename
  10476	    120	    196	  10792	   2a28	temp_tracker
[100%] Built target temp_tracker

and make flash:

➜  build git:(master) ✗ make flash
[  7%] Built target device
[ 95%] Built target emlib
[100%] Built target temp_tracker
Scanning dependencies of target flash
SEGGER J-Link Commander V6.14h (Compiled May 10 2017 18:39:45)
DLL version V6.14h, compiled May 10 2017 18:39:37


Script file read successfully.
Processing script file...

J-Link connection not established yet but required for command.
Connecting to J-Link via USB...O.K.
Firmware: Silicon Labs J-Link OB compiled Apr  6 2017 16:11:45
Hardware version: V1.00
S/N: 440047451
VTref = 3.297V

Target connection not established yet but required for command.
Device "EFM32HG322F64" selected.


Found SW-DP with ID 0x0BC11477
Found SW-DP with ID 0x0BC11477
No AP preselected. Assuming that AP[0] is the AHB-AP
AP-IDR: 0x04770031, Type: AHB-AP
AHB-AP ROM: 0xF00FF000 (Base addr. of first ROM table)
Found Cortex-M0 r0p1, Little endian.
FPUnit: 4 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl[0] @ F00FF000
ROMTbl[0][0]: E00FF000, CID: B105100D, PID: 000BB4C0 ROM Table
ROMTbl[1] @ E00FF000
ROMTbl[1][0]: E000E000, CID: B105E00D, PID: 000BB008 SCS
ROMTbl[1][1]: E0001000, CID: B105E00D, PID: 000BB00A DWT
ROMTbl[1][2]: E0002000, CID: B105E00D, PID: 000BB00B FPB
ROMTbl[0][1]: F0040000, CID: B105900D, PID: 001BB932 MTB-M0+
Cortex-M0 identified.
PC = 00002090, CycleCnt = 00000000
R0 = 00000000, R1 = E000ED00, R2 = 200009C8, R3 = 00000004
R4 = 00000004, R5 = 40002000, R6 = 20001FBC, R7 = 00000D39
R8 = 00000000, R9 = 02000000, R10= 1FFF2000, R11= 00000000
R12= 4000A000
SP(R13)= 20001FA0, MSP= 20001FA0, PSP= 00000000, R14(LR) = 00002A9F
XPSR = 61000000: APSR = nZCvq, EPSR = 01000000, IPSR = 000 (NoException)
CFBP = 00000000, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 00

Downloading file [temp_tracker.bin]...
Comparing flash   [100%] Done.
Erasing flash     [100%] Done.
Programming flash [100%] Done.
Verifying flash   [100%] Done.
J-Link: Flash download: Flash programming performed for 1 range (11264 bytes)
J-Link: Flash download: Total time needed: 0.602s (Prepare: 0.071s, Compare: 0.009s, Erase: 0.271s, Program: 0.237s, Verify: 0.001s, Restore: 0.011s)
O.K.

Loading binary file temp_tracker.bin
Reading 10596 bytes data from target memory @ 0x00000000.
Verify successful.

Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.



Script processing completed.

[100%] Built target flash

So the first thing I think to do is alright spin up the debugger so I create two shells, one I run cmake debug-server and the other I run make debug in GDB I run monitor reset halt followed by break main followed by continue however it never breaks.

Output of make debug-server:

 ➜  build git:(master) ✗ make debug-server 
[  7%] Built target device
[ 95%] Built target emlib
[100%] Built target temp_tracker
Scanning dependencies of target debug-server
SEGGER J-Link GDB Server V6.14h Command Line Version

JLinkARM.dll V6.14h (DLL compiled May 10 2017 18:39:37)

-----GDB Server start settings-----
GDBInit file:                  none
GDB Server Listening port:     2331
SWO raw output listening port: 2332
Terminal I/O port:             2333
Accept remote connection:      yes
Generate logfile:              off
Verify download:               off
Init regs on start:            off
Silent mode:                   off
Single run mode:               off
Target connection timeout:     0 ms
------J-Link related settings------
J-Link Host interface:         USB
J-Link script:                 none
J-Link settings file:          none
------Target related settings------
Target device:                 EFM32HG322F64
Target interface:              SWD
Target interface speed:        4000kHz
Target endian:                 little

Connecting to J-Link...
J-Link is connected.
Firmware: Silicon Labs J-Link OB compiled Apr  6 2017 16:11:45
Hardware: V1.00
S/N: 440047451
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 2 bytes @ address 0x000003D6 (Data = 0xF7FF)
Read 2 bytes @ address 0x000003D6 (Data = 0xF7FF)
Read 2 bytes @ address 0x000003D6 (Data = 0xF7FF)
Read 4 bytes @ address 0x00000460 (Data = 0x46C0E7FE)
Setting breakpoint @ address 0x000003D6, Size = 2, BPHandle = 0x0001
Starting target CPU...

I also tried deleting build and recreating it with both the commands cmake -DCMAKE_BUILD_TYPE=Debug .. and cmake -DCMAKE_CXX_FLAGS_DEBUG=-g3 -DCMAKE_BUILD_TYPE=Debug .. followed by rebuilding and reflashing however that made no difference. Any ideas or would be great cause I am not sure where to go from here...

The architecture of the new GG11/GG12 is Cortex M4 but falls through to M3 in toolchain/efm32-base.cmake.

The EFM32 MicroPython port recently switched to using efm32-base for its headers and libraries; before it had its own import of the gecko_sdk and rail. However, after this change the device doesn't seem to be able to transmit -- everything else with the 802.15.4 radio mode works fine, but packets just don't seem to reach the other side.

I bisected the patches and found that this change in the library from rail/TARGET_EFR32_1/librail_efr32xg1_release.a to efm32-base/protocol/bluetooth/lib/EFR32MG1P/GCC/librail.a is the one that broke it: osresearch/micropython@8b375bd#diff-d4c7b5c5d3162a974a48093ebb03c72fR45

Linking the new image against the old library also works and restores TX functionality. One thing I noted is that the library in efm32-base has bluetooth in the name, so I'm curious if there was a different RAIL library that has the 802.15.4 support or if we're picking up the wrong library? The part is an EFR32MG1P132G1 (shown in the above photo), so I'm hoping that means the EFR32MG1P librail.a is the correct one.

Hi,

The referenced toolchain appears to be very old. Nearly 5 years old in fact. May I please confirm support for more recent build toolchains?

Your Travis CI bulid is using a different toolchain to those in the toolchain link on the repo. May I please confirm which you recommend and why?

Excerpt below

-- The C compiler identification is GNU 7.3.1
-- The CXX compiler identification is GNU 7.3.1

Ta, VR.

Hi Ryan,

You suggested in #31 that perhaps going to an ESP32 is a better option than continuing with the SiLabs chip for BLE and WiFi. We have a mostly complete project to track satellites that uses efm32-base, and we want to reuse the code on ESP32, or perhaps make it compatible with both platforms.

Fortunately, ESP-IDF is also cmake-based, so maybe this is pretty easy to add as a submodule and start porting.

• Do you have any experience doing something like this?
• Any words of wisdom along the way?

Thanks for your help!

-Eric and Zeke

I was curious if OpenOCD can be used instead of the Jlink software in order to use a more open debugging and flashing environment. If so it might be worth adding support in the make files for flashing with openocd commands.