NRF_LOG_BACKEND_SERIAL_UART_BAUDRATE documentation of baudrate is incorrect

[vit bernatik]

Hello, It seems that NRF_LOG_BACKEND_SERIAL_UART_BAUDRATE has wrong documentation. In sdk_config.h it says:

// <o> NRF_LOG_BACKEND_SERIAL_UART_BAUDRATE  - Default Baudrate
// <251658240=> 921600 baud 
// <268435456=> 57600 baud 

But if I measure the speed I see:

 251658240 = 957 854 baud
 268435456 = 1 008 064 baud

Also even though with 957 854 baud I see often the correct text (with documented speed 921600 I saw always nothing) sometimes it happens that text is corrupted.

Expected and often got text:

APP:INFO:Helo world
SDH:INFO:sd_ble_enable: RAM START at 0x20003000
SDH:WARNING:sd_ble_enable: app_ram_base should be adjusted to 0x20002128
SDH:WARNING:ram size should be adjusted to 0xded8
APP:INFO:Heart Rate Sensor Start!
APP:INFO:Fast Adverstising

Sometimes in ~30% of cases I get corrupted text - for example:

APP:INFO:Helo world
SDH:INFO:sd_ble_enable: RAM START at 0x20003000
Sa▒:▒*▒▒'.▒%1+  1▒
                  ▒▒%5%▒!=▒1
                            )▒▒▒"=▒▒
                                    ▒▒!▒:▒*▒▒'.%▒!=▒1▒
                                                      ▒▒▒▒▒▒▒▒▒▒▒�▒▒▒▒e▒▒▒'jr▒▒U9▒=▒▒▒%▒▒▒'▒
            ▒▒▒▒%▒%95

Also interesting is that when I use highest speed rate (268435456 = 1 008 064 baud) I never get garbled text...

So my questions are:

1. Will you correct documentation?

2. Why you do use ugly numbers (like 268435456) in sdk_config.h comments if you could use defined macro (like UART_BAUDRATE_BAUDRATE_Baud1M) from file nrf52_bitfileds.h: ?

3. Just out of curiosity - why the mode 251658240 = 957 854 baud does not work sometimes?

[Einar Thorsrud]

1. There is a typo on the last comment line. Where it says "57600 baud " it should be "1Mega baud". I will report this internally. Regarding the other inaccuracies of the baud rate, this is documented in the product specification (BAUDRATE register).

2. Using magic number directly (though commented) rather than existing defines surprises me as well. It could be that they wanted not to have any dependencies on other header files, but I will check with the developers of Logger module to get a proper answer.

3. I am not sure about this. However, you should note that unless you have started the crystal oscillator, the internal 64 MHz internal oscillator (assuming you are on a nRF52) will have a worst case frequency tolerance of up to ±6 %, which might explain it.

[vit bernatik]

ad 3) I think the change is that in between first and next logs I call SOFTDEVICE_HANDLER_INIT which selects NRF_CLOCK_LF_SRC_XTAL. And frequency source changes. Some transition effect might also be due being soon after reset. With my logic analyzer I measure baudrate at beginning 957 854 but baudrate at the end is 946 969... And somewhere in middle I even measured startbit baudrate to be 934 597. So it is quite unstable... But it seems not being SW but HW... Maybe there is some issue with UART block because I see more often this start bit to be 5% shorter than next bit...