HCI UART Issues on nRF Connect SDK 1.3.0

[Cody]

Hello Nordic Team,

I am having issues with the HCI UART firmware for the nRF52840 on the Thingy91. I have been using the HCI UART firmware from nRF Connect SDK 1.0.0 for some time but recently I ported over the changes from nRF Connect SDK 1.3.0 and I have since ran into issues.

My application is similar to the LTE BLE Gateway application in that I am using the nRF52840 as a bluetooth controller to scan for nearby bluetooth devices. I have also used the patches provided by Sigurd on the following ticket: https://devzone.nordicsemi.com/f/nordic-q-a/52689/nrf9160-lte-sensor-gateway-on-thingy-91/230300#230300 to support this on the Thingy91.

With the nRF Connect SDK v1.0.0 HCI UART firmware, I would occasionally see the following from the RTT logging on the nRF9160:

00> [00:16:23.539,947] <wrn> bt_driver: Discarding event 0x3e

but now with the nRF Connect SDK v1.3.0 HCI UART firmware, I get a bunch of these types of messages printed out (in addition to the message above):

00> [00:17:13.480,102] <err> bt_driver: Not enough space in buffer
00> [00:17:14.016,693] <err> bt_driver: Unknown H:4 type 0x49
00> [00:17:14.017,028] <err> bt_driver: Unknown H:4 type 0x0e
00> [00:17:14.017,364] <err> bt_driver: Unknown H:4 type 0x2f
00> [00:17:14.017,669] <err> bt_driver: Unknown H:4 type 0x6e
00> [00:17:14.018,005] <err> bt_driver: Unknown H:4 type 0xec
00> [00:17:14.018,341] <err> bt_driver: Unknown H:4 type 0x1e
00> [00:16:29.435,485] <wrn> bt_hci_core: Unhandled event 0x01 len 41: 0301da972fdf98fa1e02010403039afe16169afe1181820179ececd817b280e2e31edd480ac101bc04

The behavior of the firmware is also affected -  usually after the "Unhandled event" message as seen above, the bluetooth scan will be provide no results for 30-60 seconds before it recovers. This differs from the nRF Connect SDK v1.0.0 HCI UART firmware, as the bluetooth scan would still provide results regardless of the "Discarded event" message.

Any ideas?

Thank you,
Cody

[Cody]

Hey Hakon,

Sorry for the delayed response, just finally getting back to looking into this.

I don't see any pattern to this issue, I would say that I am in an area with a non-trivial amount of bluetooth devices advertising, I would guess around 50 devices. With that said, my use case is simple, I am only using the nRF52840 to scan for devices and read the advertising packet/scan response packet - no connections are ever being made.

I do see indications of a reboot on the nRF52 side, if I run a simple firmware on the nRF9160 side that enables bluetooth (via HCI UART) and initiates a scan and let that run while debugging the nRF52 side, I do see the chip restarting.

One new piece of information I have is that the HCI UART firmware from nRF Connect SDK v1.0 and v1.1 appear to be working fine, I am trying to confirm at what point the firmware stopped working (currently working on testing v1.2).

UPDATE: Tested nRF Connect v1.2.0, HCI UART firmware still works so it was definitely broken somewhere between the official release of v1.2.0 and v1.3.0.

Thanks,
Cody

[Håkon Alseth]

Hi Cody,

 

Could you try adding this config on the nRF52-side, to force it not to reset if a fault occurs?

CONFIG_RESET_ON_FATAL_ERROR=n

 

In the case of an error, you should get a print out: but if there's no print out, you can enter debug mode and look for a stack frame similar to this:

#3  0x0000fea0 in z_fatal_error (reason=0, esf=0x20001390 <_interrupt_stack+1984>)

Most debuggers let you select the frame in one way or another (right-clicking in the call stack window, selecting the frame) and look into the specific locals.

Here, the debug info is available in the "esf" pointer, with information about where the fault occurred and what the register content was at this time.

 

Kind regards,

Håkon

[Cody]

Hey Hakon,

I added the suggested line of configuration to the HCI UART project. Unfortunately, I did not observe any change in behavior. This may be due to the fact that the chip is not resetting based on an error and instead, is being reset by the nRF9160. In h4.c, in the location where I am seeing the error statements, I see references to a reset_rx() function being called.

Thanks,
Cody

[Håkon Alseth]

Hi Cody,

 

Cody said:

This may be due to the fact that the chip is not resetting based on an error and instead, is being reset by the nRF9160. In h4.c, in the location where I am seeing the error statements, I see references to a reset_rx() function being called.

I must apologise for the late reply. I checked around in support and in R&D, and there has been observed some issues on ncs v1.3.0 wrt. UART stability.

I can confirm that we have seen instabilities lately, and we are working on finding the root-cause. There has been work on trying to re-write the uart transport functions in this PR, but a colleague of mine has tested this just last week, but still saw some issues. If you have a older build of hci_uart that works for now, I would recommend that you stick with this one for the time being.

 

Kind regards,

Håkon

[Cody]

Thanks Hakon,

Do you have a rough time estimate regarding when UART stability will be fixed as well as the introduction of low power UART? These are both incredibly important for our product so if you can keep me in the loop that would be much appreciated. In the meantime, I will continue to use the HCI UART firmware built off of v.1.2.0.

Thanks,
Cody