USB CDC Lockup

[timias]

I was wondering if anyone has experienced occasional lock ups with MQX CDC Driver. I have seen the same problem occur with both 3.7 and 3.8 using drivers for the K60twrk60n512 - though I think the problem is more wide spread than just one processor. I was using a coldfire 51JE256 and I recall the problem occured there too.

Basically what happens is calls to USB_Class_CDC_Send_Data() return with a status code of USBERR_DEVICE_BUSY

and all additional calls, regardless of wait time return with the same error code.

It happens most frequently when transmitting data rapidly, but I don't know if there is a correlation other than more data = occur sooner.

I wrote a quick workaround which involves modifying usb_cdc.h and usb_cdc.c by adding the following function. It seemed to mask the issue, and allows me to continue without lockups, but is obviously not optimial( is suspect data loss is going to occur). This problem seems to be similar to some earlier posts, has someone else found a better way?

uint_8 USB_Class_CDC_Wipe_Data(  CDC_HANDLE handle,uint_8 ep_num)

{

CDC_DEVICE_STRUCT_PTR devicePtr;

uint_8 index;

    devicePtr = USB_Cdc_Get_Device_Ptr(handle);

if (NULL == devicePtr)

return USBERR_ERROR;

/* map the endpoint num to the index of the endpoint structure */

    index = USB_Map_Ep_To_Struct_Index(devicePtr, ep_num);

    devicePtr->

ep[index].bin_consumer = 0x00;        

    devicePtr->

ep[index].bin_producer = 0x00;  

return USB_OK;;     

}

[JuroV]

Hello Robert, can you tell me if you observe this issue in MQX 4.0? It will be released in few days.

[timias]

Yes, I saw the issue re-appear with MQX 4.0. I remodified the code with the above function and it appeared to help again.

[t_k]

Where are you calling this function from?

I've been seeing lockups as well when trying to use the CDC Virtual Comm demo.

I'm using the MCF54417 processor.

[timias]

here is an example- FYI it wasn't a perfect solution, but it dramatically helped my code.

error = USB_Class_CDC_Send_Data(g_app_handle, DIC_BULK_IN_ENDPOINT, data,  (uint32_t) size);

     if (error != USB_OK){

       _time_delay(1);

       if (error == USBERR_DEVICE_BUSY){

            (void)USB_Class_CDC_Wipe_Data(g_app_handle,DIC_BULK_IN_ENDPOINT);

            error = USB_Class_CDC_Send_Data(g_app_handle, DIC_BULK_IN_ENDPOINT, data,  (uint32_t) size);

     }

}

[mikepuckett]

I'm seeing exactly the same problem you originally reported, Robert, on a project I'm working on.  We're still using MQX 3.8 and are on a board that's based on the 72MHz K20.  I'll try implementing your patch to see whether it helps or not.  I've gone so far to uninstall and reinstall the driver when it happens -- that usually works, but it even sometimes fails and, in that case, I simply have to reboot.  I'm obviously looking for a more robust solution.

Thanks!

[timias]

I have not revisited the problem since I implemented the temporary fix. I still have minor issues with USB CDC from time to time and may be due to the the nature of how I patched it. One other thing that you might want to double check.

It is from our experience absolutely critical to use a USB 2.0 cable when connecting to the device. The USB 2.0 cables have metal shielding around the signal wires. The cheap USB cables can create their own class of connection issues.

[t_k]

I'm still getting lockups.

I've started with the CDC  Virtual Com demo, added your fix, and commented out the hardware flow control.

After its been running a little while, the comport disappears from the PC side. 

Any ideas of where to start looking?

[timias]

The problem I was seeing didn't manifest itself as a COM port disappearance. The COM port remained active on the PC, but the data stopped posting from my device to the PC.