I have an application where knowledge of the current date/time is important. This is implemented by the central passing the time to the peripheral when it initially connects and then maintaining locally on the peripheral via the RTC.
However, the default action in the SDK examples for an SDK error is to reset the device. When this happens the time tracking on the peripheral is lost. I am gradually working through all the corner cases where errors are returned during "normal" operation - the SDK examples don't seem particularly robust in that regard, especially when the link between peripheral and central is strained (e.g. due to distance). For example several of the call back routines associated with peer manager assume the connection to be valid when there are cases where the connection may have dropped during peer negotiation (possibly due to an interrupt race condition - it is difficult to tell even with the debugger attached). This then results in an invalid connection error being reported by the peer manager which is resetting the device.
I would like to know if there is a more graceful way to handle SDK errors while maintaining application state - for example by resetting the soft device and reinitialising the BLE stack?
If not then what are the critical error cases where the device MUST be reset in order to ensure it can recover to a valid state.
