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]

Simon, when I cut solder bridges and use a standard TTL UART connected directly to the target (bypassing the interface uC) all the issues I had with serial comms are resolved.

This must surely be an issue with the interface uC firmware.

[Simonr]

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

[danmcb]

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.

[Simonr]

Hi

I agree that it didn't sound like a firmware issue from your description, I just wanted to put it down in writing just in case.

I have reported this internally now, and we're looking into it. Have you contacted SEGGER, as it seems like JLink/the RTT viewer needs an update to fix this.

Best regards,

Simon

[danmcb]

No problem, I appreciate your responsiveness. It took us a few days to isolate this issue.

I guess it does look as if RTT Viewer (or the suite it is a part of) is the issue, but as we cannot really see the traffic between that app and your interface uC, it's hard to be sure, and frankly we don't really want to spend much more time on it. We can workaround for now. If you reproduce and work on the issue, taking it up with Segger if that seems appropriate, that would be OK for us. Obviously we'd like to see a fix going forward.

Please keep us posted with your findings though - I'd personally like least to see the issue confirmed, as I thought I was going crazy for a bit :-)

All the best.