Soft Device repeatedly returns NRF_ERROR_RESOURCES on a BLE connection that has become unresponsive

[droberson]

---Hardware---

nRF52840 Rigado Development Kit (Software and pin compatible with the Nordic nRF52840 DK)

---Software---

Keil uVision

Soft Device: S140

SDK: 15.0.0

Device Firmware: Application based on the Nordic UART (NUS) example: nRF5_SDK_15.0.0_a53641a\examples\ble_peripheral\ble_app_uart

PC BLE Client: nRF Connect Bluetooth Low Energy App v2.2.0

--- BLE Connection Settings ---

Connection Interval: 20 ms

Connection Timeout: 4 seconds

MTU size: 247

Packet transmit size: Generally ~228 bytes (Never exceeds 244 bytes)

---Issue---

I am sending a large amount of data over the NUS service for as long as it will run (ideally until a connection timeout, drop, or some other fatal error that forces the client to reconnect). After successfully transmitting packets to nRF Connect for ~10.5 hours, nRF Connect crashes with a solid white screen and becomes unresponsive. You must close the app and reopen it to use it again. My nRF Connect log size is always ~1.2 GB when this happens. On the device side, the Soft Device never detects this BLE link "crash" and every call to ble_nus_data_send() returns NRF_ERROR_RESOURCES. Upon this error, I wait for BLE_GATTS_EVT_HVN_TX_COMPLETE before trying to send again. However, I am never receiving this event and my application keeps looping over ble_nus_data_send() after a timeout of waiting for BLE_GATTS_EVT_HVN_TX_COMPLETE in which it still always returns NRF_ERROR_RESOURCES. I haven't captured any BLE packets using Wireshark and such because I do not currently have those tools set up. I plan to set these up next but I wanted to kick-start this question to see if there is something I am missing or a quick fix perhaps. My only solution at the moment in theory is to start a timer when NRF_ERROR_RESOURCES is received and stop the timer when BLE_GATTS_EVT_HVN_TX_COMPLETE is received. If the timer expires, I will declare a BLE link issue and force a disconnect by calling sd_ble_gap_disconnect(). I haven't tested this yet but I am hoping to use this to get around this issue.

Summary: I would like to know the root cause of this issue and why it seems to happen every time after ~10.5 hours or when the BLE nRF Connect log reaches 1.2 GB. More importantly, I would like to know why the Soft Device doesn't detect this error and force a timeout or disconnect.

Thanks!

[run_ar]

Hi,

Do you see any additional entries in the nRF connect log when this happens?

I would guess nRF connect starts nacking packages. i.e. it is receiving them, but the receive buffers are full, due to an issue writing to the log. So packages are nacked, which will keep the link alive and the tx buffers on the peripheral full.

[droberson]

Hey,

I suspect you are correct. To answer your question, no I don't see any additional entries in the nRF Connect log. The last line in the log is always "<timestamp> INFO Attribute value changed, handle: 0x0F, value (0x): XXXX......" where XXXX is a normal data packet. If I get a chance I will capture packets with Wireshark to confirm. I will mark your response as the answer once I do this.

Thanks!

[droberson]

I wasn't able to confirm that this was the issue due to BLE sniffer problems but I still agree and suspect that you are correct. I have made changes to my code that check for this condition (Ie,a connection watchdog).

Thanks again!