APPI_UART_FIFO_INIT and APP_IRQ_PRIORITY_HIGH crashes when data is send

[Constantin]

Hi,

I have the following setting. I have a dongle with with a nrf52 which sensd all data received from the NUS service to the host via a uart and a FTDI. The FTDI is capable of running up to 3 MBaud. When I use a low Baudrate like 230400 and send not  less data all is running fine. When the data rate increases the uart crashes because the data received by the nus is higher than the baudrate via uart. Now I increased the Baudrate and enabled Flow control as suggested by the manual. 

    app_uart_comm_params_t const comm_params =
    {
        .rx_pin_no    = RX_PIN_NUMBER,
        .tx_pin_no    = TX_PIN_NUMBER,
        .rts_pin_no   = RTS_PIN_NUMBER,
        .cts_pin_no   = CTS_PIN_NUMBER,
        .flow_control = APP_UART_FLOW_CONTROL_ENABLED,
        //.flow_control = APP_UART_FLOW_CONTROL_DISABLED,
        .use_parity   = false,
        .baud_rate    = UART_BAUDRATE_BAUDRATE_Baud921600 //UART_BAUDRATE_BAUDRATE_Baud1M
        //.baud_rate    = UART_BAUDRATE_BAUDRATE_Baud230400
    };

    APP_UART_FIFO_INIT(&comm_params,
                       UART_RX_BUF_SIZE,
                       UART_TX_BUF_SIZE,
                       uart_evt_handler,
                       APP_IRQ_PRIORITY_HIGH,
                       err_code);

    APP_ERROR_CHECK(err_code);

When the application starts I receive some printf but when the real transmission is initialized the dongle freezes and the sensor disconnects and restarts advertising which indicates that the dongle somehow crashed. But there is no error message logged via RTTClient.  When I set the priority to APP_IRQ_PRIORITY_LOW the program is running at least for 10 messages and then crashes with uart communication error 1.

I believe the communication error appears because the uart handler is not able to guarantee the transmission of alle data and gets a overrun. From my opinion this should be solved if the priority is increase.

[MartinBL]

Hi,

It could be that your baud rates aren't accurate enough for your FTDI chip.

I'll copy-paste some of my answer from this case: Problem communicating via UART in non-blocking mode with higher baud rates

"It could be that the nRF52 isn't able to provide an accurate enough baud rate for your module. As you can see in the specification, the baud rate you want isn't always the baud rate you get. 

Desired baud rate	Actual baud rate	Error
9600	9598	-0.02 %
14400	14414	0.10 %
19200	19208	0.04 %
28800	28829	0.10 %
38400	38462	0.16 %
57600	57762	0.28 %
76800	76923	0.16 %
115200	115942	0.64 %
230400	231884	0.64 %
250000	250000	0.00 %
460800	470588	2.08 %
921600	941176	2.08 %

In addition to the errors here, you will have to factor in the accuracy of the HF clock in your nRF52. This is because the digital logic in the UART is driven by the HF clock and the clock accuracy will hence directly affect the baud rate accuracy. Unless you tell it otherwise, the HF clock is generated by the internal RC oscillator (HFINT) with an accuracy that could be as bad as +-6 %. You can try to force the HF clock to utilize the external crystal (HFXO) as a source instead to increase the accuracy (typ 40 ppm or less). You can turn on the crystal like this: 

 

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

 

or with the function sd_clock_hfclk_request() if you are using a Softdevice and BLE. "

 

If you are using APP_IRQ_PRIORITY_HIGH you might get into trouble with interrupt priorities if you try to send UART data via BLE directly in your UART event handler. 

 

Have you turned on debugging, set optimization level to 0, and debugged like this? An application rarely just crashes without leaving a trace of errors. 

[Constantin]

Thanks Martin, increasing the accuracy to 30 PPM improved the situtatio. Now I get rarely errors. But still it is not possbile to increase priority of the uart interrupt higher than low. If I increase it the system stops on sending data without throwing an error. So far I could not debug. But I will do later. Could be that it is the uart_event_handler which calls sd_** functions. And I've read that is not possible from higher priority routines.

[MartinBL]

That is correct. Here is why.