On Tue, 3 Jan 2017 18:18:02 +0100, Vincent Pelletier
<plr.vincent@xxxxxxxxx> wrote:
> Sadly, this fix alone is not enough to get a functional device. I did
> not investigate much yet, and need to get some sleep.
I investigated more.
The next issue is that often (>9 times out of 10) the dwc3 fails to
respond to the SET_CONFIGURATION standard request. As a result, only
EP0 works.
Host-side, syslog contains a -110 (ETIMEDOUT) error. Re-triggering a
SET_CONFIGURATION causes the same timeout to happen again.
Device-side, functionfs does trigger the "ENABLE" event.
Altogether, ep0 does work (vendor-specific requests from host do get
received by the program on device which listens to events on ep0 file).
Host (comprehensibly) refuses to emit requests to endpoints which are
not considered as configured, so I cannot test this part.
Plugging my USB protocol analyser, I see corrupted USB PIDs. Here is a
capture, starting at the beginning od the last GET_DESCRIPTOR
transaction before the SET_CONFIGURATION one:
001:23.273'515"383n SETUP @054.00 DATA0 8B ACK
000 80 06 03 03 09 04 ff 00 ........
001:23.273'518"000n IN @054.00 NAK
001:23.273'539"966n IN @054.00 NAK
001:23.273'582"983n IN @054.00 NAK
001:23.273'604"666n IN @054.00 DATA1 34B ACK
000 22 03 46 00 5a 00 45 00 44 00 34 00 34 00 33 00 ..F.Z.E.D.4.4.3.
010 44 00 30 00 31 00 54 00 34 00 32 00 35 00 30 00 D.0.1.T.4.2.5.0.
020 31 00 1.
001:23.273'607"666n OUT @054.00 DATA1 0B NAK
001:23.273'628"966n PING @054.00 NAK
001:23.273'649"650n PING @054.00 NAK
001:23.273'683"966n PING @054.00 ACK
001:23.273'685"300n OUT @054.00 DATA1 0B ACK
001:23.274'459"183n (bad pid) 0xf0 0x36 0xf8
001:23.275'036"750n (bad pid) 0x03 0x00 0x00 0x00 0x96 0x52 0x68 0xfa
001:23.275'037"266n SETUP @054.00 DATA0 8B ACK
000 00 09 01 00 00 00 00 00 ........
001:23.275'039"750n IN @054.00 NAK
001:23.275'067"183n IN @054.00 NAK
001:23.275'110"183n IN @054.00 NAK
001:23.275'131"866n IN @054.00 NAK
001:23.275'153"183n IN @054.00 NAK
001:23.275'196"200n IN @054.00 NAK
001:23.275'217"883n IN @054.00 NAK
001:23.275'239"200n IN @054.00 NAK
001:23.275'260"883n IN @054.00 NAK
001:23.275'287"300n IN @054.00 NAK
001:23.275'308"900n IN @054.00 NAK
001:23.275'329"900n IN @054.00 NAK
001:23.275'356"216n IN @054.00 NAK
001:23.275'377"900n IN @054.00 NAK
001:23.275'399"216n IN @054.00 NAK
001:23.275'442"233n IN @054.00 NAK
001:23.275'463"916n IN @054.00 NAK
001:23.275'485"233n IN @054.00 NAK
001:23.275'506"916n IN @054.00 NAK
001:23.275'528"233n IN @054.00 NAK
001:23.275'571"250n IN @054.00 NAK
001:23.275'592"933n IN @054.00 NAK
001:23.275'614"250n IN @054.00 NAK
001:23.275'635"933n IN @054.00 NAK
001:23.275'662"350n IN @054.00 NAK
001:23.275'683"950n IN @054.00 NAK
001:23.275'706"266n IN @054.00 NAK
001:23.275'727"950n IN @054.00 NAK
001:23.275'749"266n IN @054.00 NAK
001:23.275'770"950n IN @054.00 NAK
001:23.275'811"200n (bad pid) 0xf0 0x36 0xf8
001:23.275'792"266n IN @054.00 NAK (incomplete transaction)
001:23.278'811"983n HS idle
The format being:
timestamp token_type "@"device"."endpoint data_type bytes"B" handshake_type
data_stage_hexdump
Strangely, when plugging the device on a hub seems to improve the
situation. Sadly, my protocol analyser gets confused when plugged
between that hub and the device, and fails to capture anything (it
likely fails to detect the chirp handshake).
There seems to be another issue (or is it just a consequence of this
one ?) where it may become completely silent, unable to join the bus
when udc identifier is writted to UDC file.
Regards,
--
Vincent Pelletier
--
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
