New platform: EFR32 from Silicon Labs

[Jonathan Beri]

https://github.com/openthread/openthread/tree/master/examples/platforms/efr32

We're excited to announce support for the EFR32 from Silicon Labs. The example demonstrates OpenThread running on the EFR32™ Mighty Gecko Wireless Starter Kit using RAIL, part of the Flex SDK, provided by Silicon Labs. Support for the low-cost Thunderboard™ Sense will be landing next.

Please give this new platform a go and send us feedback and suggestion on Github.

[Mike Morschbert]

The Thunderboard looks indeed quite decent for demo applications as it is reasonably priced around 35-40$/€. Would love to see support for those.

[Adam Pierce]

Hi Johnathan, I was working on my own EFR32 port so this release has saved me some time and effort.

I want to get it running on the MGM111 module which has less memory than the latest Mighty Gecko kit. So far it has been working, I changed the Makefiles to refer to the appropriate linker scripts and libraries for my platform and it works up the point where you can ping nodes. So that's good.

Now I want to try the commission/join functionality but when I compile with COMMISSIONER=1, the image exceeds the available RAM. Do you have any advice on reducing RAM usage so I can get it to run?

[Adam Pierce]

Solved it. I reduced the number of packet buffers from 40 down to 24 and it fits in 32k of RAM now.

[Oluwokay Victor Johns]

Hi,
  I was attempting to try out this platform as I have some available here at work and am also working on Thread.

I am able to build the examples, setup the JLinkGDBServer and flash the output to the board. However, it looks as though currently I never advance past the reset handler. Please find the serial output from the gdb session in which I flashed the elf file to the board. Since I see other people have gone thru this exercise successfully, kind of puzzled as to where to start debugging this. I can't step thru the code
Any input/help would be appreciated

Thanks
Victor

<==========excerpt from gdb session start ==================================================================>
johnsv@johnsv-desktop:~/open_thread_codelab/openthread_src/openthread-master/output/efr32/bin$ arm-none-eabi-gdb ot-cli-ftd
GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ot-cli-ftd...done.
(gdb) target remote 127.0.0.1:2331
Remote debugging using 127.0.0.1:2331
Default_Handler ()
    at /home/johnsv/open_thread_codelab/openthread_src/openthread-master/examples/../examples/platforms/efr32/../../../third_party/silabs/gecko_sdk_suite/v1.0/platform/Device/SiliconLabs/EFR32MG12P/Source/GCC/startup_efr32mg12p.c:356
356      while(1);
(gdb) load
Loading section .text, size 0x2c8c8 lma 0x0
Loading section .ARM.exidx, size 0x8 lma 0x2c8c8
Loading section .data, size 0x294 lma 0x2c8d0
Start address 0x202f8, load size 183140
Transfer rate: 14903 KB/sec, 3896 bytes/write.
(gdb) monitor reset
Resetting target
(gdb) c
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
Default_Handler ()
    at /home/johnsv/open_thread_codelab/openthread_src/openthread-master/examples/../examples/platforms/efr32/../../../third_party/silabs/gecko_sdk_suite/v1.0/platform/Device/SiliconLabs/EFR32MG12P/Source/GCC/startup_efr32mg12p.c:356
356      while(1);
(gdb) where
Cannot access memory at address 0x2003fff4
#0  Default_Handler ()
    at /home/johnsv/open_thread_codelab/openthread_src/openthread-master/examples/../examples/platforms/efr32/../../../third_party/silabs/gecko_sdk_suite/v1.0/platform/Device/SiliconLabs/EFR32MG12P/Source/GCC/startup_efr32mg12p.c:356
#1  <signal handler called>
Backtrace stopped: Cannot access memory at address 0x2003fff0
(gdb) bt
#0  Default_Handler ()
    at /home/johnsv/open_thread_codelab/openthread_src/openthread-master/examples/../examples/platforms/efr32/../../../third_party/silabs/gecko_sdk_suite/v1.0/platform/Device/SiliconLabs/EFR32MG12P/Source/GCC/startup_efr32mg12p.c:356
