Is this bug in MQX USB driver?

[kaskasi]

Hello,

We have been wondering why we cannot send one certain packet out with our USB CDC driver. Took us while to figure out that problem was the packet's length which happened to be 2*EP size. In our case 128bytes. I didn't have time to search if this bug has been found previously so here is what I did to fix this particular problem. In khci_dev_main.c function _usb_device_usbfs_service_tk_dne_intr (around line 876) has following code. I did comment out &&(ep_num==USB_CONTROL_ENDPOINT). This seemed to solve the particular problem. Which happens to be not sending 0 size packet for the transmission that is 2*EP (or any even number there after)

	/* to send zero bytes data on CONTROL ENDPOINT TO MARK END OF TRANSFER*/
	/* this is needed only when last send transaction was equal to
	max_buffer_size and there is no more data to send*/
	if((len==state_ptr->EP_INFO[ep_num].max_packet_size)&&
	(buf_num_bytes == 0)/*&&(ep_num==USB_CONTROL_ENDPOINT)*/ )
	{

I'm thinking this fix should not break anything?!?! Could someone else who is more familiar with this code confirm.

So if you happen to have problems where USB packets are not going out check the packet length if it is 2 * EP size you most likely will have this problem.

Thanks,

Kari

[c0170 · Accepted solution]

Hello Kari,

I have reported your issue and I was told your fix is fine.

Update: After some investigation we think that this is not an issue and it works as designed.  Your fix can solve your problem, but it is not systematic solution.

All you want to notify the host that it should flush the data, because the device does not have any additional data. This can be application specific, some applications might not want to flush data. However we think that many customers would think that this is an issue so we have fixed it in the application itself.

Thank you for reporting!

Regards,

MartinK

[jpa]

Martin (and others),

I seem to be encountering this issue or some variation on it, and would like to hear more about the "proper" way to handle it from the application side, if that's where it should be done. 

I gathered that if the last packet to be sent to the host is full, the application should send a zero packet after, to flush the data.  I've done that. 

What about receive?  My handler for USB_APP_DATA_RECEIVED always calls USB_Class_Recv_Data again regardless of the packet size, but it seems like full packets stall the receive process, too.  In other words, the second full packet from the host never seems to make it to USB_Notif_Callback.   Another (non-full) packet sent from the host kick-starts things again and all the data is received. 

I'm using my own class based on CDC and AUDIO, so if none of this makes sense, say so, it's quite possible the problem is in my implementation.

John

[jpa]

My apologies if this is just noise, but I figured out the trigger and a workaround to my circumstances. 

My descriptor sets the endpoint packet size to 64.  I call Recv with a buffer and size that is 8*64.  This works when sending more than 64 bytes or less than 64 bytes, but at exactly 64, I don't get the packet until something other than 64 bytes is sent. 

By all appearances, the audio_speaker example does the same thing (calling RECV with a much larger buffer), but with an ISOCHRONOUS endpoint instead of a BULK endpoint, so perhaps it works under those circumstances. 

Calling Class_Recv_Data with a size equal to the descriptor endpont maximum (64) appears to work with all three cases.  On the send side, I'm still looking for calls to Send that end with a 64 byte packet and sending a zero byte packet after.  Maybe if I'm felling brave later, I'll take it out and see if it breaks it. 

Hope this helps someone else...

John

[freuz]

Hi,

we just ran into the same issue today and found the same solution. You mention that this fix is application specific. But actually there is an option defined in your documentation: DONT_ZERO_TERMINATE. This is in the XD structure. It should be checked in the "if" to adapt to the application. So this is really a bug where the driver is not using the field that exists to adapt its behaviour to the need of the application.

Is that bug fixed or will it be fixed?

Fred

[kaskasi]

Thanks for your response and update Martin.

Guess all of our applications are different. :smileywink:

I'm using USB_Class_CDC_Send_Data() function to send data and based on information in your documentation there is no mention that I need to flush data in case size of the packet is multiples of 128. Have  not checked CDC demo app.

As a developer and user of the USB Device Class API I just spent two days of my development time trying to understand why certain packets were not received by the windows application. Obviously it all pointed to the changes in our application. More specifically to the fix that made our packet to be exactly 128 bytes, which sounded irrelevant during the time. Once function is called I did even see the callback event coming back to confirm the data sent. But packet never went over to the windows side. We could repeat sending of this packet multiple times, until there was a packet with different length (in our case 17 bytes). That flushed out all the data. Once we understood that it was the size of the app_buff when calling USB_Class_CDC_Send_Data() that was problematic everything started to make sense. And that is the best moment of the problem solving, when things start making sense!!! 

Hopefully this post helps someone out there that is wondering why data is delayed or seems to get lost.

Totally appreciate that full source code is available and we can modify it make our own customizations.

Thanks,

Kari