topic Re: Apparent bug in virtual com port example... in i.MX RT Crossover MCUs

Apparent bug in virtual com port example...

EdSutter — Thu, 01 Oct 2020 14:45:04 GMT

Note that this is a rewrite of this topic. Now that I understand the problem and have confirmation from another developer that its a valid issue, it seemed appropriate to repost with correct subject line and only the essential details...

Referring to the usb_device_cdc_vcom_lite example from the SDK. This example just echoes whatever character is sent. Here's a --slightly modified-- snippet taken directly from the example...

void APP_task(void) { usb_status_t error = kStatus_USB_Error; if ((1 == s_cdcVcom.attach) && (1 == s_cdcVcom.startTransactions)) { /* User Code */ if ((0 != s_recvSize) && (0xFFFFFFFFU != s_recvSize)) { int32_t i; /* Copy Buffer to Send Buff */ for (i = 0; i < s_recvSize; i++) { #ifdef DEMONSTRATE_THE_ERROR if (s_currRecvBuf[i] != 'Z') #endif s_currSendBuf[s_sendSize++] = s_currRecvBuf[i]; } s_recvSize = 0; } if (s_sendSize) { uint32_t size = s_sendSize; s_sendSize = 0; error = USB_DeviceSendRequest(s_cdcVcom.deviceHandle, USB_CDC_VCOM_BULK_IN_ENDPOINT, s_currSendBuf, size); if (error != kStatus_USB_Success) { /* Failure to send Data Handling code here */ } } } }

With DEMONSTRATE_THE_ERROR undefined, the above code works... It simply echoes each character received from the host back to the host. If DEMONSTRATE_THE_ERROR is defined and the host sends 'Z', all echoes stop, and the connection is essentially dead as best I can tell.

One additional note...

If I call USB_DeviceSendRequest() with buffer and size set to 0 when I receive the 'Z', the 'Z' is not echoed, but after that characters are echoed. So it appears that for each incoming (from the host) character there needs to be a corresponding call to USB_DeviceSendRequest() even if the length is zero.

It appears to me that this is an issue in the SDK, can someone from NXP take a look and offer some suggestions?

Re: Apparent bug in virtual com port example...

danielchen — Tue, 06 Oct 2020 02:25:51 GMT

Hi Edsutter:

Thank you very much for your feedback. Let me try to reproduce this issue on my side.

Regards

Daniel

Re: Apparent bug in virtual com port example...

EdSutter — Thu, 08 Oct 2020 11:59:53 GMT

Hi Daniel,

Thanks for taking a look at this...

Any idea what is going on?

Re: Apparent bug in virtual com port example...

danielchen — Tue, 13 Oct 2020 14:38:25 GMT

Hi @EdSutter

The demo's default behavior is: Send back the data that is received from host, then start to receive the next data from host. If host doesn't the receive the data from the device, the device will not receive next data.

You can modify the demo according to your requirement.

We can change the demo's behavior to receive the data continuously.

Regards

Daniel

Re: Apparent bug in virtual com port example...

EdSutter — Tue, 13 Oct 2020 14:53:37 GMT

Daniel,

I know what the default behavior is.

Ultimately I want to hook this up to a terminal on a host, and the terminal interface won't always want to have every character echoed back. The modification (that I figured was a hack) I made to get around this is to call

USB_DeviceSendRequest(s_cdcVcom.deviceHandle,USB_CDC_VCOM_BULK_IN_ENDPOINT,0,0);

in APP_task() for each character received. I just assumed there would be a better way to resolve this.

Is that really the way to do this?

Re: Apparent bug in virtual com port example...

danielchen — Wed, 14 Oct 2020 12:03:42 GMT

it seems ok to me.

Re: Apparent bug in virtual com port example...

R3to — Tue, 21 Mar 2023 06:43:58 GMT

Is this really the best solution? You wrote

We can change the demo's behavior to receive the data continuously.

The demo has not changed since 2020. This example is not very practical

Re: Apparent bug in virtual com port example...

maartenm — Thu, 31 Aug 2023 11:19:02 GMT

While googling for my own issue i ran into this thread. We are currently experiencing this issue as well and it has costs of quite some debugging time to even identify this was the cause of our issues. Unfortunately our fix of just calling USB_DeviceCdcAcmRecv while handling kUSB_DeviceCdcEventRecvResponse seems to result in missing usb responses back to the host.