Clock skew under temperature for UART and PWM

[eb12345]

I am using an nrf52833 with both 32.768 kHz and 32MHz external crystals (identical to the DK). When I go down to -30 deg C, the uart stops working. I believe that this is due to frame errors having to do with clock skew. Interesting enough, when I plug the usb cable (data only), the uart communications started up again.

In order to confirm a clock skew, I used a gpio pin as output of a pwm at 1mSec. I observed an increasing pwm output of 1.03-1.07msec. When usb was plugged in, the pwm output was exactly 1.00msec.

Not sure why this is happening, and why it is not happening when USB is connected?

[hmolesworth]

The 32MHz crystal is quite good at low temperatures but the internal 32MHz clock is affected heavily by both temperature and VDD; VDD is propped up by the USB when it is low due to low battery temperature, and that can correct some of the error in the internal 32MHz clock. Given no mention is made of the UART and PWM clock, note that the UART and PWM clock default to the sloppy internal 32MHz clock and not the external 32MHz crystal. Try enabling HFCLK using the external crystal and the issues should go away.

[eb12345]

All the defaults were kept, so it sounds like the internal 32MHz clock is being used. How do I enable the HFCLK using the external crystal ? Is there documentation or example on how to do it on ncs ?

Thank you,

[Vidar Berg]

The crystal oscillator can be requested with this function: https://github.com/nrfconnect/sdk-nrf/blob/6acdd63eb1c31331deb92f2982a279afe6d68f5a/samples/peripheral/radio_test/src/main.c#L32 

[eb12345]

Is there a way to specify the clock that the UART uses, that way when I disable the uart (when not in use), it automatically disables the HF clock ? I assume that the internal clocks are lower power than the external clocks ?

[Vidar Berg]

The HF peripheral clocks are sourced from either HFINT or HFXO, depending on which one is active. Therefore, the UART driver should not force the HFXO off, as it may be required by other modules such as the Bluetooth stack (HFXO must be active when using the RADIO). Instead, it should release its request for the high accuracy clock source via the onoff API. This is what I did in the sample posted here:  RE: Suspending UART Async using PM_DEVICE ACTION_SUSPEND causes crash.