Thanks for the quick reply. The device can transmit more than 64 bytes. Each packet is broken into 64 bytes fragments while transmitted.
At normal operation, the device generated data every 4-5ms, while the host usually polls every 1ms. The issue occurs when there is one delayed poll from the host, which is 100ms after its last poll. In this case the data is generated faster than the host polls, but this is not normal behavior. We cannot work with 100msec rates. It's too slow. I also assume that there is some sort of TXFifo in the USB to overcome such a situation. There is nothing wrong in sending to packets in the same frame, except it's not supposed to be this way, and eventually the concatenation causes packets to get lost. If I will be able to overcome the concatenation issue, and force each packet to be transmitted in its own frame, data won't be lost. I tried to busy wait on the transmit status register, to verify that the previous packet was already sent, but it didn't help. In the FW code I can only trigger the poll by setting the POLL_DEMAND bit in the control register. If the poll doesn't arrive, the data will still accumulate. Any ideas? Thanks, Gadi On Wed, 5 Dec 2007, Gadi Tunes wrote: > Hi, > > My device is connected to the host by 3 IN endpoints (USB 1.1). > Two of them are interrupt HID eps and the third is bulk. > I have an issue with packets being concatenated while sent from the > device to the host, if the polling from the host isn't quick enough. > For instance, in my bulk ep, I can transfer 64 bytes in each frame. I > usually send 16 byte packages. > If the polling was delayed from some reason, the 4 packets will be > transferred to the host the next time it polls, and 64 bytes will be > transferred. > If there were more than 4 packets concatenated, the rest will be lost, > as only 64 bytes can be passed in a frame Why can't the device transmit more than 64 bytes in a frame? > (but if I had a packet larger > than 64 bytes in will be fragmented into 64-bytes fragments and all > the data will pass). > I had this issue also with the interrupt HID eps. I was supposed to > send > 8 bytes reports, and the EP could have transferred 16 bytes, so > sometimes I had concatenations. The reports which arrived to the host > were illegal (incompatible with the report descriptor, awaiting 8-byte > reports) and I got resets on the USB line. As a workaround I enlarged > the reports into 10 bytes, which prevented the possibility of > concatenation (the ep could not transfer 20 bytes), but with the bulk > ep I can't do that as anything is allowed on the bulk ep, and the > maximum package size is much bigger and I don't want to overload the USB line. What you're saying isn't entirely clear. It sounds like you are submitting data to the firmware faster than the host will accept it, and as a result some of your data is getting lost. Is that right? > My questions are: > How do prevent this concatenation? I want each packet to be sent in > its own frame. Why do you want each packet sent in its own frame? What's wrong with sending two packets in the same frame? If you really want to prevent the device from sending more than one packet per frame, you shouldn't submit them so fast. After submitting a packet, wait until the packet has been sent to the host and a frame boundary has occurred before submitting the next packet. > What is causing this issue? You are. > Should I config something in the FW related to the USB and DMA > registers? It's pretty hard to answer that without knowing anything about the device's USB and DMA registers. > Is this a "babble" condition? No. "Babble" means the device transmitted more data than the host expected. > Can I force the host to poll every time I have data? No. The host polls when it wants to; you can't affect it. > It polls every 1ms > anyway on the interrupt eps. I use a Poll Demand trigger every time I > have data available for the DMA to transfer to the USB TxFifo, but > these concatenations still happen. Alan Stern ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
