This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001024] STM32 USB driver and proposed USB API change


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

--- Comment #19 from Chris Holgate <chris@zynaptic.com> 2010-10-16 13:17:42 BST ---
(In reply to comment #18)
> (In reply to comment #17)
> 
> > The fact that you have a USB bus sniffer could be very useful here. Could you
> > check to see if the host is sending anything else in addition to the packets
> > containing the characters.  In particular, is it sending out any zero length
> > packets in between the character packets?
> 
> The host does not send any out-packets other than the ones containing the
> characters typed in minicom. Depending on how fast I type, there are
> occasionally intermitted in-packets which are NAK-ed (device has nothing to
> send).

Ok - that eliminates on possible cause.  The bug is obviously an issue with the
double buffering on bulk endpoints, but I have not seen it before with my class
driver.  The most obvious difference here is that John's request is sized
'exactly' for a single character, while I have been using an oversized receive
buffer.

Does the problem still occur if the request specifies an RX buffer size of,
say, 100 characters?  Also, can you check that your build has asserts enabled,
since most of the unexpected driver behaviour should be covered by assert
conditions.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]