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

[danmcb]

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);

}

[danmcb]

our code to read the uart starts like this:

void uart_event_handle(app_uart_evt_t * p_event)

{

    uint32_t    ret_val;

    uint8_t     b_in;

    switch (p_event->evt_type)

    {

        /**@snippet [Handling data from UART] */

        case APP_UART_DATA_READY:

            ret_val = app_uart_get(&b_in);

[Simonr]

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

[danmcb]

hi Simon - very weird indeed. I believe that our app was based on that example, but not sure. Where can I get the source? then I can try to build and reproduce ...? (EDIT) - ok, I found it, thank you.

[danmcb]

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.

[danmcb]

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.