In SDK versions above 1.8.0, sleeping threads don't wake when BT UART is connected in the nRF52840

[mnor]

It appears that after a few seconds and sometimes after a few minutes sleeping threads do not wake up, even though the UART shell and BT NUS are working. The only service that the BT is advertising is the BT NUS. This problem occurs after the first time that I connect to the BT NUS from my Android phone. If I don't connect to the BT NUS, then the firmware does not show this problem. The only way that I've been able to recover the nRF52840 is by resetting it. I don't see this problem in version 1.8.0 of the SDK. 

[Einar Thorsrud]

Hi,

Is this something you see with a sample application or your own firmware? Which threads are not waking up, and what are they waiting for (what should wake them up)? What have you found by debugging?

[mnor]

Hello,

We've seen it in sample applications (peripheral UART) and in our own firmware. The threads that are not waking up have been put to sleep with "k_msleep()". Threads that wait on OS mechanisms such as semaphores or queues appear to be waking up.

The affected threads include "main", which is in a simple loop toggling an LED every second. As I mentioned, it appears to only affect threads that have been put to sleep for a number of milliseconds.

At some point, the threads that are asleep don't wake up. The most obvious thread is "main" because the LED stops blinking. When I stop the processor, the firmware is in the idle code "cpu_idle.S".

This only occurs when BT NUS is enabled and connected. It can also take a minute to over 10 minutes to occur. If the nRF52840 is only advertising NUS, then the problem does not occur.

I've been working with the nRF5340 and not seen this problem. It seems to only affect the nRF52840, but in SDK versions above 1.8.0.

Thanks,

Mike Norton

[Einar Thorsrud]

Hi Mike,

This seems very odd, but I have not been able to reproduce or find any other reports of this behavior. Can you provide detailed examples on how to reproduce? Some thing like:

1. use specific sample from specific SDK release
2. do these specific changes
3. test in this specific way, and
4. observe this specific result (failure)

[mnor]

Hi Einar,

Thanks for the response. Sorry for the delay on my end, but things got busy. I will follow your advice and post my results.