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.
My questions:
- 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?
Dieter