What could make the SoftDevice reset without being asked to?

[jpo38]

We have a nRF based device being connected from a nRF51 dongle (PCA10031). We use pc-ble-driver 2.2.1.

We enable notifications and then we let the device running for a long time. At some point, we stop receiving any notifications, buy checking the log, we can se:

[12:03:23.446] Received notification, handle: 0x0023, value: 0xB7 0x04 0x1E 0x0F 0x00 0x00 
[12:03:23.466] NRF Log:94910/ 0 <-  [02 39 00 00 00 00 00 00 00 23 00 01 06 00 b9 04 79 0f 00 00 ] type:     VENDOR_SPECIFIC reliable:yes seq#:7 ack#:2 payload_length:14 data_integrity:1 header_checksum:da err_code:0x0
[12:03:23.646] NRF Log:   94906 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:0 payload_length:0 data_integrity:0 err_code:0x0
[12:03:23.646] Received notification, handle: 0x0023, value: 0xB9 0x04 0x79 0x0F 0x00 0x00 
[12:03:23.656] NRF Log:94911/ 0 <-  [02 39 00 00 00 00 00 00 00 23 00 01 06 00 b9 04 79 0f 00 00 ] type:     VENDOR_SPECIFIC reliable:yes seq#:7 ack#:2 payload_length:14 data_integrity:1 header_checksum:da err_code:0x0
[12:03:23.656] NRF Log:   94907 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:0 payload_length:0 data_integrity:0 err_code:0x0
[12:03:23.656] NRF Log:94912/ 0 <-  [02 39 00 00 00 00 00 00 00 23 00 01 06 00 b9 04 79 0f 00 00 ] type:     VENDOR_SPECIFIC reliable:yes seq#:7 ack#:2 payload_length:14 data_integrity:1 header_checksum:da err_code:0x0
[12:03:23.656] NRF Log:   94908 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:0 payload_length:0 data_integrity:0 err_code:0x0
[12:03:23.656] NRF Log:94913/ 0 <-  [02 39 00 00 00 00 00 00 00 23 00 01 06 00 b9 04 79 0f 00 00 ] type:     VENDOR_SPECIFIC reliable:yes seq#:7 ack#:2 payload_length:14 data_integrity:1 header_checksum:da err_code:0x0
[12:03:23.656] NRF Log:   94909 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:0 payload_length:0 data_integrity:0 err_code:0x0
[12:03:23.656] NRF Log:94914/ 0 <-  [02 39 00 00 00 00 00 00 00 23 00 01 06 00 b9 04 79 0f 00 00 ] type:     VENDOR_SPECIFIC reliable:yes seq#:7 ack#:2 payload_length:14 data_integrity:1 header_checksum:da err_code:0x0
[12:03:23.656] NRF Log:   94910 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:0 payload_length:0 data_integrity:0 err_code:0x0
[12:03:23.766] NRF Log:94915/ 0 <-  [01 7e ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:2 data_integrity:0 err_code:0x0 [SYNC]
[12:03:23.766] NRF Log:State change: STATE_ACTIVE -> STATE_RESET

[12:03:23.766] NRF Log:   94911 ->  [N/A] type:          RESERVED_5 reliable: no seq#:0 ack#:0 payload_length:0 data_integrity:0 err_code:0x0
[12:03:24.036] NRF Log:94916/ 0 <-  [01 7e ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:2 data_integrity:0 err_code:0x0 [SYNC]
[12:03:24.036] NRF Log:94917/ 0 <-  [01 7e ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:2 data_integrity:0 err_code:0x0 [SYNC]
[12:03:24.046] NRF Log:94918/ 0 <-  [01 7e ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:2 data_integrity:0 err_code:0x0 [SYNC]
[12:03:24.056] NRF Log:94919/ 0 <-  [01 7e ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:2 data_integrity:0 err_code:0x0 [SYNC]
[12:03:24.066] NRF Log:94920/ 0 <-  [01 7e ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:2 data_integrity:0 err_code:0x0 [SYNC]
[12:03:24.076] NRF Log:State change: STATE_RESET -> STATE_UNINITIALIZED

[12:03:24.076] NRF Log:94921/ 0 <-  [01 7e ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:2 data_integrity:0 err_code:0x0 [SYNC]
[12:03:24.076] NRF Log:   94912 ->  [01 7e ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:2 data_integrity:0 err_code:0x0 [SYNC]
[12:03:24.076] NRF Log:   94913 ->  [02 7d ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:2 data_integrity:0 err_code:0x0 [SYNC_RESP]
[12:03:24.076] NRF Log:94922/ 0 <-  [01 7e ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:2 data_integrity:0 err_code:0x0 [SYNC]
[12:03:24.076] NRF Log:   94914 ->  [02 7d ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:2 data_integrity:0 err_code:0x0 [SYNC_RESP]
[12:03:24.086] NRF Log:94923/ 0 <-  [02 7d ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:2 data_integrity:0 err_code:0x0 [SYNC_RESP]
[12:03:24.086] NRF Log:94924/ 0 <-  [03 fc 11 ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:3 data_integrity:0 err_code:0x0 [CONFIG [ sliding-window-size:1 out-of-frame:0 data-integrity-check-type:1 version-number:0 ]]
[12:03:24.086] NRF Log:State change: STATE_UNINITIALIZED -> STATE_INITIALIZED

[12:03:24.086] NRF Log:   94915 ->  [03 fc 11 ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:3 data_integrity:0 err_code:0x0 [CONFIG [ sliding-window-size:1 out-of-frame:0 data-integrity-check-type:1 version-number:0 ]]
[12:03:24.086] NRF Log:   94916 ->  [04 7b 11 ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:3 data_integrity:0 err_code:0x0 [CONFIG_RESP [ sliding-window-size:1 out-of-frame:0 data-integrity-check-type:1 version-number:0 ]]
[12:03:24.096] NRF Log:94925/ 0 <-  [04 7b 11 ] type: LINK_CONTROL_PACKET reliable: no seq#:0 ack#:0 payload_length:3 data_integrity:0 err_code:0x0 [CONFIG_RESP [ sliding-window-size:1 out-of-frame:0 data-integrity-check-type:1 version-number:0 ]]
[12:03:24.096] NRF Log:State change: STATE_INITIALIZED -> STATE_ACTIVE

But our app did not request the soft device to reset (I d'ont even know how this could be requested).

What could make the dongle reset it's state like that?

Note that we don't even get any BLE_GAP_EVT_DISCONNECTED notification, so our app still believe everything is still fine, while actually the connection was closed for good.

[tesc]

Hi,

This looks like a known issue with earlier versions of pc-ble-driver, which has later been fixed.

There are a few possible workarounds:

A) Use 1M baud rate instead of 115k2, if you can, or
B) Use a newer version of pc-ble-driver. Current latest release is v4.0.0, or
C) You could try with this patch for pc-ble-driver. It is known to work for pc-ble-driver v1, and from what I can tell the affected portion of code is still the same in v2.1.1, but note that we have not tested it for 2.1.1. Line numbers may differ between that patch and your version of pc-ble-driver.

Regards,
Terje

[jpo38]

Hello tesc,

I know: I'm the one who reported the issue leading to this patch ;-). See private ticket https://devzone.nordicsemi.com/support/31970.

But this patch is present in 2.2.1.

I'm already using 1M. I'll give it a try with 4.0.0 and let you know if it is fixed.

Kind regards,

Jean Porcherot

[tesc]

Hi,

Ah, sorry, I see now that the patch was actually present for 2.2.1. Looks like this is a separate issue then.

Hopefully the issue is no longer present in v4.0.0. I know that the team worked on making the serialization more robust for that release.

Regards,
Terje

[jpo38]

Ok, we will try and let you know. Problem is that 4.0.0 is much more stable for high rate devices (see https://devzone.nordicsemi.com/f/nordic-q-a/44922/s140-pc-ble-driver-4-0-0-freezes-when-receiving-too-many-data) and that's why we did not migrate to 4.0.0 yet.

[jpo38]

Hello,

So I did more testing:

- Driver 2.2.1 with nRF51 dongle programmes with API v2
- Driver 4.0.0 with nRF51 dongle programmes with API v2
- Driver 4.0.0 with nRF52 dongle programmes with API v3

All config ended up with a silent disconnection after some time (between 20mn and 40mn).

I'll try to use the sniffer and send some logs soon. Hopefully this may help you identify what's going on?

Kind regards,

Jean Porcherot

[tesc]

Hi,

Did you have any luck with the sniffer?

Regards,
Terje