Odd USB testbench behaviour.

[Chris Holgate <chris at zynaptic dot com>]

Hi folks,

I've now nearly finished the STM32 USB driver and have it running
reliably in my application stress test (ie, my own eCos USB class driver
and Linux kernel driver).  I thought I'd also try it against the
standard eCos testbench (specifically bulk-boundaries) - which has
already proved valuable in trapping a race condition I'd otherwise missed.

When running bulk-boundaries on my OpenSuse 11.0 host, I can see the
device to host transfers running correctly (even though the script
reports 'failed'!).  However, the host to device traffic looks very odd
and results in the tests reporting received (at the device) message
lengths of 0 for all tests up to message length 64, where the host and
device then go out of sync.  Tapping into the transaction completion
handler, I see the following sequence of messages are being received at
the device side:

STM32 USB : RX transaction complete (endpoint 3, length 1).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 1).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 2).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 3).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 4).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 5).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 7).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 8).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 9).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 15).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 16).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 17).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 31).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 32).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 33).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 63).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 64).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 1).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 63).
STM32 USB : RX transaction complete (endpoint 3, length 0).
STM32 USB : RX transaction complete (endpoint 3, length 64).
STM32 USB : RX transaction complete (endpoint 3, length 64).
STM32 USB : RX transaction complete (endpoint 3, length 64).
FAIL:<Test abort requested by host application> Line: 1350, File:
/zynaptic/projects/eCos/working-02.01.09/ecos/packages/io/usb/slave/current/tests/usbtarget.c
EXIT:<done>

It looks as though the host is adding in zero length messages between
the messages I would expect to see.  I'm guessing that this is
unintended and may be as a result of me using a newer version of usbfs
than the one originally tested against.  Can anyone shed some light on this?

Chris.