802.15.4 Multiprotocol

[Ted Herman]

I am attempting the use of Nordic's 802.15.4 stack with Softdevice in a multiprotocol way, but not using Thread or Zigbee. The application initializes sdh, then ble, then nrf_802154. The application receives packets (sent by another nRF52840 DK) correctly for about two minutes, but then does not receive any more packets, although the app continues to run (we see the NRF_LOG_INFO messages continue being printed). I could not think of a way to debug this, so I tried simply refreshing the 802154 stack, stopping and restarting Softdevice/BLE. I have some observations from my experience.

Background: using SDK15.3, using the github repo of 802154 at commit 79385a34 (Thursday Feb 28 2019).

1. The call to nrf_802154_deinit() resulted in a SOFTDEVICE: INVALID MEMORY ADDRESS error. Looking into the code, I found the following problems.

2. It helps to make empty the body of the function nrf_802154_hp_timer_deinit(), at least for my case of using RAAL_SOFTDEVICE

3. The function nrf_raal_uninit() has a bug - it should assign m_initialized = false, otherwise a subsequent nrf_raal_init() will fail an assert check.

4. One source of the softdevice error was the call to nrf_drv_clock_uninit found in nrf_802154_clock_sdk -- I could not see a simple fix for that. So, I removed both nrf_drv_clock_init() and nrf_drv_clock_uninit() from nrf_802154_clock_sdk, which then requires initializing nrf_drv_clock in the app before calling nrf_802154_init. 

With changes (2)-(4), it appears that the workaround succeeds, the app continues to receive packets indefinitely. I have several other difficulties which will be subjects of future postings to devzone.

[Ted Herman]

I forgot to mention, the app is using promiscuous mode for receiving, and also calls nrf_802154_buffer_free_raw upon each nrf_802154_received_raw event to recycle memory. No matter how this turns out, it is good to be able to repeatedly init() and deinit() the 802.15.4 stack.

[Ted Herman]

I discovered a problem in the app (timing error of received_raw handler working on same variables as app_scheduler task) which may explain why packets were not being received after a couple minutes. However, my observations about trying nrf_802154_deinit() and later nrf_802154_init() remain. 

[Vidar Berg]

Thanks for the update! With regards to the problem with init and de-initialization of 802.15.4: the radio/power/clock registers are protected while the Softdevice is enabled and it will trigger a "memory access" assert if the app tries to access any of these registers directly outside of radio timeslot. 

[Ted Herman]

How does the app become aware it is inside a timeslot? Is it by a periodic call to nrf_raal_timeslot_us_left_get() in the raal api?

[Vidar Berg]

Timeslot scheduling should be transparent to the app (i.e., handled internally in the 15.4 driver). Are you using our dynamic or switched multiprotocol support (doc link)? It sounds like there might be a limitation in our driver implementation that prevents you from repeatedly initializing and deinitializing 15.4.