NRF52840 UART Rx received data incorrectly when use HFINT internal oscillator as clock source

[Damon Liu]

Hello, I am currently working on nrf52840 using nrf-sdk v2.2. to build a Matter firmware. I encountered an issue that a small number of chips UART received data incorrectly. I obtained the data waveform using an oscilloscope and did not find any abnormalities. 

I use ’mpsl_clock_hfclk_is_running' interface to check if HFXO is enabled, the result is no. Then I try to enable HFXO as clock source and this issue never occurred again.

Given that this issue only occurs in a small number of chips, I believe it is a hardware issue caused by individual differences in the internal oscillators of different chips.

Is my inference reasonable?  Will individual differences in the internal oscillator of nrf52849 lead to unstable serial port timing?

Here are some supplementary information：

Due to the low power consumption requirements of the product. UART enters "sleep" when it is not in use, the RX turns to GPIO mode. When data comming, RX generates a falling edge (UART start bit), triggering a GPIO falling edge interrupt. In interrupt processing, UART will be enabled again. This process is called "wakeup". This issue occurs during the initial wake-up period of UART, and then returns to normal until UART goes back to sleep.

[Hieu]

Hi Damon,

As you have found, on the nRF52840, HFINT is not sufficient for the UART peripheral to work accurately. This is note in the Product Specification:

Note: The external crystal oscillator must be enabled to obtain sufficient clock accuracy for stable communication. See CLOCK — Clock control for more information.

Due to the low power consumption requirements of the product. UART enters "sleep" when it is not in use, the RX turns to GPIO mode. When data comming, RX generates a falling edge (UART start bit), triggering a GPIO falling edge interrupt. In interrupt processing, UART will be enabled again. This process is called "wakeup". This issue occurs during the initial wake-up period of UART, and then returns to normal until UART goes back to sleep.

On the topic of UART clock, I think when the UART work, it is only thanks to a relatively low baud rate. If you use high baud rate, you will start to see more issues.

This is not the topic of discussion, but in the nRF Connect SDK, the OS should by default put the device into an idle low power mode, where UART activity can be maintain without the need to reconfigure UART RX pin like you are describing. Is this not enough?

Hieu

[Damon Liu]

Hi Hier,

Thank you for answering my questions. I will try not to duplicate the configuration of Rx and verify if the power consumption meets our product requirements

[Hieu]

Hi Damon,

Great, please feel free to let me know if you have any related questions

[Damon Liu]

Sorry for the late reply, I have recently tested this issue. I tried to keep UART alive and test the power consumption of nrf52840, the result is above 600uA, which cannot meet our requirement of low power.

[Hieu]

Have you tried to put UART to sleep? Refer to:  How to put the UART to sleep (low power mode)