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
