nRF 52840 thread application stops at otSysProcessDrivers on Fanstel BT840

[Rajendra]

Hello,

I am working on BLE+Thread multiprotocol and took ble_thread_swi_template as a base code. I am using nRF5_SDK_for_Thread_and_Zigbee_v4.1.0_32ce5f8. My development hardware is Fanstel BT840. I am using softdevice - s140_nrf52_7.0.1_softdevice.

When I run the template example, the thread gets up but suddenly stops working.

When debugged I found that - When this function - otSysProcessDrivers(mp_ot_instance); is called inside thread_process(), the application suddenly stops.

void thread_process(void)
{
    ASSERT(mp_ot_instance != NULL);
    otTaskletsProcess(mp_ot_instance);
    otSysProcessDrivers(mp_ot_instance);
}

I also have made internal clock related changes for BT 840: https://devzone.nordicsemi.com/f/nordic-q-a/58956/softdevice-not-working-on-bt840-based-custom-board

#define NRF_SDH_CLOCK_LF_SRC 0
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#define NRF_SDH_CLOCK_LF_ACCURACY 1

This same example works on nRF Development Kit but does not work on BT840. I was wondering how does the underlying hardware affecting the thread operation? Kindly let me know if there is any information on this.

Thanks in Advance,

Rajendra

[Sigurd Hellesvik]

Hi Rajendra

This same example works on nRF Development Kit

Just to make sure: Which Developement Kit are you using?

Regards,
Sigurd Hellesvik

[Rajendra]

I am using nRF52840-DK, Version 2.0.2  2021.44

It works on nRF52840-DK, Version 2.0.1  2020.38  as well.

[Sigurd Hellesvik]

In that case, it would be nice with some more information about your issue.

Is the BME advertising at any point during your test?

Are you able to use debugging to step into otSysProcessDrivers  to find where exactly the code stops running?

Regards,
Sigurd Hellesvik

[Rajendra]

This is my main function. The while loop stops printing LOG messages after 2-3 seconds.

When I comment out otSysProcessDrivers(mp_ot_instance); it keeps on printing LOG messages
//////////// main function
int main(void)
{
log_init();
scheduler_init();
timers_init();

// init Thread stack
thread_instance_init();
thread_coap_init();
NRF_LOG_MSG("\nThread init complete");

uint32_t loop_cnt = 0;
uint32_t cnt = 0;

while (true)
{
  thread_process(); // calling this function causes issue

  app_sched_execute();

  if (NRF_LOG_PROCESS() == false)
  {
    thread_sleep();
  }

  //// just to check if main is running all the time.
  loop_cnt++;
  if(loop_cnt == 100)
  {
    cnt++;
    NRF_LOG_MSG("\nloop cnt:%d", cnt);
    loop_cnt = 0;
  }
}

}

This is the memory map from linker file, I am using default ld file -ble_thread_swi_template_gcc_nrf52.ld from SDK examples.
MEMORY
{
  FLASH (rx) : ORIGIN = 0x27000, LENGTH = 0xd5000
  RAM (rwx) : ORIGIN = 0x20002ae8, LENGTH = 0x3d518
  ot_flash_data (r) : ORIGIN = 0xfc000, LENGTH = 0x4000
}

As mentioned above, I have already made clock related changes:
Clock setting required for Thread:
CLOCK_CONFIG_LF_SRC 0
CLOCK_CONFIG_LF_CAL_ENABLED 1
Clock setting required for Bluetooth:
#define NRF_SDH_CLOCK_LF_SRC 0
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#define NRF_SDH_CLOCK_LF_ACCURACY 1

I have not debugged inside otSysProcessDrivers yet, may be that would help me. Any quick reference on debugging into openthread?

Regards,
Rajendra

[Sigurd Hellesvik]

If you use a mobile application, for example the nRF Connect for Mobile, can you see that your Bluetooth Low Energy is advertising? Will it also advertise if you call otSysProcessDrivers?

See our tutorial on Debugging with Segger Embedded Studio.

Regards,
Sigurd Hellesvik

[Rajendra]

I switched to 'simple_coap_client' from ble_thread_swi_template and switched to 'Fanstel BT840 DK' from my custom board.
I did this to check if there is any issue with softdevice stack on my custom board. The same issue still persists. 
Now it is clear that Thread stack(SDK:nRF5_SDK_for_Thread_and_Zigbee_v4.1.0_32ce5f8) has some issue running on BT840.

Regards,
Rajendra

[Sigurd Hellesvik]

Hi Rajendra,

Did you test what I suggested in my previous answer?

Sigurd Hellesvik said:

If you use a mobile application, for example the nRF Connect for Mobile, can you see that your Bluetooth Low Energy is advertising? Will it also advertise if you call otSysProcessDrivers?

Regards,
Sigurd Hellesvik

[Rajendra]

Hi Sigurd,

Here in 'ble_thread_swi_template' either THREAD or BLE is running. When BLE is running it runs well. I can see advertising messages, I can connect and disconnect from 'nRF Connect for Mobile'. The issue arises when I switch from BLE to THREAD by calling - 'switch_ble_to_thread()'.
When I am in THREAD I do not see any advertising messages since BLE is OFF(BLE deinit was called during switching). I also checked in 'nRF5_SDK_for_Thread_and_Zigbee_2.0.0_29775ac' and found that THREAD works well with this SDK
Here is the summary of the working SDKs.

SDK	OPENTHREAD-VERSION	WORKS ON NRF52840-DK?	WORKS ON BT840-DK?
nRF5_SDK_for_Thread_v0.10.0_e1c3d11	OPENTHREAD/g6a15261b-dirty; NRF52840; Jun 29 2017 09:15:02	Yes	Yes
nRF5_SDK_for_Thread_and_Zigbee_2.0.0_29775ac	OPENTHREAD/g591ec62; NRF52840; Sep 19 2018 11:42:29	Yes	Yes
nrf5sdkforthreadandzigbeev300d310e71	OPENTHREAD/20180926-00501-g23ff1015; NRF52840; Mar 25 2019 13:04:52	Yes	Yes
nrf5sdkforthreadandzigbeev3209fade31	OPENTHREAD/20180926-00632-g2279ef61; NRF52840; May 23 2019 20:44:20	Yes	Yes
nRF5_SDK_for_Thread_and_Zigbee_v4.1.0_32ce5f8	OPENTHREAD/20191113-00534-gc6a258e3; NRF52840; Apr  5 2020 21:51:18	Yes	No
nrf5_sdk_for_thread_and_zigbee_v4.2.0_af27f76	OPENTHREAD/20191113-00534-gc6a258e3; NRF52840; Apr  5 2020 21:51:18	Yes	No

Best Regards,
Rajendra

[Sigurd Hellesvik]

Hi Rajendra,

It is definitively interesting that it works for previous versions of the SDK.
I will check this with our developers to see if this is caused by a bug or a purposeful change.

I will return here when I know.

Thank you for the thorough testing.

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

Hi Rajendra,

First up: The nRF Connect SDK is the newest SDK we have. Therefore, our developers are not able to look too closely at your issue.

But since you found that there is a difference between version 4.1.0 and 3.2.0, I suggest that you have a look at the difference between these two, and see if you can find the issue yourself here.
Our developers suggest that you start looking at the thread_init function, as it seems to have changed between 4.1.0 and 3.2.0.

Another solution could be to try to run Multiprotocol with our nRF Connect SDK, since we recommend the nRF Connect SDK for new projects.

By the way, do you see the same issue with the BT840 DK if you turn on the SW5?

Regards,
Sigurd Hellesvik