USB UART configuration has no RX

[Vladimir RB]

We want to use nRF52840 as advanced USB - UART converter to control end device (see structure below).

We already checked that our end device is working fine by external USB - UART converter (just connects to RX/TX pins on our board while nRF52840 in RESET state).

We based our software on USB-UART example from Thread SDK 2.0 (we want to use Thread in this project).
Standart USB-UART example works fine on nRF52840-DK through Jlink UART - we can send & receive data from both sides.

But when we want to adapt code for our board (just reconfig pins) we can't receive any data, only transfer a data.
We thought that it may be specialized pins in EVM but we tried all 3 configurations on nRF52840-DK and on our device (PCB):

• Connect Profilic on the RX/TX pins (0.6/0.8) between nRF52 and Jlink UART in turned off mode
• Tried free GPIO 1.6/1.4 as RX/TX 
• and vice versa (1.4/1.6) to be sure that the are no schematics and connection issues.

Anywhere the resualt the same - no RX by nRF52840.

See the project in attachment usbd_cdc_acm_to_uart.zip
Just place it in examples/peripheral.
Сustom_board2.h should be renamed to custom_board.h and moved to components/boards

We think it should be software issue because in general the example works.
Please help us here.

[awneil]

Have you disabled hardware flow control?

Have you tried just the nRF UART part - without any USB?

Does the debugger show data being received by the nRF?

[Vladimir RB]

We don't use hardware control.

We tried to connect the nRF UART directly to end device. Rusult was the same.

We doesn't run the debugger because USB is the time critical protocol and it will be crashed when we going into point.

The main question there, as I understand, why after changing the pins we can't receive the data, while we still can transfer. Data flow control, as I understand, affect on both RX & TX at the same time. So if we can send data, that configuration is correct.

[Vladimir RB]

We checked our receiving handler.

static void nbiot_read(struct nrf_serial_s const * p_serial,
                       nrf_serial_event_t event)
{
    switch(event)
    {
      case NRF_SERIAL_EVENT_RX_DATA:
      {
          nrf_serial_read(&serial_uart, &NBIOT_BUF[cntas], 1, NULL, 1000);  // читаем принятый байт UART в массив NBIOT_BUF
          //size_t size = sprintf(m_tx_buffer, &NBIOT_BUF[cntas]);
          //if (usb_open)
          //{
              app_usbd_cdc_acm_write(&m_app_cdc_acm, &NBIOT_BUF[cntas], 1);
              //nbiot_clr_buf(); //чистим буфер
          //}
          break;
      }
      default: break;
    }
}

We got the message in NBIOT_BUF.So our UART config should be correct.

[awneil]

So you're saying that you ran this in the debugger, and you do see the received data arriving in your UART handler?

If so, then that does go to show that your UART and UART handler are working - so your problem lies Further "up" the chain - towards the USB stuff ...

Have you looked at the Segger Monitor Mode Debugging for the time-critical parts ... ?

eg, https://devzone.nordicsemi.com/b/blog/posts/segger-embedded-studio-part-2-monitor-mode-debuggi - and search for other discusions ...

[Vladimir RB]

You right, that if we received data from UART into buffer, that our problem has in another place

Because we don't change the example, we think that it should be an bug in initialization of USB UART. We still don't found it.

[Vladimir RB]

We reviewed the code and found that hardwade flow control is used

After we changed next define we can send & receive data.

#define HWFC           false

It's strange that at the same time we got the RX data in buffer...

[awneil]

Vladimir RB said:

It's strange that at the same time we got the RX data in buffer

Is it?

You showed your UART configuration, and it had NRF_UART_HWFC_DISABLED - so, as far as the UART hardware is concerned, its hardware flow control was disabled.

Therefore it is not surprising that the UART hardware did receive data.

Presumably, as noted earlier, this HWFC control must apply at some point further "up" the chain - towards (or within) the USB stuff.

You could pursue that by browsing/searching for the uses of that HWFC control ...