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.