• State Verified Answer
  • Replies 3 replies
  • Subscribers 73 subscribers
  • Views 1263 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 211146
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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.

Parents
  • +1

    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. 
Reply
  • +1

    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. 
Children
Related
Terms of service