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) 

[Damon Liu]

You mean 600uA? No, I don't put UART to sleep this time. Because if I put UART to sleep, I need to wake it up when data arrives, otherwise, UART can not receive the data. That's why I mentioned earlier about setting RX to the GPIO during UART sleep, so that when data arrives, UART can be awakened in the falling edge interrupt of GPIO. This is what we talked about at the beginning.

[Hieu]

Hi Damon, my apology for the late reply and for my misunderstanding. I forgot the setup you already have.

If you need lower than 600uA during UART active operation, I am afraid it is not really possible. 

Let's refer to the Current Consumption section of the Product Specification for TIMER. We can see that the current when HFXO is running is typically 646uA. The majority of the consumption is from HFCLK running on external source, UART uses a little less current than TIMER, and thus 600uA is within expectation.

[hmolesworth]

As an aside, what baud rate register value are you using? Probably have to set breakpoint and look at UART baudrate register to be sure, but you could also output register value in logging. Some baud rates were accurately calculated, some not; worth a check.

HFINT works better with accurate setting; 961200 baud (used to) have the biggest error.