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

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

Thomas Kolb — Thu, 22 Sep 2022 10:25:00 GMT

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.

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

Einar Thorsrud — Wed, 21 Sep 2022 13:03:14 GMT

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).

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

Thomas Kolb — Tue, 20 Sep 2022 14:56:27 GMT

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…

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

Einar Thorsrud — Tue, 20 Sep 2022 13:17:22 GMT

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.