Intermittent Uart Frame Errors

Hello,

I'm running an nrf52832 (fanstel module) communicating over UART with another MCU at 460800 baud. The Uarts both have matching configurations. The baud rates are both set to 460800 using the internal clocks. The UART implementation is similar to the implementation here: https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bluetooth/central_uart/src/main.c however it incorporates a ring buffer.

The UART is receiving a fairly constant stream of data and regularly gets two UART_RX_STOPPED interrupts in a row with reason framing error and then a UART_RX_DISABLED. I've attempted running at lower baud rates of 115200 and 230400 as well with no improvement.

I've analyzed the data sent with a logic analyzer and found that the LA had no errors reading the same uart frames that caused a frame error.

  • The most important factor that might effect your communications here is if you are using HWFC (hardware flowcontrol) or not. It might seem that both the UARTs on either side are working with similar configuration but there will still exist some differences in timings (rising and falling edge characteristics of the signals) that might resonate over time and can cause framing errors if you send data continuously. HWFC many times reduces this resonating effect by pausing the communications based on buffer availability. Even though this pause technically should not have any impact, we have seen that it have an impact of reducing framing errors. If you have not tried already, please enable HWFC and do this testing again. That said, UART on nRF52 products are very mature peripherals, so it is a bit unlikely to find hardware issues on it. Atleast from the support side, we will not suspect hardware issues. If you still see framing errors, then I will seek some help from you to reproduce the issue on a latest sdk version (not on main version, like the link you showed) 

  • You might also review the definitions for 460800 baud as the earlier nRF52832 documentation was incorrect; perhaps try using 0x075F7000 if not already. However if the "other MCU" device is using the same value as the nRF52832 then of course it doesn't matter what the value is.

    //  -------Documentation---------   -------Calculated---------
    //  Register    Required   Actual    Register    Actual    Ok?      Index
    //  ==========  ========   ======   ==========   ======   ====      =====
       {0x01D60000,   115200,  115108,  0x01D7E000,  115203, "  -"},  // 10
       {0x03B00000,   230400,  231884,  0x03AFB000,  230392, "  -"},  // 11
       {0x04000000,   250000,  250000,  0x04000000,  250000, " Ok"},  // 12
       {0x07400000,   460800,  457143,  0x075F7000,  460800, "  -"},  // 13
       {0x0F000000,   921600,  941176,  0x0EBEE000,  921600, "  -"},  // 14
       {0x10000000,  1000000, 1000000,  0x10000000, 1000000, " Ok"},  // 15
    // Extra and changed values from nRF52840 Product Specification
       {0x01D7E000,   115200,  115942,  0x01D7E000,  115203, " Ok"},  // 22
       {0x03AFB000,   230400,  231884,  0x03AFB000,  230392, " Ok"},  // 23
       {0x075F7000,   460800,  470588,  0x075F7000,  460800, " Ok"},  // 24
       {0x0EBED000,   921600,  941176,  0x0EBEE000,  921600, "  -"}}; // 25
    

    nRF52832 v1.7:

    // Quoted values from nRF52832 v1.7 datasheet - "No" means incorrect
    //
    //  --------Calculated-------------------  ---------------Documentation---------------
    //  Required Register      Actual   Error  Register    Required   Actual  Error   Ok?
    //  ======== =========== ======== =======  =========== ======== ======== =======  ====
    //   115200, 0x01D7E000,  115203, +0.002%  0x01D60000,  115200,  115108, -0.079%,  No,
    //   230400, 0x03AFC000,  230407, +0.003%  0x03B00000,  230400,  231884, +0.644%,  No,
    //   250000, 0x04000000,  250000,       -  0x04000000,  250000,  250000, +0.000%,   -,
    //   460800, 0x075F7000,  460800, +0.000%  0x07400000,  460800,  457143, -0.793%,  No,
    

    Edit: I posted my calculation here in case you want to verify:

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

  • Hello, I located the issue.

    tldr: Need to enable HW async and timer

    CONFIG_UART_0_ASYNC=y
    CONFIG_UART_0_NRF_HW_ASYNC=y
    CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2
    CONFIG_NRFX_TIMER2=y

    The issue stems from the async uart not being fast enough without a timer to assist as described here:docs.nordicsemi.com/.../CONFIG_UART_0_NRF_HW_ASYNC.html

    It really seems like this should be enabled by default if you use the async uart on nordic or possibly a warning when your device tree sets the baud rate to a higher speed. Feels like handling this with sw would be the fallback if you don't have timers to allocate to the task.

    Thank you for your replies. I appreciate the assistance.

Related