Apparent bug in virtual com port example...

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Apparent bug in virtual com port example...

1,581 Views
EdSutter
Senior Contributor II

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? 

7 Replies

1,561 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi Edsutter:

 

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

 

Regards

Daniel

0 Kudos

1,530 Views
EdSutter
Senior Contributor II

Hi Daniel,

Thanks for taking a look at this...

Any idea what is going on?

Ed

0 Kudos

1,510 Views
danielchen
NXP TechSupport
NXP TechSupport

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

0 Kudos

1,505 Views
EdSutter
Senior Contributor II

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? 

1,484 Views
danielchen
NXP TechSupport
NXP TechSupport

it seems ok to me.

0 Kudos

729 Views
R3to
Contributor I

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

 
 

 

 

 
 

 

 

0 Kudos

466 Views
maartenm
Contributor I

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.