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, I believe that this is an issue with the interface uC. I could show incorrect behaviour, independent of the code on the nRF52832. Here is how:

    1. connect the Rx pin of a TTL UART to port 8 on the SDK board (TxD of the interface uC, RxD of the 52832. Connect to RealTerm or similar, 115200, 8N1

    2. connect a second RealTerm instance to the JLINK UART port.

    3. type "QWERTY" into the sending terminal.

    4. Observe "QQWERTY" in the receiver (the one on port 8).

    Also you will see each char is delayed by one send, assuming you can reproduce.

Reply
  • Simon, I believe that this is an issue with the interface uC. I could show incorrect behaviour, independent of the code on the nRF52832. Here is how:

    1. connect the Rx pin of a TTL UART to port 8 on the SDK board (TxD of the interface uC, RxD of the 52832. Connect to RealTerm or similar, 115200, 8N1

    2. connect a second RealTerm instance to the JLINK UART port.

    3. type "QWERTY" into the sending terminal.

    4. Observe "QQWERTY" in the receiver (the one on port 8).

    Also you will see each char is delayed by one send, assuming you can reproduce.

Children
No Data
Related