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.

[Vidar Berg]

Hi,

The HFXO clock should be enabled when UART RX is enabled. I uploaded an example in this post  Suspending UART Async using PM_DEVICE ACTION_SUSPEND causes crash. showing how one can request and release the HFXO source via the onoff API in the nRF Connect SDK.

Ref. https://docs.nordicsemi.com/bundle/ps_nrf52833/page/uarte.html 

Best regards,

Vidar

[eb12345]

That example worked in turning on the HFCLK. I am able to use the UART all the way down to -40 deg C. For some reason, even though I release the HFCLK like your example, the current consumption does not go back down into the uA like expected. If I don't request and release the HFCLK (code I had before starting this thread), then the sleep currents are ok. My assumption is that something is holding the HFCLK (not the UART since I'm suspending it). Is there a way to check what is holding the HFCLK from being disabled ? Did you ever notice this behavour ?

[Vidar Berg]

What sleep current do you measure with this implementation? If the HFXO is left running but not sourced to any peripheral, the idle current should be around 200 µA. However, if the HF clock is requested by a peripheral such as UART, TIMER, etc., it will exceed 500 µA.

[eb12345]

The difference is about 1.5mA. Same code without ever requesting the HFXO and releasing it is 30uA. Interesting enough, the same thing happens if I plug in the USB and then unplug it. Something is not releasing the HFXO, or is being turned on in the process.

[Vidar Berg]

I think the discrepancy is too big to caused by the clock source. Do you have a 52833 DK you can test this on for comparison? The System run current in idle and UARTE enable should not exceed 1 mA regardless of whether you are using HFINT or HFXO.

Another thing you can to do troubleshoot this is to read out the following registers with the debugger:

• HFCLKSTAT - check if xtal is enabled
• UARTE.ENABLE - check if UARTE instance is enabled

[eb12345]

Thank you for helping with the troubleshooting steps and register definitions. Turns out the HF crystal in this last batch/build was installed incorrectly. When I tried to request the HFCLK, it was failing, which caused the 1mA additional current. Once I fixed the crystal issue, the current comes back to 30uA.