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

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

Damon Liu — Mon, 22 Apr 2024 09:04:09 GMT

OK, thanks for help

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

Damon Liu — Mon, 22 Apr 2024 09:03:52 GMT

OK, thanks for help

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

hmolesworth — Fri, 19 Apr 2024 15:56:34 GMT

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

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

Hieu — Fri, 19 Apr 2024 13:58:59 GMT

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.

[quote user="Damon Liu"]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?[/quote]

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?

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

Damon Liu — Fri, 19 Apr 2024 02:09:53 GMT

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?

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

Damon Liu — Fri, 19 Apr 2024 01:52:45 GMT

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

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

Hieu — Thu, 18 Apr 2024 13:01:00 GMT

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.

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

hmolesworth — Wed, 17 Apr 2024 18:32:47 GMT

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.

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

Hieu — Wed, 17 Apr 2024 18:24:54 GMT

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.

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

Damon Liu — Thu, 11 Apr 2024 06:31:13 GMT

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.

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

Hieu — Tue, 09 Apr 2024 11:18:32 GMT

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

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

Damon Liu — Tue, 09 Apr 2024 02:21:10 GMT

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.

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

Hieu — Tue, 19 Mar 2024 11:47:35 GMT

Hi Damon,

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

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

Damon Liu — Tue, 19 Mar 2024 05:03:29 GMT

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

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

Hieu — Mon, 18 Mar 2024 10:49:56 GMT

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:

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

[quote user=""]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.[/quote]

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