OpenThread application development

Table of Contents

• Thread-safe MbedTLS with FreeRTOS
• USB pseudo reset

Note

OpenThread API is not thread-safe.

As an application developer, you must make sure that calls to the OpenThread API are not preempted by other calls to the OpenThread API.

• In a bare-metal environment, this is achieved by executing all OpenThread procedures from the main function context. Do not call any OpenThread functions in ISRs or callbacks from ISR context. You can use the app_scheduler module to execute callbacks from the app_timer and the SoftDevice in the main context. Refer to the examples included in this SDK to see how the app_scheduler module should be used with OpenThread.
• In an operating system environment, all calls to the OpenThread API must be performed from a single thread. Other threads may call OpenThread functions, but the function call must be guarded by mutex to make sure one call is not preempted by another one. For a reference, see BLE HRS and Thread CoAP Server with FreeRTOS Example.

---

Thread-safe MbedTLS with FreeRTOS

MbedTLS can utilize external implementation for mutexes when working in the RTOS environment. The freertos_mbedtls_mutex module enables usage of FreeRTOS mutexes with mbedTLS. For details and the list of modules with automatic locking protection, see MbedTLS Thread Safety and Multi Threading.

Note

This library does not currently support hardware acceleration with the ARM CryptoCell.

To enable Thread-safe MbedTLS in your FreeRTOS application:

• Use libraries from the mtls_ts directory.
• Add the following defines:
  • DISABLE_CC310=1
  • MBEDTLS_THREADING=1.
• Include in your project the freertos_mbedtls_mutex component located at <InstallFolder>/components/thread/freertos_mbedtls_mutex/.
• Call the function freertos_mbedtls_mutex_init() in the initialization of the application before initializing OpenThread and using any mbedTLS API.

---

USB pseudo reset

The USB variant of the nRF52840 platform library uses a feature called pseudo reset.

Pseudo reset causes the reinitialization of the OpenThread stack and certain peripherals. It is invoked instead of triggering a hardware reset when a reset from OpenThread stack is requested. The reason for such behavior is that when native USB CDC connectivity is used, performing a hardware reset would cause the device to reenumerate in the host system. As a result, this would impair the ongoing communication through CLI or Spinel. Any application that uses USB CDC for serial communication must use the pseudo reset feature instead of the hardware reset. Refer to Thread CLI Example or Thread NCP/RCP Example for an example implementation of this feature.