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

[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.

[Hieu]

Right. The value used in the UART documentation and drivers are not the best value. But the ones used in the UARTE docs and drivers should be better.

I believe hmolesworth discussed that in depth here:  RE: Technical question regarding UART baud rate generator (BAUDRATE register, offset 0x524) .

Damon Liu How about lowering the baud rate? At lower baud rate, the lower accuracy of HFINT could be less impactful. However, please note again that this is not what the UART peripheral was designed to run with, so we cannot guarantee long term reliability.

[Damon Liu]

Thank you for your suggestion, but I observed an anomaly under the condition of a baud rate of 9600

[Damon Liu]

The baud rate is 9600 right now, so lower baud rate may not solve my problem. The power I mentioned refers to the average value over a period of time, so suspending the UART when it is not working will result in an average value much less than 600uA and is acceptable.  So what I need to do is switch HFINT to HFXO, so that UART can work properly. Do you think this method is feasible?

[Hieu]

Right, and for baud rate 9600, the issue that hmolesworth mentioned is not relevant, so we don't have anything to improve in this direction.

Damon Liu said:

The power I mentioned refers to the average value over a period of time, so suspending the UART when it is not working will result in an average value much less than 600uA and is acceptable.  So what I need to do is switch HFINT to HFXO, so that UART can work properly. Do you think this method is feasible?

If the suspending then resuming strategy works for you, I think you should use it. Especially when it still satisfies your power requirement when HFXO is in used.

Is this the answer you are looking for or did I misunderstand the question?

[hmolesworth]

Quite, at 9600 the frequency is unlikely to be an issue. Worth checking something else when waking from sleep; depending on the driver sometimes I see unexpected events incorrectly left enabled. In the case of EVENTS_CTS this is always set by hardware regardless of whether the HW flow control is ever used or not. Maybe capture these registers and print values:

Event:  CLOCK->EVENTS_HFCLKSTARTED      0x4000'0100 = 1 (No Enable Field)       IntEnable 0x4000'0300=         0
Event:  CLOCK->EVENTS_LFCLKSTARTED      0x4000'0104 = 1 (No Enable Field)       IntEnable 0x4000'0300=         0
Event:  POWER->EVENTS_SLEEPENTER        0x4000'0114 = 1 (No Enable Field)       IntEnable 0x4000'0300=         0
Event:  UARTE->EVENTS_CTS               0x4000'2100 = 1 Enable 0x4000'2500=0x00 IntEnable 0x4000'2300=         0, Shorts 0x4000'2200=0
Event:  UARTE->EVENTS_TXDRDY            0x4000'211C = 1 Enable 0x4000'2500=0x00 IntEnable 0x4000'2300=         0, Shorts 0x4000'2200=0