OpenThread support for OTA on EFR32

Question

due to the discontinuation of the SL-Thread stack by Silicon Labs, we are considering migrating to OT for a new device in a system that is already based on EFR32s.

The device would be a relatively simple, mains powered FTD (think "range extender").

I am trying to estimate what the effort would be and in particular I am a bit worried about OTA firmware updates. Looking at the EFR directory in the GitHub repo, I see: no trace of the Gecko bootloader. Does this imply that we should use a regular Gecko bootloader build from the SL SDK? Or is there a OT-specific bootloader that I'm missing? no trace of an OTA protocol (in SL'Thread there used to be a TFTP implementation and an dotdot implementation) Is there any plan to have a OpenThread specific OTA method? Or is the official advice to use the GeckoBootloader and implement your own transfer protocol?

Thanks in advance, Matteo

Answer 1

Jonathan Hui, tech lead for OpenThread, replied in the Google Group .

Quoting him: "The primary goal of the OpenThread project is to implement the Thread protocol. Given that Thread is a network-layer technology, it does not specify a protocol for OTA. Similarly, the OpenThread project does not include bootloaders and OTA in its scope."

Answer 2

I have lots of experience with the efr32 line of microcontrollers and, incidentally, I'm also attempting to port our Silicon Labs Thread implementations to OpenThread. So I think I can help you here...

If you only need a powered (assuming non-sleepy) full thread device this may not be too much of a problem. You can build the demo projects from the command line (either in Linux or Windows Subsystem for Linux) and just change one of the demo projects to meet your needs.

If you need an IDE build for advanced debugging functionality or just general usability this is much more of a challenge.

The bootloader may be a bit of an issue though. OpenThread is only designed to implement the Thread protocol and is generic so it can be used in a myriad of applications. You won't see any of the Gecko Bootloader stuff there, or any bootloader stuff for that matter.

The Gecko bootloader is essentially an application that runs after a microcontroller reset which looks for a Gecko bootloader image (.gbl) either in external flash or internal flash. If it finds an image it will overwrite the existing application and boot into it. If it doesn't find an image it will just jump to the application. So you're bootloader challenge is 2-fold.

1) The application has to put the .gbl image into the memory location the Gecko bootloader expects. There isn't a standard way to to this as far as I know, it's up to the application. My application, for instance, repeatedly polls a CoAP endpoint to grab chunks of the .gbl image to put in external flash (which is where my bootloader expects the image). Then when it gets the whole image it reboots.

2. The demo project for the efr32 boards in openthread use a linker script that doesn't include space for the Gecko Bootloader. You'll have to reverse engineer the linking process used in the Simplicity Studio build. It uses 2 linker files as well as some #defines to put the application in the correct location. Depending on your comfort level with the build process this may or may not be difficult.

A note of caution: If you need an migrate an existing Silicon Labs Thread stack based project to an OpenThread project you're in for a beast of a project. The Silicon Labs Thread stack integrates a simple non-rtos based scheduler and sleep functionality. OpenThread, even the efr32 demo projects, contain none of this. Because the Silicon Labs Thread stack is closed source, it makes this much much more difficult. I'm attempting to do this right now an it is very unpleasant. I wouldn't wish it on my worse enemy.