Hi Alan, So now, I have two options as per your mail. First: If I modify my device's firmware so what type of modification it should be. Shall I prevent device from sending pkt size of 1042 in isochronous mode ? Please elaborate. But I would like to mention that device belongs to third party and I cannot change its firmware and I want to handle this issue some how at the host side only. Second: At host side you said I have to handle this error at all levels, even if I handle the error at all levels, but PORTSC connection bit reports 0 i.e. no device connected then how do I prevent that. Because even if I handle the error but disconnection happens it stops streaming, so whatsoever handling I implement it should prevent this disconnnection Can you plz give me some pointers to do so. Further I don't even know from which side disconnect is initiated, Can u plz suggest some method to find it out. ? Regards Nitin Arora On Tue, Jan 4, 2011 at 8:57 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 4 Jan 2011, Nitin Arora wrote: > >> Hello, >> >> I am trying to stream audio from usb audio device to my embedded host >> through USB 2.0. >> My host system is arm based . >> device is configured as audio device and using USB Audio class driver >> in Isochronous mode. >> >> Every thing is working fine but suddenly while audio is being streamed >> we get an USB error >> EOVERFLOW and host controller doesn't detect the device any more. >> I have checked the "Current Connect Status" bit (bit-0) in PORTSC >> register according to EHCI specification. >> Its value is 0. >> Which means that after EOVERFLOW error occurs connection is broken >> either from device side or host side. >> >> I observed USB analyser traces, it shows a failed USB transaction >> wherein it shows a packet of size >> 1042 arriving from device to Host whereas the max packet size in >> isochronous mode is 1024 >> (Most probable reason for overflow). >> >> I am a beginer in USB and my question is that >> >> 1. Where should this error be handled, At host controller (h/w) level, >> HCD level, USB Protocol Level or device firmware . > > It should be handled at all those levels. The host controller should > recognize that it received a packet that was too long, the HCD should > recognize that the transaction failed, the protocol specifies that the > transaction should not be retried, and the firmware should avoid > generating those bad packets in the first place. > >> 2. What type of error it is h/w, s/w. > > Either the device's hardware or the device's firmware. Not an error in > the host. > >> 3. I tried to ignore overflow error for that particular micro frame >> and keep on processing successive uframes >> but because the "current connect status" is already 0 >> (disconnected). No use of doing that. > > That isn't a question. > >> Please suggest me how can I prevent or recover from this error at >> software level. > > You have to fix the device's hardware or firmware. Changing the host > won't help. > > Alan Stern > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