#1  <signal handler called>
Backtrace stopped: Cannot access memory at address 0x2003fff0
(gdb)

<==========excerpt from gdb session end  ==================================================================>

[xiaom]

Hi Victor,

May I know what the specific part number of EFR32 SoC you are using is and which version of gecko sdk is? Currently OpenThread supports EFR32MG12P serial. You can find the macro defined in the Makefile.am (/example/platforms/efr32/Makefile.am)

I guess that the default handler might be caused by the mismatched platform initialization function in the first glance.

Thanks,

Xiao

[Oluwokay Victor Johns]

Hi,
  It looks from your setup as though you are using the newer daughtercard boards with more SRAM ( 256k on the 4161 based boards vs 32K on the 4151 based boards).
I was just curious if anyone here has gotten open thread on the EFR32 platform working on the 415* based boards. These boards typically have 32K of SRAM

Thanks
Victor

[Oluwokay Victor Johns]

Also,
 If anyone can point me to where I can modify the linker file in order to change the memory map. I looked thru the Makefile, but it is not apparent to me which ld file I would need to change in order to get the memory map to be correct)

Any help would be appreciated


Thanks

Victor

[Martin Turon]

The linker file selection occurs in the Makefile.am of the application, so both cli and ncp examples have a chunk of paths for each platform such as this:

https://github.com/openthread/openthread/blob/ac416b4fd4592b3c2bee15846cb334b97b5bf44d/examples/apps/cli/Makefile.am#L112

if OPENTHREAD_EXAMPLES_EFR32

LDADD_COMMON += \

$(top_builddir)/examples/platforms/efr32/libopenthread-efr32.a \

$(top_srcdir)/third_party/silabs/gecko_sdk_suite/v1.0/platform/radio/rail_lib/autogen/librail_release/librail_efr32xg12_gcc_release.a \

$(NULL)

LDFLAGS_COMMON += \

-T $(top_srcdir)/third_party/silabs/gecko_sdk_suite/v1.0/platform/Device/SiliconLabs/EFR32MG12P/Source/GCC/efr32mg12p.ld \

$(NULL)

endif # OPENTHREAD_EXAMPLES_EFR32

_____________________________
Martin Turon  |  Nest Labs

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-users+unsubscribe@googlegroups.com.
To post to this group, send email to openthread-users@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/9d809403-322d-4e9b-b1d1-a3fac25326b4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Oluwokay Victor Johns]

Hi All,

  I went thru and modified the Makefile.am files to point to the lower memory EFR32 target ( 32K RAM). The image flashes, but I can never advance past the initialization of the platform. I was able to obtain some of the higher end EFR32 targets ( 256K RAM) and this works fine. I was wondering if there would be any interest in pursuing getting ot running on some of the lower end targets. It seems that this might be useful for the mtd use case.

If there is, I could take a look into this ( with some help from others of course)

Thanks

Victor

To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.

[Jonathan Hui]

Hi Victor,

Thanks for the update.  We've experienced the same issue of fitting into the smaller EFR32, but have not had much time to investigate further.  Would be great if you wanted to dive in deeper.  Xiao Ma (cc'ed) may also be able to help with your efforts.

--

Jonathan Hui

To unsubscribe from this group and stop receiving emails from it, send an email to openthread-users+unsubscribe@googlegroups.com.
To post to this group, send email to openthread-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/8a080aa8-93b4-43f1-a711-1cd8aeb42432%40googlegroups.com.

[Oleg Stukov]

Hi, Jonathan. I could build, flash and run ot-cli-ftd app on EFR32 platform using ARTIK 030 Mesh Networking Kit (SIP-KITSZG001) - see https://www.artik.io/modules/artik-030/ for details. Of course, related Makefile.am files were modified to refer to particular EFR32MG1P family and BRD4300D radio board in Gecko SDK. This is exactly "smaller EFR32" with just 256K of flash memory and 32 K RAM. As it appeared, it's possible to fit into these limits with most OT roles including border router and, as mentioned above by Adam Pierce, even with commissioner / joiner, if default number of packet buffers is reduced.

