STM32WB5x BLE OTA gets stuck mid-update with no way to reconnect — is a firmware-side timeout/reset the right approach?

[MinhLuu]

Setup:
MCU: STM32WB5x (WB55 in particular)
Performing OTA firmware update over BLE, using a custom OTA service/characteristics (based on the STM32WB Cube OTA support), sending firmware in chunks after the device reboots into OTA/bootloader mode.
Client app: Android, iOS app

Problem:
During an OTA session, if the connection between the client and the device is interrupted (e.g. chunk write failure or stuck, or the client fails to resume sending data) while the device is already in OTA mode, the device gets stuck — it stays in OTA mode waiting for the remaining firmware data, but no new connection can be established to resume or restart the transfer. The device appears to remain advertising/connectable at the BLE stack level in some cases, but the OTA session itself cannot be recovered or restarted from the client side once this happens, effectively bricking the update flow until a manual power-cycle.

Question:
To make the OTA process self-recoverable, I'm considering adding a timeout mechanism on the firmware side while in OTA mode: start a timer (e.g. 60 seconds) as soon as the device enters OTA mode, and reset/kick the timer each time a valid firmware chunk is received. If the timer expires with no new data received, the firmware would trigger a reset (either restarting the BLE stack/advertising, or a full MCU reset via NVIC_SystemReset()) so the device becomes connectable/updatable again.

Is there a recommended/existing timeout or watchdog mechanism already built into the ST OTA support code (or IPCC-based OTA flow) for this exact scenario, rather than implementing a custom one?
Any guidance on the correct/recommended way to make OTA mode recoverable after a stalled/interrupted transfer would be appreciated.

Thanks,

[MinhLuu]

My goal is just to make the device advertise again so the app can reconnect and try again to update, not necessarily to restore the exact previous state.
 

[Dominique FOLLEZOUR]

Hi

 

I assume you follow Guidelines for over-the-air application and wireless firmware update for STM32WB series microcontrollers - Application note and associated sample code.

 

If for some reasons during OTA the link is disconnected with client due to RF range, or battery power concern, the WB55 OTA peripheral will start back advertising. However here you concern is that link is still alive, so connection still alive between wb55 and client but for some reasons data can not be transmitted.

In FOTA process, client send data to peripheral using write without rsp procedure so indeed there will be no flow control, and once file has been transferred, peripheral will send indication to client that full file has been received.

 

If for some reasons client is in stuck state and no more sending data to peripheral here indeed a timeout mechanism is required to make sure peripheral move back to advertising. That’s been said, this is non expected as we should not expect either peripheral or client to enter in “stuck”state while gatt transferred are ongoing.

Let us know.

Br

Dominique

[MinhLuu]

Please confirm whether it is possible to add a timeout mechanism to handle cases where the device remains in OTA mode. If so, how should we implement this mechanism?