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

[jpo38]

Hi,

no, I could not reproduce the issue when I was using the sniffer. I'll try to test with "nRF Connect" and or Android app, see if it the same problem occurs (then it will prove the problem is not related to pc-ble-driver). I'll also try with the sniffer again.

Regards,

Jean

[jpo38]

I tried to put my computer in standby while a device was connected. This reports exactly the same message "State change: STATE_ACTIVE -> STATE_RESET" when the computer wakes up.

Surprisingly, in the log I sent, this message is reported less than 1sec after a notification, so this is likely not due to the computer going to standby (else, the message would appear when the computer wakes up, long after the last notification). But the log looks similar, as if Windows for an aunnown reson unpowered the dongle for some time, and this made it reset.

Also, I notice that before the state is changed to STATE_RESET, we receive:

[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]

There is no such event before. Any clue what could make this LINK_CONTROL_PACKET be received?

Kind regards,

Jean

[tesc]

Hi,

The LINK_CONTROL_PACKET messages are used for setting up the UART communication between the connectivity device and the pc, so it means the connection has been lost.

The direction of the particular message ("<-") is from the pc to the connectivity device. This is consistent with the connectivity device having lost power so that the connection is lost and the pc tries to reestablish the connection.

It is not unusual that USB ports are powered off when entering a sleep state.

Are you still seeing issues that are not related to putting your pc to standby?

Regards,
Terje

[jpo38]

I have to check. This is most likely the root cause of the issue, Windows turning OFF the USB. But the computer is configured not to go to stand by. So we need to figure out what's going on. When I'm 100% sure this is a Windows/standby issue and not a dongle/SD problem, I'll update the ticket.

Kind regards,

Jean

[tesc]

Hi,

Did you reach a conclusion?

There are some potential issues when the mass storage device on the programmer mcu is enabled, which it is by default. This may be either the operating system trying to defragment the device, or antivirus software trying to quarantine it. (I am not sure if we have experienced the latter on the nRF51 dongle, but I think we have seen it on the nRF91 DK.) Use J-Link Commander and run the command MSDDISABLE to configure the dongle not to appear as a USB device. (If you need to enable it again at a later point then you can do so with the command MSDENABLE.)

Regards,
Terje