nRF5340: issue with USB CDC ACM and UART driver running in parallel

[bojan]

Hello, guys.

We need USB CDC ACM and UART driver with DMA to run in parallel as two different nodes in the device tree. 

For that purpose, here is what we have in the prj.conf file:

CONFIG_USB_DEVICE_STACK=y #set to y if using usb
CONFIG_USB_DEVICE_PRODUCT="BT40"
CONFIG_SERIAL=y
CONFIG_CONSOLE=n
CONFIG_UART_LINE_CTRL=y
CONFIG_UART_ASYNC_API=y

and the .overlay file

&uart2 {
    status = "okay";
    current-speed = <115200>;
    tx-pin = <47>;
    rx-pin = <45>;
    rts-pin = <0xFFFFFFFF>;
    cts-pin = <0xFFFFFFFF>;
};

&uart3 {
    status = "okay";
    compatible = "nordic,nrf-uarte";
    current-speed = <115200>;
    tx-pin = <31>;
    rx-pin = <36>;
    rts-pin = <0xFFFFFFFF>;
    cts-pin = <0xFFFFFFFF>;
};

&zephyr_udc0 {
    cdc_acm_uart2 {
        compatible = "zephyr,cdc-acm-uart";
        label = "CDC_ACM_0";
    };
};

UART2 is used for USB CDC ACM driver whereas UART3 is used as a simple UART port with DMA

It seems there is some kind of conflict between USB CDC ACM and UART3. I can't neither set the callback for UART2 with

uart_callback_set(uart_dev, &uart_cb, NULL);

nor I can send/receive data over UART3. I always get 134 (ENOTSUP) error.

Only when I don't use the USB CDC ACM and remove the following line from the prj.conf file:

CONFIG_USB_DEVICE_STACK=y #set to y if using usb

I'm able to properly use UART3 as UART device with DMA.

Do you have any idea how can I make those two (USB CDC ACM on UART2 and UART3 with DMA) to work in parallel?

Thank you very much for your time and efforts. It is really appreciated.

Sincerely,
Bojan.

[ovrebekk]

Hi 

It should be possible to combine regular UART's with virtual CDC ACM UART's at the same time. 

Is there any chance that the uart_dev device could be the CDC ACM UART?
The CDC ACM driver does not support the ASYNC API, and will return ENOTSUP if you try to enable the callback.  

How is uart_dev initialized?

Best regards
Torbjørn

[bojan]

Hello, ovrebekk .

Thanks for your feedback.

uart_dev is installed the following way:

    uart_dev =  device_get_binding(DT_LABEL(DT_NODELABEL(uart3)));
	if (uart_dev == NULL) {
		LOG_ERR("Could not find  %s!\n\r",DT_LABEL(DT_NODELABEL(uart3)));
        return -1;		
	}

    ret = uart_callback_set(uart_dev, &uart_cb, NULL);
    if (ret != 0) {
		LOG_ERR("uart_callback_set: %d", ret);
        return ret;
	}

On the other side, here is the part of CDC ACM UART initialization:

uart_irq_callback_user_data_set(dev, interrupt_handler, NULL);

dev = DEVICE_DT_GET_ONE(zephyr_cdc_acm_uart);
if (!device_is_ready(dev)) {
	LOG_ERR("CDC ACM device not ready");
	return;
}

ret = usb_enable(NULL);
if (ret != 0) {
	LOG_ERR("Failed to enable USB");
	return;
}

CDC ACM UART is using interrupt-driven UART. Should I have the following line in the prj.conf:

CONFIG_UART_INTERRUPT_DRIVEN=y

?

I don't have it at the moment.

Sincerely,
Bojan.

[ovrebekk]

Hi Bojan

Any chance you can share your example with me so I can try to reproduce the issue on my end? 

If so, please just zip the project folder and attach it to your reply. 

If you don't want to share your code in a public case just let me know, and I can make the case private. 

Best regards
Torbjørn

[bojan]

Hello, ovrebekk .

Sorry for the late reply from my side.

Attached you can find the part of the project that you can use to explore the conflict between regular UART and virtual CDC ACM UART. We used nRF5340-DK for testing.

If in the prj.conf file the following lines are set to =n:

#BME280
CONFIG_USE_BME280=n

#USB transfer
CONFIG_USB_DEVICE_STACK=n 

virtual CDC ACM UART will be disabled and regular UART will work as expected.

If the above lines are set to =y (virtual CDC ACM UART enabled), the regular UART will not work.

uart_callback_set() function will return 134 (ENOTSUP).

Please let me know if you need anything else from my side. Thanks in advance for taking a look into the codebase and let us know your opinion.

Sincerely,
Bojan.

cpuapp.zip

[Sigurd Hellesvik]

Hi,

I will continue to help with this case.

I tried to run your sample with nRF Connect SDK v1.9.1, but got no logs from the normal port on my nRF5340DK.

Did I misunderstand something here?