Detect LFXO tampering or improve LFRC tolerance

[Pascal Künzi]

Hi there,

We had a setup that runs the RTC with the LFXO.
Tampering with the XL1 and XL2 signals allowed to increase/decrease the clock speed. This wouldn't be so bad.

Unfortunately, the LFXO can also be fully stopped, which then "paused" the watchdog and RTC peripheral. Also the SoftDevice is "paused" depending on the executed BLE functionality. As soon as the LFXO is released, the peripherals and SoftDevice continue as nothing happened.

As long as the nRF is running, the LFXO clock could be verified with the RTC counter value and using the HFXO and a TIMER as a reference.

Once entering system on low power mode, this is no longer possible. If the nRF is configured to wakeup on a RTC event, this could be "paused" and postponed to be triggered at a later point in time.

Is it possible to detect such tampering? Or is the nRF expected to just continue running?

If tampering on the LFXO can't be detected, is there a possible way to improve the LFRC tolerance?

For example by using a more accurate 32MHz crystal?

Which factors lead to the max. ±500ppm tolerance of the LFRC?

Thank you in advance!

Regards,
Pascal

[Simonr]

Hi Pascal

No, if the only source running is the LFXO clock, the nRF won't have a way of detecting if it's been tampered with I'm afraid. When the CPU is running, you should indeed be able to use the HFXO or HFINT as "sanity checks" for the LFXO, but when everything else sleeps it can be tampered with without the nRF52 knowing.

Unfortunately the physical properties of the LFRC oscillator will be ±500ppm regardless of how it's configured or what HF crystal you use. I must say I don't see a way that tampering with the LFXO while it's sleeping would be an issue for a product, but I guess the way to both have good tolerance and be safe from tampering would be to use the synthesized LF clock (LFSYNTH) from the HFINT. This will draw more power than the other two options. Seems like a dilemma where you can't have your cake and eat it too unfortunately...

Best regards,

Simon

[Pascal Künzi]

Hi Simon

Thank you for the fast reply and your answers!

At least we now know, that this is the expected behavior. There are less convinient workarounds but that is ok.

Regards,
Pascal