btt_gatt_write in nus_c never gets reply

[Jared]

I'm currently running on nRF Connect SDK (hash: 4b012fb4882f0ddd3de9f339ebc5a3f1c3cacd4a). I'm running a connection between a nRF91+nRF52840 (as central running NUS_C) using HCI plus a separate nRF52840 (as peripheral running NUS service).

For the most part, the notifications coming from the peripheral are spot on. The device has consistently sent thousands of messages with no problem. On the other side though, sometimes the NUS_C_RX_WRITE_PENDING flag never gets cleared. This means the on_sent callback never gets called. I'm at a loss as to why this may be happening. Is there anything I can do to figure out where it's getting stuck in the process? It seems silly to reset the connection if the write gets "stuck".

Thanks!

[Jared]

I will add that when I reset the connection, things "go back to normal" where messages are exchanged in both directions. (Until the next time a reply doesn't occur..)

[Jared]

This may be a product of the HCI over UART. Is flow control still supported. I know that it now should use the pins defined in the device tree?

Here's my .overlay

/ {
	chosen {
		zephyr,bt-uart=&uart2;
	};

};

&uart2 {
	compatible = "nordic,nrf-uarte";
	current-speed = <1000000>;
	status = "okay";
	tx-pin = <24>;
	rx-pin = <23>;
	rts-pin = <29>;
	cts-pin = <30>;
};

[Simon]

Have you tried to debug your project? E.g. set a breakpoint in on_sent(), get the call stack and check where it's called from, which may help you get to the bottom of this. You could also try to capture a sniffer trace, to see if the message is actually sent.

If this didn't help and you're not able to make any progress, please tell me and I will take a closer look at it.

Best regards,

Simon

[Jared]

Hey Simon,

For context, I'm sending it another nRF52840 which is not operating in HCI-UART mode. When I increased the transmission frequency, there were a ton of HCI-UART related errors. So things are not getting processed fast enough or UART bytes are getting dropped. Very funky.

Thanks again

[Simon]

Hmm... I'm not sure what's causing this. The baud-rate is quite big and should not be the bottleneck. Maybe some buffers are overflowing? I will take a look at it/ask internally, and see if I can get to the bottom of it.

Best regards,

Simon