On 12/02/2014 04:04 PM, Uwe Bonnes wrote:
Hendrik> They are there but a bit hidden:
Hendrik> http://pastebin.com/raw.php?i=3Vwk2NAs You can see that the
Hendrik> packet with size 327 comes in with 0162 and the following
Hendrik> packets show 0160 again.
5.977422 1<-- 33: 0160 0202 0619 001f 4000 0100 0102 ...
5.978486 1<-- 52: 0160 1617 1819 1a1b 1c1d 1e1f 2021 ...
5.985341 1<-- 327: 0162 4849 4a4b 4c4d 4e4f 5051 5253 ...
5.986459 1<-- 52: 0160 a5a6 a7a8 a9aa abac adae afb0 ...
5.987462 1<-- 44: 0160 d7d8 d9da dbdc ddde dfe0 e1e2 ...
More remarks:
- About 8 ms elapsed between the second and the third call. This is doomed for
overflow.
Are you sure that this is what happens or that this only seems to
happen? The 327 bytes packet consists of multiple 64 byte packets
containing the status bytes and data. I'm not completely sure if that is
what usbdump tells me, but maybe it is only the return time of that
complete transfer. So you indeed observe multiple shorted sized packets
coming in every millisecond, but the 327 bytes data transfer internally
contains 5+ 64 byte packets (though that are listed as one), so it takes
~7 ms but it also has about 6 'packets' inside so it is not strange that
it takes multiple milliseconds. With 50 bytes per millisecond being sent
to the FTDI by the microcontroller this transfer containing multiple 64
byte packets should not have caused an overflow because the transfer was
already in progress?
Still the overflow bit is set so the overflow case stands. But on the
other hand: transfers with a larger latency timer are listed as one
transfer of 522 bytes which is way over the FTDI buffer anyway, but
those cases mostly don't cause problems.
- Transfers only happen in milisecond frame. Is your USB hub not USB high
speed?
It is, but maybe it is not a multi-tt HUB. From what I read a full speed
device on a non multi-tt hub will force the downstream to be full speed
instead of high speed. I tried directly on my PC but that did not change
it though. Same problem.
- You transfer short packages due to the 1 ms latency. 1 ms with about 50
bytes is too small to fill up the USB buffer with 62 bytes.
Try to set latency to 2 ms. Then you transfer full 62 byte buffers.
True but the problem persists. With the latency timer set to a high
value it 'almost never' goes wrong. I don't really understand why the
latency timer has so much influence on causing an overflow inside the FTDI.
Some percentages:
Latency vs percentage of failed transfers (in which I don't receive the
522 bytes packet)
1 -> 1.37%
2 -> 0.41%
4 -> 0.14%
16 -> 0.11%
Regards,
Hendrik
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
| 