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

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. 

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related