nRF52840DK uart - 921600 not working

RE: nRF52840DK uart - 921600 not working

hmolesworth — Mon, 28 Nov 2022 18:48:03 GMT

Have a look at a couple of links where I posted some comments about using 921,600 baud

technical-question-regarding-uart-baud-rate-generator

RE: nRF52840DK uart - 921600 not working

Einar Thorsrud — Fri, 25 Nov 2022 13:12:05 GMT

Output it via GPIOTE using a timer like I showed? You can't (the math don't add up). That is was not the point with that code.

RE: nRF52840DK uart - 921600 not working

Stig24 — Fri, 25 Nov 2022 12:20:51 GMT

I see, but there is not a way to actually measure the exact 941176?

RE: nRF52840DK uart - 921600 not working

Einar Thorsrud — Fri, 25 Nov 2022 09:44:42 GMT

Aha, I did not notice that. You will not be able to get the exact same frequency. The point was that you can use this to measure the accuracy. The accuracy over time will be the same regardless of the frequency of the toggeling pin (so regardless of the prescaler and CC), as the clock source / oscillator is the same. So this was an answer to how you can measure the accuracy of the HFXO. In short, output a known frequency and use a frequency counter to check the deviation from the intended frequency and the measured frequency. Assuming a perfect frequency counter, this will tell you the accuracy of your HFXO.

RE: nRF52840DK uart - 921600 not working

Stig24 — Fri, 25 Nov 2022 09:25:05 GMT

I tried to reply to the message where you gave me this code:

#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)
    {
        
    }
}

RE: nRF52840DK uart - 921600 not working

Einar Thorsrud — Fri, 25 Nov 2022 09:21:30 GMT

Which prescaler and CC? The only register you can write to to modify the baudrate of the UART or UARTE peripheral is the BAUDRATE register, and you should only use values that are described in the register description in the product specification.

To achieve 941176, write 0x0F000000 (251658240) to the BAUDRATE register as stated in the product specification (typically by setting the sdk_config.h macro for the driver accordingly. Note that if using the UART peripheral instead of UARTE, the value is different (0x0EBED000 = 247386112), which you can also see in the product specification.

RE: nRF52840DK uart - 921600 not working

Stig24 — Fri, 25 Nov 2022 08:53:25 GMT

So I have been adjusting the Prescaler and cc to achieve 941176 in baud rate, but I only manage to achieve 1Mhz and 888Khz. How can I adjust it to achieve 941176?

RE: nRF52840DK uart - 921600 not working

Einar Thorsrud — Sun, 20 Nov 2022 11:21:37 GMT

I cannot disclose details of how tis is implemented internally in the IC.

RE: nRF52840DK uart - 921600 not working

Stig24 — Fri, 18 Nov 2022 06:41:52 GMT

Just to clarify, why can the crystal produce 921600 or more close? 32MHz / 35 =914285 why can't this baud rate be produced? And by the way, my esp8266 uses a 26MHz crystal -> 928571

RE: nRF52840DK uart - 921600 not working

Einar Thorsrud — Mon, 14 Nov 2022 12:34:53 GMT

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.

RE: nRF52840DK uart - 921600 not working

Stig24 — Mon, 14 Nov 2022 11:30:38 GMT

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.

RE: nRF52840DK uart - 921600 not working

Einar Thorsrud — Fri, 11 Nov 2022 13:21:26 GMT

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

RE: nRF52840DK uart - 921600 not working

Stig24 — Fri, 11 Nov 2022 11:53:19 GMT

[quote userid="7377" url="~/f/nordic-q-a/92834/nrf52840dk-uart---921600-not-working/395059"]

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

Unfortunately I cannot disclose implementation details.

[/quote]

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

RE: nRF52840DK uart - 921600 not working

Einar Thorsrud — Thu, 10 Nov 2022 09:40:04 GMT

[quote user="jorgenrs"]I see, do you have an example code for this?[/quote]

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)
    {
        
    }
}

[quote user="jorgenrs"]You mention that the baud rate was due to a WH limitation, can you elaborate more?[/quote]

Unfortunately I cannot disclose implementation details.

RE: nRF52840DK uart - 921600 not working

