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

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

mnor — Thu, 13 Oct 2022 22:52:08 GMT

I've made some progress debugging this issue. I started with version 2.1.0 of the SDK and a sample project from the same SDK called "shell_bt_nus". This sample works fine.

I then added some of our UART interface code to the shell_bt_nus sample. This code uses UART_1 and the UART asynchronous driver provided by Nordic. This caused the problem. Upon further investigation, I found that the issue is caused by using the UART asynchronous driver provided by Nordic in SDK version 2.1.0. When I changed the code to use the UART interrupt driven driver from the Nordic SDK then the problem did not occur.

I still don't know why this is happening with the UART asynchronous driver, but as least I've got a workaround by using a different version of the UART driver.

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

mnor — Wed, 05 Oct 2022 23:49:11 GMT

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.

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

Einar Thorsrud — Fri, 30 Sep 2022 12:16:28 GMT

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:

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

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

mnor — Thu, 29 Sep 2022 14:04:02 GMT

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

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

Einar Thorsrud — Thu, 29 Sep 2022 10:52:24 GMT

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?