nRF9160 BLE Gateway using nRF52820

[esisk]

Is it feasible for me to use the 9160 as ble-host and 52820 as ble-controller using just TX and RX lines? (no request or ready lines) My setup is NCS v1.7.0, custom board. I've configured my project to where I get reliable transmissions for around 30 min then my application will crash due to an hci command timing out:

00> ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:305
00>   k_sem_take failed with err -11

The error is sporadic; sometimes happening much sooner or later than 30 min in the lifetime of the boot. I referenced the samples found in samples/nrf9160/lte_ble_gateway and samples/bluetooth/hci_lpuart to get to where I am now, but I'm a little lost with these errors. After looking at this ticket "ASSERTION FAIL [err == 0] k_sem_take failed with err -11" when HCI is used with LP-UART - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com) my assumption is that I should be able to, but maybe I've just set up the UART device wrong. Any guidance would be appreciated

[Albrecht Markus Schellenberger]

Hello Ethan,

Any guidance would be appreciated

I’m not sure if it is possible to run HCI via UART without HW flow control enabled. The HCI UART sample in Zephyr states clearly, that it has to be enabled. I will check with our development team and see if I can get any more input.

Do you have the possibility to run your application on a board that supports HW flow control? It would be interesting to see if you face the same sporadic error there as well.

Regards,

Markus

[esisk]

Hey Albrecht, unfortunately it's not possible for our production application to run on a board that supports HW flow control. Our PCB design has been finalized and we're going to start production soon. I do have some development kits at my office, it'd be quite the task getting the app to run on there though. The ticket I mentioned above states that HW flow control is not required for the hci_lpuart sample.

[Albrecht Markus Schellenberger]

Hello Ethan,

First of all, my apologies for the delayed reply.

esisk said:

The ticket I mentioned above states that HW flow control is not required for the hci_lpuart sample.

Our development team has tested HCI over UART with baud rates up to 115200 kb/s and that seems to work fine. However, without flow control there is a bigger chance of loosing bytes, and HCI does not implement mechanisms to recover from this. So you can basically end up in any bad state, which might explain the error you are facing.

My recommendation would be to test with baud rates < 115200 kb/s and see if that works ok.

Regards,

Markus

[esisk]

No worries Albrecht, I appreciate your help. I actually tested that yesterday, a baud rate of 115200, and the bug has not resurfaced. I'll keep an eye on it but I think the problem just boiled down to the baud rate I was using was too high. I let my HW team know to possibly include two extra lines for UART communication in future board revisions, so we can utilize the low power UART driver. The software choice of the split BLE stack was not known to us at the time of HW design, so we didn't take it into account. Thanks again for your suggestions Albrecht

[Albrecht Markus Schellenberger]

esisk said:

I let my HW team know to possibly include two extra lines for UART communication in future board revisions, so we can utilize the low power UART driver. The software choice of the split BLE stack was not known to us at the time of HW design, so we didn't take it into account.

Thanks a lot for your feedback, Ethan. Yes, that makes totally sense. But I’m glad to hear that you were able to find a solution that might work for you anyway :-)

Cheers,

Markus