nRF52840 UART Transition Issues

[BAEE]

We are having issues with UART communication on the nRF52840. Using a logic analyzer, we have found that the transitions happen too quickly. This causes the receiving MCU to read incorrect bits most of the time depending on where the transition lands. Is there a work around for this? Thanks.

[Einar Thorsrud]

Hi,

I am having problems understanding how "transitions happen too quickly", but it makes me think that you are talking about a situation where there are timing problems so that sampling happens too late, or similar? If so, I suspect one of two problems:

• you have not configured the same baud rate in both devices, or
• the clock drifts too much between the devices. For instance, you should consider enabling the crystal oscillator, since the RC oscillator may not be accurate enough (at least with high baud rates).

[BAEE]

I also believe it may be that the clock drifts too much between devices.  However, unless we did something wrong, we attempted to select the crystal oscillator and it didn't seem to help the problem.  Do you have some instructions for selecting the crystal oscillator?

[awneil]

It's still not clear what, exactly, your problem is!

BAEE said:

the crystal oscillator

Which one - on the nRF, or on the other MCU.

UART comms requires that both sides of the link have accurate clocks.

[BAEE]

The problem seems that when going from example a 0 to a 1, the transition happens right on the boundary of when the other MCU is determining the value of the 0 bit position.  Sometimes, the other MCU recognizes the bit as a 0 and sometimes it recognizes it as a 1 because the value transitioned to the 1 a little early.  I have connected two of the other type of MCUs and they always work correctly.  

[awneil]

Sounds like a bug in the other MCU - a UART should be sampling at the centre of the bit ...

Are you doing a software (bit-banged) UART on the other MCU ... ?

[BAEE]

On further investigation, it seems that the Nordic is running at 116504 baud even though we have it set to 115200.  The other MCU is running at 115163 baud.

[Einar Thorsrud]

Then it looks like you need a more accurate clock source on the nRF. The cleanest approach would probably be to use the clock driver and call nrf_drv_clock_hfclk_request().

[BAEE]

Thanks, we will try that.

[BAEE]

OK, so we were finally able to select the XTAL as the clock source and everything works great.  The following code was added to the config file to accomplish this.

#ifndef NRF_CLOCK_ENABLED

#define NRF_CLOCK_ENABLED 1

#endif

 

#ifndef NRFX_CLOCK_CONFIG_IRQ_PRIORITY

#define NRFX_CLOCK_CONFIG_IRQ_PRIORITY 6

#endif

 

#ifndef NRFX_CLOCK_CONFIG_LF_SRC

#define NRFX_CLOCK_CONFIG_LF_SRC 1

#endif

 

 The following code was added to the main file:

 

    nrf_drv_clock_init();

 

    nrf_drv_clock_hfclk_request(NULL);

 

 

[Einar Thorsrud]

I am glad to hear that worked. And thank you for the detailed update! Such updates can be very useful for others when looking for a solution to a similar problem.

[BAEE]

Can you please tell me exactly which crystal/oscillator this selects on the schematic?

[Einar Thorsrud]

Yes, calling nrf_drv_clock_hfclk_request() starts the 64 MHz oscillator, which uses the 32 MHz crystall.