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 Daniel

    Could you share what SDK version the project is built in, and what revision of the nRF52832 DK you're using? A picture of the sticker on the interface MCU would be helpful. I can't recall running into this issue before on our end with the SDK examples, but I'll investigate. 

    One thought that came to mind regarding your test procedure is that in the default UART example. Q and q has its own functionality that causes the program to transmit "EXIT!" and go into an infinite loop. So does this happen when you write other characters/strings than QWERTY as well? Just to rule out that the Q's "exit functionality" isn't still there in your app. I don't think it is since it works as intended with the standard TTL UART, but I thought it was worth mentioning.

    Best regards,

    Simon

Reply
  • Hi Daniel

    Could you share what SDK version the project is built in, and what revision of the nRF52832 DK you're using? A picture of the sticker on the interface MCU would be helpful. I can't recall running into this issue before on our end with the SDK examples, but I'll investigate. 

    One thought that came to mind regarding your test procedure is that in the default UART example. Q and q has its own functionality that causes the program to transmit "EXIT!" and go into an infinite loop. So does this happen when you write other characters/strings than QWERTY as well? Just to rule out that the Q's "exit functionality" isn't still there in your app. I don't think it is since it works as intended with the standard TTL UART, but I thought it was worth mentioning.

    Best regards,

    Simon

Children
  • hi Simon - I checked this this morning with a colleague. Initially he could not reproduce, it turned out that he was using RTT Viewer V6.88a, I have V7.60. He was able to reproduce and then clear the issue by switching between the versions. So looks like an issue with V7.60.

    Please read my post above carefully. I was able to show (by connecting a TTL UART to the interface MCU TxD pin) that the problem is NOT related to our firmware. By viewing this signal line using RealTerm it was clear that the interface MCU is the problem.

    You can probably reproduce this yourself without even programming the board, by doing the same. Connect a TTL UART RxD pin to the signal IMCU_TxD (which is P0.08 on the DK, it is available on connector P6). Type some characters to the JLINK UART channel and see what that UART picks up. I think you will then see the issue.

    Thanks.

Related