Stig24 — Thu, 10 Nov 2022 07:10:53 GMT

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?

RE: nRF52840DK uart - 921600 not working

Einar Thorsrud — Tue, 25 Oct 2022 11:44:29 GMT

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.

RE: nRF52840DK uart - 921600 not working

Stig24 — Tue, 25 Oct 2022 10:58:10 GMT

Is it possible to measure the external clock frequency?

RE: nRF52840DK uart - 921600 not working

Einar Thorsrud — Mon, 24 Oct 2022 10:50:40 GMT

Hi,

[quote user="jorgenrs"]What I find strange is when sending data to my module (which is a LiDAR) and at the same time reading this data with the usb-2-ttl the bytes is perfect, yet the LiDAR is not responding. I would assume the usb-2-ttl module shows a bit more flexibility in terms of baud rate.[/quote]

It is a bit odd, but that could be it.. Which exact LiDAR module are you using? Could it be something else, like a flow control issue? (just an idea without any particular reason for thinking that would be related). Is it possible to use flow control with the module? If so, can you try it?b

[quote user="jorgenrs"]Just to clarify it is not possible to “tune” the baud rate to get it more accurate?[/quote]

No, the values from the product specification is the closest you can get. There is one thing though, which I have forgot to mention before. Note that there are different values for the UART (without DMA) and UARTE (with DMA) peripheral. So depending on which you use, you need to pick the correct one (see baud rate table in PS for that).

RE: nRF52840DK uart - 921600 not working

Stig24 — Fri, 21 Oct 2022 09:10:42 GMT

What I find strange is when sending data to my module (which is a LiDAR) and at the same time reading this data with the usb-2-ttl the bytes is perfect, yet the LiDAR is not responding. I would assume the usb-2-ttl module shows a bit more flexibility in terms of baud rate.

I have tried contact the manufacturer of the LiDAR without luck, but I will try to reach out to them again.

Just to clarify it is not possible to “tune” the baud rate to get it more accurate?

Thanks for the help!

RE: nRF52840DK uart - 921600 not working

Einar Thorsrud — Fri, 21 Oct 2022 08:56:47 GMT

Hi,

With this code you will be using the HFXO (though it would be cleaner to start it with the clock driver as you are anyway using that), so that should be OK. The difference in baud rate between the two devices here is a bit more than 2%, so with this short frame I would expect a lower error rate, but apparently that is not the case.

The fact that the nRF cannot do exactly 921600 baud is a WH limitation, so that is just how it is. Does the other device support other baud rates? If so, can you pick one where there is a better match (assuming you can also live with a lower baudrate).

RE: nRF52840DK uart - 921600 not working

Stig24 — Thu, 20 Oct 2022 08:56:10 GMT

I enabled the HFXO but didn’t improve anything.

Made a test (on/off signal to module every two seconds) and observed if the correct signal reached my module. Also observed my 13 bytes trough a usb to ttl module, and the bytes is always correct.

What	Correct	Wrong
With flush, with usb-2-ttl connected, without HFXO	16	34
Without flush, with usb-2-ttl connected, without HFXO	12	38
Without flush, with usb-2-ttl connected, with HFXO	13	37
With flush, with usb-2-ttl connected, with HFXO	11	39
With flush, without usb-2-ttl connected, without HFXO	10	40
Eqvivalent python program module connected to ttl (no nRF52)	50	0

Cannot understand why with the nRF52 it is struggling that much and the usb-2-ttl show the correct bytes from nRF52.

Snip of code

RE: nRF52840DK uart - 921600 not working

Einar Thorsrud — Fri, 14 Oct 2022 06:45:13 GMT

Hi,

Based on the compiler errors it looks like you put these 3 lines outside of a function. Try moving them into a function (for instance in the beginning of main()).

RE: nRF52840DK uart - 921600 not working

Stig24 — Fri, 14 Oct 2022 06:39:37 GMT

Will try!

When trying to enable HFXO

NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
NRF_CLOCK->TASKS_HFCLKSTART    = 1;
while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);

I get these fault messages and not sure why they occurs:

RE: nRF52840DK uart - 921600 not working

Einar Thorsrud — Thu, 13 Oct 2022 11:05:28 GMT

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).