Tivaware (2.1.2.111) CDC device not transmitting

Hello Chris

CDC device requires interrupt type transfers where the host needs to send the IN packet request to the device. Are these requests coming to the device?

Hi Amit

I have the system tapped inline with my beagle and this is what I see:

(when I push a button on the device and it says that it successfully queues up a send to the host)

I pushed the button in there somewhere...  When I initiate the data transfer from the host side, the data all goes through and it continues with this behavior.

Thanks

Hello Chris

You would need to capture the failing transaction point where the issue begins.

Hi Amit

That's what the reading looks like when I'm tapping the line and I push the button; it doesn't look like anything is done during the time when it's trying to send to the host that it has a little message.  For contrast, this is what I see if the button link is working:

Chris

Hello Chris,

It is tough to say since the two logs looks identical. And we are not sure where the device poll by the host stops reading data. Is it possible to run this with a PC as a host?

Hi Amit

I can, sorry I'm really new to USB (using example code on both sides) but I'll see what it does on my PC

Chris

Hello Chris,

BTW, did you try the usb serial example from TivaWare in your setup and see how it behaves?

Hi Chris,

I'm having a similar issue as you are describing, but I am at a loss as to why it is happening.

For some reason after I make a call to USBBufferWrite() with my CDC device, my output buffer just sits there with several bytes waiting in it, and it never sends them to my waiting host.

Did you ever find resolution to your issue?

--clint

Hi Clint

I actually haven't found a solution yet but I've just recently started working on the problem again; I'll let you know what I figure out.

Chris

Hi Chris,

Thanks for the reply. :)  

After a full evening of going over it piece-by-piece, I think I have finally sussed out the last little bits of my problems.  Unfortunately, I can't quite tell what exactly was the root cause of my un-emptied buffers, but I think it was a combination of a few things.  I'll share what I've found, and perhaps one of these is the source of your issue:

• System instability that leads to the micro rebooting can leave either the host expecting data, or the device expecting to send data when the host won't accept it.  Even though I call USBBufferFlush() upon USB_EVENT_CONNECTED, I'm not convinced that it fully cleans everything out of the system during a warm-boot.
• One of the big things that tripped me up was that -- even though you can use USBBufferWrite() to send an arbitrarily large chunk of data (up to the size of the output buffer), calling USBBufferRead() upon USB_EVENT_RX_AVAILABLE will return no more than 64 bytes -- even if your input buffer is much larger than that.  You need to buffer the input data and wait for a second firing of USB_EVENT_RX_AVAILABLE. If you were expecting something larger (70 bytes or so, as in my case), then one's application code might receive enough data to believe that it got the whole packet and fire a response back to the host, but then there is a leftover handful of bytes that act like a separate packet and this caused the application and the host to get out of sync.  Make sure you always verify how much you received, and plan to process packets > 64 bytes after 2 or more calls to your RxHandler.  
• The CDC driver is structured in such a way that it does not send data to the host unless it is explicitly requested, so unless your host is actively reading (and not merely polling to see how much data is waiting), then the data will not be read and it will continue to sit in the transmit buffer.  Especially combined with the out-of-sync issues mentioned above, it can cause no end of pulling ones' hair out.
• And finally, if you're suffering from general intermittent system instability like me, increasing my stack size helped smooth things out immensely.  Once I bumped pui32Stack from 128 up to 256, a great many of my stability issues went away.

The "no more than 64 bytes per receive" thing was a particularly grievous oversight on my part, and the others were more minor.  Walking through the code with a fine-toothed comb and reading through the USB library manual helped me understand the internals and piece together the parts that I was missing.

I hope some of my findings may be useful to you!

--clint