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]

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

[Stig24]

I see - by the way - what does nRF52840DK stands for? I assume RF - Radio frequency, DK - development kit, and maybe n = nordic. Haven found any good information on this.

[Einar Thorsrud]

Nobody knows :D Well, almost, at least. There is sort of a system:

• All RF devices made by nordic the last decades has a name starting with nRF (think "Nordic RF").
• The series (or generation if you like) is defined by the first to digits (51, 52, 53 for short range devices).
• And the rest of the numbers are typically so that a higher number is more high-end (think more peripherals and more memory) than the lower number devices.