Xiaofan,
I managed to liase with Pete, and after some discussion, found that if
WinUSB accepts the second round of data, sends it, and then reports a
failure, it would seem that it's detecting that the device reports an error
and stalls as a result (in which case the CSW can never be read as it need
to go through an endpoint reset)
So, eventually, some changes is made in the part during _read in libusb10.py
that upon receiving a stall, retry one more time. Apparently this method
works and the CSW is returned. I ain't sure whether its a bug itself or even
usbstor.sys might be also doing similar actions.(Pete has similar thoughts
too)
Just placing the comments here in case the next user of PyUSB using libusb10
and communicating with a usb mass storage would have some leads for
troubleshooting.
Thanks.
On Wed, Aug 25, 2010 at 9:37 AM, Xiaofan Chen <xiaof...@gmail.com> wrote:
> On Tue, Aug 24, 2010 at 5:13 PM, Max Teo <max...@gmail.com> wrote:
> >>>> ind.read(13, timeout=5000)
> > libusb:debug [libusb_get_config_descriptor] index 0
> > libusb:debug [libusb_get_config_descriptor] index 0
> > libusb:debug [winusb_submit_bulk_transfer] matched endpoint 81 with
> > interface 0
> > libusb:debug [usbi_create_fd] could not duplicate handle for CancelIo -
> > using original one
> > libusb:debug [winusb_submit_bulk_transfer] reading 13 bytes
> > libusb:debug [usbi_add_pollfd] add fd 4 events 1
> > libusb:debug [libusb_get_next_timeout] next timeout in 4.999235s
> > libusb:debug [handle_events] poll() 2 fds with timeout in 5000ms
> > libusb:debug [handle_events] poll() returned 1
> > libusb:debug [windows_handle_events] checking fd 3 with revents = 0000
> > libusb:debug [windows_handle_events] checking fd 4 with revents = 0001
> > libusb:debug [usbi_remove_pollfd] remove fd 4
> > libusb:debug [windows_transfer_callback] handling I/O completion with
> > errcode 31
> > libusb:debug [windows_transfer_callback] detected endpoint stall
> > libusb:debug [bulk_transfer_cb] actual_length=0
> >
> > I tried polling for a few times by sending a libusb_clear_halt,
> > (technically its not required for the other standalone program)
> > but got back the Pipe error.
>
> You snipped too many things to make the whole thing meaningful.
> However I think this is kind of device problem, which means the
> device does not like this sequence of commands.
>
> >
> >> Since you have the bus analyzer, you can see the differences
> >> on the wire.
> >>
>
> As I mentioned before, you can use the Bus Analyzer to see
> the sequence the other working program sends out, and then
> you can try it with your pyusb using the same sequence.
>
>
> --
> Xiaofan
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> pyusb-users mailing list
> pyusb-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
pyusb-users mailing list
pyusb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pyusb-users
