Soft reset of connectivity chip in serialized application (via SER_GENERIC_CMD_SOFT_RESET)

[Thomas Kolb]

Hi,

we use the NRF52840 as a connectivity chip in a serialized application (based on nRF5-SDK v17.1.0 and SoftDevice S140).

When our main app starts, we would like to reset the SoftDevice (BLE Stack) so we have a known state. The connectivity firmware additionally maintains a USB connection, which should stay available during the reset, if possible. We found that sending the following packet to the connectivity chip does basically what we want (that is, restart the SoftDevice only):

 uint8_t reset_command[4] = {0x02, 0x00, SER_PKT_TYPE_GENERIC_CMD, SER_GENERIC_CMD_SOFT_RESET}; 

This works as intended if there are no active connections or all active connections are idle. However, if a peripheral continuously sends notifications at a high rate, the connectivity firmware crashes during the reset. Here are the steps to reproduce (from the application’s point of view):

1. First application run after power-on:
   1. Open serialization channel
   2. Send reset command (as defined above)
   3. Set up BLE (some calls to sd_ble_cfg_set() and finally sd_ble_enable())
   4. Scan for a device
   5. Connect to the device
   6. Enable notifications
   7. Process notifications
2. Close the application (without closing active BLE connections or disabling notifications; this might also be a crash of the application)
3. Second run with the connectivity chip still busy:
   1. Open serialization channel
   2. Send reset command
   3. Set up BLE
   4. <no response from connectivity chip>

The connectivity chip produces the following log between steps 3.b and 3.c:

<info> app: reset ongoing
<info> app: Dropping BLE event (during reset).
<info> app: Dropping BLE event (during reset).
[10 repetitions removed]
<info> app: Dropping BLE event (during reset).
<error> app: ERROR 12289 [Unknown error code] at ./nrf5-sdk/components/softdevice/common/nrf_sdh_ble.c:315
PC at: 0x000397D9
<error> app: End of error report

The error code is 0x3001 [BLE_ERROR_NOT_ENABLED] and the description says that sd_ble_enable() has not been called. That is obviously correct at this point because the SoftDevice was just disabled and re-enabled. However, it looks like some of the notifications still hang in some queue after the SoftDevice is disabled and are processed once it is enabled again.

Is this a bug or can we change something in our application code to avoid this problem, apart from doing a full chip reset?

Thanks

Thomas

[Einar Thorsrud]

Hi Thomas,

I must admit I am not sure why this feature of disabling the SoftDevice (SER_GENERIC_CMD_SOFT_RESET) exists, nor does it seem clear that disabling/reenabling of the SoftDevice is fully supported in the connectivity firmware. I would suggest that you do a proper reset of the connectivity device in these cases instead, using sd_rpc_conn_reset(). Why do you want to avoid a full reset in this case (when you anyway want to reset the SoftDevice)? With a full reset you will achieve your goal of getting the device in a known state.

[Thomas Kolb]

Hi Einar,

thanks for your fast response. We are developing a USB dongle specifically tailored to be used with our own BLE peripherals. The NRF52840 on the dongle exposes some additional hardware to the host computer via USB and also provides access to the serialized SoftDevice API via native USB (we wrote a custom ser_phy module for that). That means the host PC is basically our application processor and the dongle is the connectivity chip.

It would be nice if we could avoid the USB re-enumeration caused by the full reset. The SER_GENERIC_CMD_SOFT_RESET seems to provide exactly that, but if it is not really supported and there is no way around the problem above, we will have to live with the full reset…

[Einar Thorsrud]

I see. I do not have much to add at the time being, unfortunately.

I want to mention though that if you are in the beginning of development and want something more future-proof, then it could be an idea to consider the approach of using the Bluetooth shell (see for instance this post).

[Thomas Kolb]

Ok, thanks for the hint about the Bluetooth shell. Unfortunately, I don't have any experience with the nRF Connect SDK yet, so switching to that is not easy right now. I'll keep it in mind for future developments/updates.

Regarding the original reset problem, I think we can find a suitable workaround.