I have a weird problem to solve. I have developed an USB sound card with an own firmware implementation (inspired from the XMOS UAC project). The firmware works fine under normal conditions. When I output music and penetrate the sound card with ESDs, the output stops and the mixer doesn't work anymore. I have sniffed the USB communication with Wireshark/USBmon under linux and I was able to identify many communication errors.
The sound card uses multiple endpoints, including an endpoint for audio streams in and out. The first communication error I have found, happens to the endpoint for isochronous stream in. I suspect that I could have found the error at another endpoint as well at first.
Here is the output of the first erroneous USB frame, that wireshark has logged:
Frame 193151: 84 bytes on wire (672 bits), 84 bytes captured (672 bits) on interface usbmon2, id 0 USB URB [Source: 2.3.1] [Destination: host] URB id: 0xffff9edcc9372000 URB type: URB_COMPLETE ('C') URB transfer type: URB_ISOCHRONOUS (0x00) Endpoint: 0x81, Direction: IN 1... .... = Direction: IN (1) .... 0001 = Endpoint number: 1 Device: 3 URB bus id: 2 Device setup request: not relevant ('-') Data: present (0) URB sec: 1655901567 URB usec: 891490 URB status: Success (0) URB length [bytes]: 4 Data length [bytes]: 20 [Request in: 193134] [Time from request: 0.004017000 seconds] [bInterfaceClass: Unknown (0xffff)] ISO error count: 0 Number of ISO descriptors: 1 Interval: 8 Start frame: 1008 Copy of Transfer Flags: 0x00000204, No transfer DMA map, Dir IN Number of ISO descriptors: 1 USB isodesc 0 [Protocol error (-EPROTO)] (4 bytes) Status: Protocol error (-EPROTO) (-71) Offset [bytes]: 0 Length [bytes]: 4 Padding: 0x00000000
According to USB Error codes EPROTO means:
- bitstuff error
- no response packet received within the prescribed bus turn-around time
- unknown USB error
In my code only the EP0 (Control) is OR-ed with XUD_STATUS_ENABLE.
In 4.2.11 Status Reporting is the behavior of XUD_STATUS_ENABLE described.
- Shouldn't an ESD test cause an USB protocol error? That means, the error is caused by a bad hardware design?
- If an protocol error happens i.e. inside isochronous stream, should lib_usd fix this error itself?
- If lib_usd doesn't fix this error itself, should I OR-ing all my endpoints with XUD_STATUS_ENABLE and implement an error handling according to the function "USB_StandardRequests()" in "xud_device.xc" by calling "XUD_SetStall()" myself in an error case?
- Should I do something completely different?