NRF52840 UART high error rate communicating with Raspberry Pi

[davidz]

I am using nrf52840 DK and communicate with Raspberry Pi 3 through UART port. The Raspberry Pi is used as a gateway. The baud rate is set at 115200 default on both nrf52840 and Raspberry Pi 3. Raspberry Pi 3 is using GPIO14 and GPIO15 and its UART is set up by following the official guide.

Since this is a direct wired connection from nrf52840 and Raspberry Pi 3, it does not involve the soft device. The SDK version is 17.0.2.

I found that there is rather high data error rate during the UART data transmission. For 300 sets of data transmitted from nrf52840 to Raspberry Pi, there are 13-15 set of data dropping one byte. The dropping byte position is not fixed. This is about 4% error, which is too high? 

I am using the standard Nordic UART function following the examples. 

The following is the UART init function:

static void uart_init(void)
{
ret_code_t err_code;

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_DISABLED,
.use_parity = false,
.baud_rate = UART_BAUDRATE_BAUDRATE_Baud115200
};

APP_UART_FIFO_INIT(&comm_params,
UART_RX_BUF_SIZE,
UART_TX_BUF_SIZE,
uart_event_handle,
APP_IRQ_PRIORITY_LOWEST,
err_code);

APP_ERROR_CHECK(err_code);
}

The following is the sending data function:

static void ble_uart_send(uint8_t * p_data, uint16_t data_len)
{
ret_code_t ret_val;

for (uint32_t i = 0; i < data_len; i++)
{
do
{
ret_val = app_uart_put(p_data[i]);

if ((ret_val != NRF_SUCCESS) && (ret_val != NRF_ERROR_BUSY))
{
NRF_LOG_INFO("app_uart_put failed for index 0x%04x.", i);

}
} while (ret_val == NRF_ERROR_BUSY);
}

// Add two end bytes to identify the ending of the packet
do
{

ret_val = app_uart_put(0xAA);
if ((ret_val != NRF_SUCCESS) && (ret_val != NRF_ERROR_BUSY))
{
NRF_LOG_INFO("app_uart_put failed\r\n");

}
} while (ret_val == NRF_ERROR_BUSY);
do
{
ret_val = app_uart_put('\n');
if ((ret_val != NRF_SUCCESS) && (ret_val != NRF_ERROR_BUSY))
{
NRF_LOG_INFO("app_uart_put failed\r\n");

}
} while (ret_val == NRF_ERROR_BUSY);

}

[hmolesworth]

Try enabling high drive outputs on the Tx; this works fine over 12" wires to a Raspberry Pi-3 at 1MBaud (1,000,000 baud) with only occasional character loss (ie a few characters in 500 MBytes of data) with no flow control enabled:

void EnableHighDriveUartPins(void)
{
    nrf_gpio_cfg(TX_PIN_NUMBER,
                 NRF_GPIO_PIN_DIR_OUTPUT,
                 NRF_GPIO_PIN_INPUT_DISCONNECT,
                 NRF_GPIO_PIN_NOPULL,
                 NRF_GPIO_PIN_H0H1,       // Require High Drive low & high levels
                 NRF_GPIO_PIN_NOSENSE);
    // Add RTS if used
}

Add EnableHighDriveUartPins() as the last line in uart_init() as uart_init() sets low drive on this pin

[davidz]

I added the above codes and still had the same issue. The normal data length is 11 bytes. For about 4-5% of the time, the received data has only 10 bytes and one byte is dropped.

Could it be a clock issue?

[hmolesworth]

Better than that GPIO14 P0.14 has LED2 and P0.15 LED3 with too much load for a Tx pin; unless you disconnected those ..

[davidz]

Raspberry Pi 3 is using GPIO 14 and GPIO 15, not the nrf52840. There are nothing else connected to UART pins at Raspberry Pi 3 and nrf52840. The length of the wire is only 6". 

[hmolesworth]

Ah, of course. I use the same pins on the Pi-3 and supply the nRF52 with Vcc from Pin 1, 3.3V. I trust the nRF52840 is using P0.nn and not P1.nn? I don't see those pin numbers ..

[davidz]

Yes the pins are fine. I have narrowed down to the following right now: 

The nrf52840 also uses nus UART service to receive data from peripheral. Once nus data is received, then nrf52840 calls ble_uart_send() function to send data to Raspberry Pi. 

The data received via nus UART is correct (I double-checked :)).

The program sends data via UART to Raspberry Pi also correctly when it runs alone (without connecting to the nus UART service). I used constant dummy data to verify this. No errors occur even at higher UART rate. 

The problem arises when they run together. The nus data is always correct. But the UART data transfer to the Raspberry Pi start having errors. 

[hmolesworth]

If central, does the busy NRF_ERROR_BUSY get handled like this:

static void ble_nus_chars_received_uart_print(uint8_t * p_data, uint16_t data_len)
{
    ret_code_t ret_val;

    NRF_LOG_DEBUG("Receiving data.");
    NRF_LOG_HEXDUMP_DEBUG(p_data, data_len);

    for (uint32_t i = 0; i < data_len; i++)
    {
        do
        {
            ret_val = app_uart_put(p_data[i]);
            if ((ret_val != NRF_SUCCESS) && (ret_val != NRF_ERROR_BUSY))
            {
                NRF_LOG_ERROR("app_uart_put failed for index 0x%04x.", i);
                APP_ERROR_CHECK(ret_val);
            }
        } while (ret_val == NRF_ERROR_BUSY);
    }
    if (p_data[data_len-1] == '\r')
    {
        while (app_uart_put('\n') == NRF_ERROR_BUSY);
    }

Hopefully also ECHOBACK_BLE_UART_DATA is 0

[davidz]

The problem was solved. It turns out that for high speed UART, the UART function should not be called in the nus event. Otherwise, it will cause the UART higher error rate.