LFCLK Failsafe

[cole]

Briefly:

1. Is it possible to switch LFCLKSRC to the internal RC from Xtal with WDT or RTC running? It appears I am only able to do this when Xtal is generating LFCLK correctly.

2. Is it possible to successfully disable softdevice (S110 in this case) when an Xtal generating LFCLK is disconnected?

Detail:

I'm using nrf51822 with a 32.768kHz external oscillator for lowest standby power in a portable device.

A few of these devices have been observed to have the crystal come loose during normal use by the end user.

We are using extra space in flash on nrf51822 to maintain a log file. I would like to maintain the integrity of the log file when possible and also log when the crystal comes loose.

When the crystal is disconnected while HFCLK is running (which has been the case for the end users who've seen symptoms of crystal disconnection), I can detect it with a check I've implemented using a TIMER. After detection, ideally I would save to flash any parts of the log that are still only in RAM along with an entry for crystal disconnection.

Additional constraints are that I have softdevice (S110) enabled and WDT running.

softdevice_handler_sd_disable() does not return when called after Xtal disconnection (returns when Xtal is connected), and I'm only able to switch LFCLKSRC to the RC when the Xtal is running normally (confirmed with LFCLKSTAT), so, so far I've only been able to get what I want logged by making calls directly to NVM with softdevice enabled, which is not ideal (according to Nordic).

Is it possible to disable softdevice when LFCLK is frozen after lost external clock source at runtime?

Is it possible to switch LFCLK over to the RC when LFCLK is frozen after lost external clock source at runtime?

[Petter Myhre]

If you try to change the clock source while the SoftDevice is enabled you will get a hardfault, so that is not an option. So softdevice_handler_sd_disable() doesn't return, and I'm assuming that sd_softdevice_disable() doesn't either?

You could access NVM directly, the SoftDevice doesn't stop you from doing this, but I recommend doing some testing. I'm not sure what will happen if the crystal disconnected and connected again.

Another solution may be to have the unlogged data in a section of RAM that is retain through a reset, then when you detect crystal disconnection you can set a bool and reset. On boot you check the bool if there is data that should be written to flash. Then you can even enable the SoftDevice again with the LF RC as source. I haven't tested this, it is just an idea.