Hi,
I have a user space application which communicates with an embedded
micro-controller over USB via an FTDI FT232H chip.
I'm seeing occasional data loss while reading data transmitted by the
micro, and I believe that when this occurs the FTDI UART Rx fifo is
being
overrun (there's no flow control between the micro and FTDI part).
I captured a trace of one of these overflows using usbmon and it
appears to
show the host stops polling the FTDI device for 200ms. The FTDI chip
is
at address 2:011, there's also a USB mass storage device on the bus at
2:002:
Normal bulk-in transfers, submissions/callbacks are all interleaved,
FTDI
status bytes == 0x3620:
f7243700 878013928 C Bi:2:011:1 0 202 = 326006ae ...
f7243700 878013948 S Bi:2:011:1 -115 512 <
f7243d00 878014928 C Bi:2:011:1 0 202 = 3260994f ...
f7243d00 878014948 S Bi:2:011:1 -115 512 <
f7243700 878015921 C Bi:2:011:1 0 202 = 3260543e ...
Then we see two callback responses to a single submission:
f7243700 878015939 S Bi:2:011:1 -115 512 <
f7243d00 878016920 C Bi:2:011:1 0 202 = 32609a01 ...
f7243700 878017929 C Bi:2:011:1 0 202 = 3260cf55 ...
Then the trace goes idle for almost 200ms, eventually there are some
transfers to/from the mass storage device:
f71cef80 878215673 C Bi:2:002:1 0 13 = 55534253 f82a0000
00000000 00
f71cef80 878215857 S Bo:2:002:2 -115 31 = 55534243 ...
f71cef80 878215922 C Bo:2:002:2 0 31 >
f7243680 878215953 S Bo:2:002:2 -115 512 = 626f6f74 ...
f7243680 878218558 C Bo:2:002:2 0 512 >
f71cef80 878218605 S Bi:2:002:1 -115 13 <
f71cef80 878228672 C Bi:2:002:1 0 13 = 55534253 f92a0000
00000000 00
~212ms after the last exchange with the FTDI device, the host appears
to
send two back-to-back Bi submissions (18us apart), the responses from
the
FTDI device show the status bytes have changed to 0x3262. I believe
the
bit that's changed indicates an overrun of the FTDI Rx FIFO (not
surprising
if it's not been serviced for over 200ms):
+212078 f7243700 878230007 S Bi:2:011:1 -115 512 <
f7243d00 878230025 S Bi:2:011:1 -115 512 <
f7243700 878230167 C Bi:2:011:1 0 202 = 32624c06 ...
f7243700 878230186 S Bi:2:011:1 -115 512 <
f7243d00 878230194 C Bi:2:011:1 0 202 = 3262ae09 ...
f7243d00 878230200 S Bi:2:011:1 -115 512 <
f7243700 878230288 C Bi:2:011:1 0 2 = 3262
f7243700 878230294 S Bi:2:011:1 -115 512 <
f7243d00 878230922 C Bi:2:011:1 0 176 = 3260398e ...
f7243d00 878230944 S Bi:2:011:1 -115 512 <
The ttyUSBX device remains open throughout, and my application is
polling/reading the device descriptor in a loop.
Kernel is:
3.10.17-yocto-standard (latest from the Yocto poky stable branch).
The host controller is:
Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev
04)
I realise that this configuration is never going to be that reliable
without flow control between the micro and the FTDI chip, but I was
hoping
that somebody might be able to help explain why the host appears to
have
stopped polling the device for >200ms?
--
Chris Sykes
chris@xxxxxxxxxxxxxxxxxxxxxxxxxx
--
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
