nRF52840DK uart - 921600 not working

[Stig24]

I’m using the nRF52840DK to communicate with a module over uart. My problem is that the module has a baud rate of 921600 and as far as my understanding the nRF52840 is using a baud rate of 941176 when set to 921600.  This leads to my commands (13 bytes) only works around 10-20% of the times, and the data received is not as expected (startbytes etc.).

I have tried using nrf_serial_flush as well but then nothing works. Also tried setting the baud rate manually without succeeding.

Any tips?

[Einar Thorsrud]

Hi,

The UART peripheral only supports some baud rates, but if you are close enough and the transfers are short enough it should be OK. It could be that there are other factors here as well. First of all, make sure you start the HFXO on the nRF. Without it you are using the HFINT, and  the frequency could be quite off (worst case up to ±8 % on the nRF52840, as you can see form the electrical specifications).

[Stig24]

Is it possible to measure the external clock frequency?

[Einar Thorsrud]

The HFXO frequency? Not directly (probing on the crystal will shift the frequency), but you can output a fraction of the frequency using a TIMER and GPIOTE connected via PPI. And then use a frequency counter to measure it.

That is probably overkill for this, though. A simple way to check if the frequency is sensible (and more than enough for UART) is to just program a BLE peripheral example and try to connect to it. If that works, it must be more or less as it should be, as if not the radio frequency would be too much off.

[Stig24]

I see, do you have an example code for this?

You mention that the baud rate was due to a WH limitation, can you elaborate more?

[Einar Thorsrud]

Stig24 said:

I see, do you have an example code for this?

There are many implementation on DevZone. The first that came up for me now was this. In principle it works on the nRF52 as well, but I did a few minor changes to make it work out of the box with the latest nRF5 SDK (17.1.0):

#include <stdint.h>
#include "boards.h"

int main(void)
{
    nrf_gpio_range_cfg_output(LED_1, LED_2); 
    nrf_gpio_pin_clear(LED_1);
    
    NRF_CLOCK->TASKS_HFCLKSTART = 1;
    while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0)
    {
    }
    NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
    
    NRF_GPIOTE->CONFIG[0] = GPIOTE_CONFIG_MODE_Task << GPIOTE_CONFIG_MODE_Pos |
                            GPIOTE_CONFIG_POLARITY_Toggle << GPIOTE_CONFIG_POLARITY_Pos |
                            LED_2 << GPIOTE_CONFIG_PSEL_Pos | 
                            GPIOTE_CONFIG_OUTINIT_Low << GPIOTE_CONFIG_OUTINIT_Pos;
                            
    NRF_TIMER1->PRESCALER = 0;
    NRF_TIMER1->CC[0] = 1;
    NRF_TIMER1->SHORTS = TIMER_SHORTS_COMPARE0_CLEAR_Enabled << TIMER_SHORTS_COMPARE0_CLEAR_Pos;
    NRF_TIMER1->TASKS_START = 1;
    
    NRF_PPI->CH[0].EEP = (uint32_t) &NRF_TIMER1->EVENTS_COMPARE[0];
    NRF_PPI->CH[0].TEP = (uint32_t) &NRF_GPIOTE->TASKS_OUT[0];
    
    NRF_PPI->CHENSET = PPI_CHENSET_CH0_Enabled << PPI_CHENSET_CH0_Pos;
    
    while (true)
    {
        
    }
}

Stig24 said:

You mention that the baud rate was due to a WH limitation, can you elaborate more?

Unfortunately I cannot disclose implementation details.

[Stig24]

Einar Thorsrud said:

24 said:

You mention that the baud rate was due to a WH limitation, can you elaborate more?

Unfortunately I cannot disclose implementation details.

Could you explain what WH is short for? can not find a good explanation.

[Einar Thorsrud]

Sorry, that was a typo. Should be HW for hardware