OpenThread application development

Table of Contents

• 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.

---

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.