This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF52-DK : UART Rx over USB loses first byte after hard reset but not after power cycle

we have an app where we use a nRF52-DK board (with the 52832 chip) as a serial to BLE interface. We connect to the board using the USB UART channel. The interface IC on the board is flashed with binary j-link-ob-sam3u128-v2-nordicsemi-170724.bin

We have flow control on the interface enabled, parity off, baud rate 115200

The issue we see is that if we power cycle the DK and send a short binary packet, the complete packet is received. However if we use the RESET button on the DK, the first byte is NOT received by the nRF52832. This happens consistently and even when several seconds pass between the reset and sending the serial data.

Is this a known issue, is there some step that we need to do after a reset?

Thanks. UART INIT code follows.

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_ENABLED,
        .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_LOW,
                       err_code);

    APP_ERROR_CHECK(err_code);
}

Parents
  • Hi

    This sounds very strange, and is not a known issue as far as I know. Can you provide some information on what SDK version and if you have based your project on any of our example applications. This shouldn't occur with the basic UART peripheral example project for example.

    Best regards,

    Simon

  • Simon, when I look at the source of your current examples - I think ours was originally based on Central UART, but this is before I inherited this code - they do not use app_uart_get() as our code does,

    However app_uart_get() *should* work OK on a byte by byte basis, no?

    Looking further I discovered that if I connect to the USB UART with a terminal program and then use RTT to see chars as they come in - and I type QWERTY right after power cycling the nRF52-DK board - I see "QQWERTY" in the debugger. And each character arrives "delayed by one" (i.e. when I type the "R" the "E" hits the debugger output).

    This has to be something very silly to do with flushing the FIFO or something, but at the moment it is giving me a headache.

    I could indeed build on of your SDK examples and maybe rewrite part of our app to do it your way - but it would help me a great deal if I could simply figure out why this odd behaviour is happening.

    I could later try to make a minimal version that can build and reproduce the issue, maybe. I could also connect a TTL UART to the physical pin between the nRF and the interface MCU perhaps.

Reply
  • Simon, when I look at the source of your current examples - I think ours was originally based on Central UART, but this is before I inherited this code - they do not use app_uart_get() as our code does,

    However app_uart_get() *should* work OK on a byte by byte basis, no?

    Looking further I discovered that if I connect to the USB UART with a terminal program and then use RTT to see chars as they come in - and I type QWERTY right after power cycling the nRF52-DK board - I see "QQWERTY" in the debugger. And each character arrives "delayed by one" (i.e. when I type the "R" the "E" hits the debugger output).

    This has to be something very silly to do with flushing the FIFO or something, but at the moment it is giving me a headache.

    I could indeed build on of your SDK examples and maybe rewrite part of our app to do it your way - but it would help me a great deal if I could simply figure out why this odd behaviour is happening.

    I could later try to make a minimal version that can build and reproduce the issue, maybe. I could also connect a TTL UART to the physical pin between the nRF and the interface MCU perhaps.

Children
No Data
Related