Unfortunately, I've experienced problems trying to communicate between 2 devices running the CLI apps.Even though I follow the EFR32 example guideline, both devices become leaders, as they can't contact each other. It's observed that when devices use different radio channels, usually the one started earlier can discover its counterpart initially. Attempt to run scan / discovery on the 2nd (later started) device results in a kind of hanging this process (it never reports "Done"). At the same time the discovery in progress is exhausting packet buffers gradually, and the 1st device stops finding the 2nd one in this state. If both devices share the same radio channel from the beginning, it seems they are never detected by discovery from both sides.

Could you suggest what might be wrong in this case? By the way, I use console in Simplicity Studio by Silicon Labs as terminal to test devices; ordinary programs like minicom or putty couldn't communicate via /dev/ttyACM0 (although opened the port after granting necessary privileges).

Thank you in advance,

Oleg

Jonathan Hui

[xiaom]

Hi Oleg,

I tried to modify the Makefile.am(s) and verified this with two EFR32MG1P SoC (BRD4151A). I didn't enable Commissioner or Joiner, since it will hit the RAM size limitation. It seems to work for me (I can open the /dev/ttyACM0, attach to thread network and ping each other). Please refer to the attachment for the specific modification.

Hope that helps.

Thanks,

Xiao

[Oleg Stukov]

Dear Xiao,

I checked the EFR32 example again referring to your updates.In fact, I did the same changes before. Besides, Makefile-efr32 should also be corrected to use EFR32MG1P (not mentioned in your screenshot).

I'd like to remind, in my case the board is BRD4300D. As for working with a terminal program over /dev/ttyACM0/1, there was some mistake before, I finally could connect to the test boards via minicom.

Unfortunately, they still cannot contact each other as expected. Both modules become leaders whenever Thread starts, device discovery doesn't find counterparts sitting on the same channel. 

The Artik 030 modules are plugged in Wireless starter kit mainboards (BRD4001B). Aren't there any H/W settings that would affect 802.15.4 functioning?

Oleg

[xiaom]

Hi Oleg,

The starter kit mainboard what i'm using is BRD4001A. I didn't see any HW setting that would affect 15.4 functions.

Assuming that you have configured with the same parameters (master key, network name, channel, panid, xpanid) on both two boards. BTW, May I know which rail lib version you are using for testing?

Could you enable the logging feature or capture the traffic between two nodes with sniffer (if that's available in your hand) for analysis? Generally this problem is caused by either the sender fails to send the packet out or the receiver fails to receive the packet or drops the incoming packet due to some reason. Then finally both of two boards becomes to Leader.

Thanks,

Xiao

[Oleg Stukov]

Hi Xiao,

I rebuilt the EFR32 sample with OT_LOG_LEVEL_DEBG logging (with latest OT sources pulled today, on July 4) and tested it again.

Log fragment of the module started first is provided in the ot1.txt attachment, log of the 2nd module is in the ot2.txt.

As can be seen, ScheduleTransmissionTask() method of MeshForwarder class fails, and obviously more detailed logging is needed to find out why sending goes to busy status.

As for RAIL library version, it's a part of latest Gecko SDK 1.1.0 updated via Simplicity Studio by Silicon Labs.

Regards,

Oleg

[Oleg Stukov]

Hi, Xiao,

Even though no reply was posted here yet, I found recently that latest updates in OT git have solved my problem.

I noticed that you migrated to Gecko SDK 1.1 and applied changes to EFR32 platform layer.

Now ot-cli-ftd sample built for EFR32MG1P is working fine with BRD4300D board (ARTIK 030 Mesh Networking Kit), 

I can ping nodes of the mesh network, CoAP requests are processed correctly and scanning / discovery works well.

Thank you for your support!

Best regards,

Oleg

[Xiao Ma]

Hi Oleg,

Sorry for delay response, I took some PTO last week.

If that update works for you, I see what functions effects the behavior (you might already notice some update in “otPlatRadioTransmit()”). Actually in the latest Rail Lib, there are two fields added for TxOption structure(removeCrc and syncWorkId), I just updated with it accordingly. However, it should only effect with latest Rail Lib. Glad to hear that help fix your problem.

Thanks,

Xiao