Using OpenThread and ESB Together on nRF52840

RE: Using OpenThread and ESB Together on nRF52840

Shi — Fri, 22 Mar 2024 17:38:47 GMT

Following the tests, I encountered an issue where the ESB program from the BLE+ESB demo mentioned previously could not function properly. Specifically, after disabling ESB and then starting OpenThread, the application would consistently trigger the RADIO_IRQn associated with the ESB connection, leading to the application freezing. The root cause was identified as the failure to restore OpenThread's MPSL interrupt bindings after shutting down ESB. The relevant code for this operation is found within the mpsl_lib_init() function.

Taking inspiration from the BLE implementation, I attempted to call mpsl_lib_uninit() before starting ESB and mpsl_lib_init() after shutting it down. However, this approach resulted in an "mpsl_init: MPSL ASSERT: 107, 271" error, which seems to be related to clock settings.

Further debugging revealed that it was unnecessary to uninitialize MPSL. Instead, simply calling mpsl_lib_init() function (excluding the "err = mpsl_lib_init_internal();" part) after shutting down ESB was sufficient. Additionally, it was discovered that ESB can be started and stopped directly within the timeslot status change event using the conventional method, without needing to manipulate the IRQ register as done in the demo. The event code is as follows:

void timeslot_callback(timeslot_callback_type_t type)
{
    int err;
    if (type == APP_TS_STARTED) {
        err = esb_initialize();
        if (err) {
            LOG_ERR("ESB initialize failed, err %d", err);
            return;
        }
    } else {
        esb_disable();

        err = MULTITHREADING_LOCK_ACQUIRE();
        if (err) {
            LOG_ERR("MULTITHREADING_LOCK_ACQUIRE() failed, err %d", err);
            return;
        }
        mpsl_lib_init_irq();
        MULTITHREADING_LOCK_RELEASE();
    }
}

RE: Using OpenThread and ESB Together on nRF52840

Shi — Fri, 22 Mar 2024 09:26:14 GMT

Continuing our previous discussion, I'd like to share some updates and progress. After implementing the missing CONFIG_MPSL_DYNAMIC_INTERRUPTS=y configuration from the example project and modifying the timeslot request logic, I've observed some positive changes. Specifically, I adjusted the handling of timeslot requests: instead of directly requesting another timeslot within the event handler upon a failed extension request, I now send a REQ_MAKE_REQUEST message to a thread via a message queue. Then, upon receiving the REQ_MAKE_REQUEST, the thread delays for 1 millisecond before executing mpsl_timeslot_request. My rationale for this approach is based on the assumption that the delay only needs to exceed the NRF_802154_PRECISE_ACK_TIMEOUT_DEFAULT_TIMEOUT default of 210 microseconds.

With these adjustments, I am now able to run OpenThread in MTD sleep 500ms mode successfully. Next, I plan to test the ESB's transmission and reception functionality. If everything goes well without further issues, I'll be prepared to close this discussion topic.

RE: Using OpenThread and ESB Together on nRF52840

Shi — Thu, 21 Mar 2024 13:48:50 GMT

Hello Kenneth,
I want to express my sincere thanks for your guidance and information.Following your advice, I was able to compile without the need for CONFIG_NRF_802154_TEMPERATURE_UPDATE=n. However, I've encountered a series of challenges that I'm hoping you can help me navigate.

1. Successful Timeslot Requests: Using the example code you provided, I successfully requested timeslots. This, however, seems to affect OpenThread's ability to connect to a router, keeping it in a "detached" state. Interestingly, running ot scan can still detect the Thread network without any issues.

2. Temporary Resolution by Closing Timeslot Session: Closing the timeslot session after 30 seconds allows OpenThread to quickly connect to the router and ot ping operates normally. However, reopening the timeslot session after another 30 seconds leads to continuous state changes every 0.5 seconds (according to CONFIG_OPENTHREAD_POLL_PERIOD=500), with OpenThread staying in the "child" state. During this period, ot ping encounters packet loss due to the consecutive state changes, even though tcpdump -i wpan0 on the pinged otbr indicates successful receipt and transmission of ICMP6 packets.

3. Observations on Timeslot and Radio Control: It seems that OpenThread does not request timeslots for receiving, which allows the application to capture the timeslot and take control of the radio. This is particularly noticeable when OpenThread is in MTD mode with mRxOnWhenIdle=1; timeslots are successfully requested and maintained until ot ping commands briefly take over the radio before releasing it, suggesting that OpenThread does not monopolize the radio during reception.

Here are the configurations I've implemented:

CONFIG_NO_OPTIMIZATIONS=n
CONFIG_DEBUG_OPTIMIZATIONS=n
CONFIG_SPEED_OPTIMIZATIONS=y
CONFIG_SIZE_OPTIMIZATIONS=y

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2304
CONFIG_MAIN_STACK_SIZE=2048

CONFIG_MPSL=y
CONFIG_MPSL_TIMESLOT_SESSION_COUNT=2
CONFIG_MPSL_FEM=y
CONFIG_MPSL_FEM_SIMPLE_GPIO=y

CONFIG_NETWORKING=y
CONFIG_NET_L2_OPENTHREAD=y
CONFIG_OPENTHREAD_SLAAC=y
CONFIG_OPENTHREAD_DNS_CLIENT=y
CONFIG_OPENTHREAD_MTD=y
CONFIG_OPENTHREAD_MTD_SED=y
CONFIG_OPENTHREAD_POLL_PERIOD=500
CONFIG_RAM_POWER_DOWN_LIBRARY=y

CONFIG_DYNAMIC_INTERRUPTS=y
CONFIG_DYNAMIC_DIRECT_INTERRUPTS=y

CONFIG_ESB=y
CONFIG_ESB_DYNAMIC_INTERRUPTS=y

These issues have left me quite puzzled, and I would greatly appreciate your insights or suggestions on how to resolve them.

Thank you in advance for your assistance.

RE: Using OpenThread and ESB Together on nRF52840

Kenneth — Wed, 20 Mar 2024 15:40:17 GMT

Hello,

Not entirely sure what the problem is, but you can find an example that use BLE and ESB here:
https://github.com/too1/ncs-esb-ble-mpsl-demo

The prj.conf is here:
https://github.com/too1/ncs-esb-ble-mpsl-demo/blob/master/app_netcore/prj.conf

I suspect you are missing one of the configurations, try to add line 19-26.

Kenneth