NRF52840 (PCA10059) Openthread Router - Example

[jibba]

Hi

The latest OpenThread/Zigbee SDK has no examples for openthread with the PCA10059 (No MBR, executing directly from 0x0 @ flash start).

Ive tried now multiple times combining examples together but i cannot build it, as required libraries are either not available for the NRF52840 or outdated.

There are examples of compiling the libs (openthread) yourself, ive done this but this is not all of it required for example for the openthread-simple-server.

- I would very much welcome all the source code in the SDK so i would not need to work with precompiled static libraries.

- I would also very much welcome examples for all your boards, not just some of them.

Would you be able to extend the SDK?

[Jørgen Holmefjord]

Hi,

It is not entirely correct that there are no Thread examples for the PCA10059 dongle. Both CLI and NCP examples comes with projects for PCA10059. The main reason why we provide limited examples for the dongle is that is does not come with any built-in debug-capabilities, making it a bad fit for development. The dongle is primarily intended for use with out development tools, like nRF Connect applications, Thread Border Router, etc.

It is of course possible to build other applications for the dongle as well, but due to the lack of debug-capabilities we would like to limit the number of customers that use this as a development platform. For this reason, I do not think we will extend the nRF5 SDK for Thread and Zigbee with more examples for this board.

You can follow the instructions in this tutorial for porting an existing PCA10056 project to PCA10059. You may also need to move the "Thread persistent data" region in flash as well, to prevent it from overlapping with the dongle Bootloader. Note that the dongle does not have a UART to USB interface, like we have on the DK. If you want to use UART for logging, etc, this must be done through the USB port of the nRF52840, using the CDC ACM class.

Regarding including full source code for OpenThread in the nRF5 SDK, this would make the compilation process take much longer time than what it does with the precompiled library approach. If you build the libraries on your own computer, you should be able to debug the source code as you would if building from source. You can also add the source files to your project after cloning the OpenThread repository. A list of required files, paths, and symbols are shown in the Makefiles used for building the libs.

Best regards,
Jørgen

[jibba]

Hi Jorgen

Thanks. However, i have the J-Link attached to my USB Dongle, so nothing lost there. The Uart as ive read should be also super easy, since i can use any GPIO as TX or RX pin (How do you solve this btw? is this a Software-Uart?).

My input was just its a bit of a rocky getting-started, and i think if the source would be placed into the SDK you would solve mutliple issues:

- Version Dependency would be gone, as per SDK release, within the Release, SW-Versions would match.

- Software not libraries: Helps to understand it better and i mean we live in the age of 8/12/16 core machines and tools like distcc or ccache, so its pretty fast.

Thanks

[Jørgen Holmefjord]

If you have a J-Link connected to the dongle, it makes it more suitable for development, but since the SDK is intended for all customers, and a lot of customers will start using the dongle for development (due to the low pricing) if all projects are provided for this, we have decided to provide examples only for the intended use-cases of the dongle in the SDK. It should still be possible to port the other examples to this device, especially if you have erased the bootloader and MBR, then it works mostly like a DK, with different pinout.

The UART is not a software-UART, but the nRF5 series chips includes a pin-crossbar feature, allowing any serial interface to be connected to any GPIO. This makes it very flexible for board layout, etc.

I'm not sure if I understand your point about version dependency. The projects would still have to be linked towards a specific version of the OpenThread source code. If the source code was updated with new APIs, or files were moved, the projects would still have to be updated to match the new version.

If you would like to develop OpenThread application with the full source code, it is also possible to build applications directly in OpenThread on Linux and macOS. Another alternative is to look in the nRF Connect SDK, which will get more support for OpenThread in the coming months/years.