libusb-win32-devel

[Libusb-win32-devel] question on usb_bulk_read

[Qianqian F. <fa...@gm...>]

hi

I am trying to access a device using libusb-win32 0.1 on windows. The device
is a Polhemus 3D tracker, I tried libusb-win32, and things are working fine
at the beginning: list of the usb devices work properly; I can match VID and
PID and get the device I want and set configuration/claim the connection.
And then it comes to sending a command and read the output. I tried the
following:

usb_bulk_write(PolhemusUSB,0x02, "P", 64, 65535);
ret=usb_bulk_read(PolhemusUSB,0x82,recv_data,64,1000)

For the first time to call this, I got the correct results ("P" command is
to tell the current positions); however, if I call it again, I will get
"usb_reap: timeout error" at usb_bulk_read().

Similarly, I tried another command "^V\r", which is supposedly to print the
whoami info, the first time, I got partial of the output limited by the
bMaxPacketSize0; and call usb_bulk_read again, it will return the remaining
part of the whoami info, then, if I call it for the 3rd time, it will
time-out.

My feeling is that there is a buffer pointer shifted every time when you do
a read, and it might need to be reset to the starting address for each read
(in the case of "P" command), but I am not sure if this is true, and how to
do the reset.

I had talked to the customer support of Polhemus, and they shared me some
libusb1.0 code work for Linux, but I want to work on windows for now. I
noticed that libusb-win32 hasn't released a windows port for libusb 1.0 yet
(I downloaded the svn libusb1 branch, and compiled under cygwin, but I can
not find the lib files for borland compilers that I need).

I am wondering if anyone can comment on the phenomena I have seen, and
possibly a workaround for this.
I am greatly appreciated for your input. Also, if there is a way to get
libusb1.0 working on windows, I would be very glad to learn.

thank you very much.

Qianqian
-- 
View this message in context: http://www.nabble.com/question-on-usb_bulk_read-tp22382485p22382485.html
Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com.

Re: [Libusb-win32-devel] question on usb_bulk_read

[Martin P. <vad...@gm...>]

On 09/03/2009, Qianqian Fang <fa...@gm...> wrote:
>
>  hi
>
>  I am trying to access a device using libusb-win32 0.1 on windows. The device
>  is a Polhemus 3D tracker, I tried libusb-win32, and things are working fine
>  at the beginning: list of the usb devices work properly; I can match VID and
>  PID and get the device I want and set configuration/claim the connection.
>  And then it comes to sending a command and read the output. I tried the
>  following:
>
>  usb_bulk_write(PolhemusUSB,0x02, "P", 64, 65535);
>  ret=usb_bulk_read(PolhemusUSB,0x82,recv_data,64,1000)

I'm not a libusb expert (and I know nothing about Polhemus) but
perhaps do you should be calling it to send a 1 byte packet rather
than 64 bytes? with something like:

usb_bulk_write(PolhemusUSB,0x02, "P", 1, 65535);

(Otherwise I believe it would send the P character, 0 byte for end of
string, and then 62 bytes of garbage)

If you look at the prototypes, the last 3 parameters are buffer, size
and timeout:

http://libusb.sourceforge.net/doc/ref.bulk.html

>  For the first time to call this, I got the correct results ("P" command is
>  to tell the current positions); however, if I call it again, I will get
>  "usb_reap: timeout error" at usb_bulk_read().

This is probably because the device isn't sending any packets back
when you call the read function. I have noticed that libusb or windows
seems to expect a zero-length packet if you are reading the max.
packet size, and it complains about a timeout when this happens (but
it's okay if usb_bulk_read returns a number less than requested size)

>  Similarly, I tried another command "^V\r", which is supposedly to print the
>  whoami info, the first time, I got partial of the output limited by the
>  bMaxPacketSize0; and call usb_bulk_read again, it will return the remaining
>  part of the whoami info, then, if I call it for the 3rd time, it will
>  time-out.

What do you expect to be returned the third time?

Re: [Libusb-win32-devel] question on usb_bulk_read

[Dennis M. <djm...@gm...>]

Martin Panter wrote:
> On 09/03/2009, Qianqian Fang <fa...@gm...> wrote:
> 
> This is probably because the device isn't sending any packets back
> when you call the read function. I have noticed that libusb or windows
> seems to expect a zero-length packet if you are reading the max.
> packet size, and it complains about a timeout when this happens (but
> it's okay if usb_bulk_read returns a number less than requested size)
> 

I'm currently experiencing an issue that may be related to this.  I have 
a device that I want to read an image from.  I request usb_bulk_read 
with a buffer big enough to capture the entire image.  I'm noticing 
strange behavior.

My device fills the ep buffer to the max size for each write.  Size of 
Buffer is 1024 bytes.  Image size varies.  It may take many packets to 
transfer the entire image.  (Up to 5 or 6 MB).

Here are some setups for testing I have:

Linux.  Works correctly.
Windows XP running in Vmware w/ Linux host: Works Correctly.
Windows XP running in Vmware w/ Mac host: usb_reap error/timeout error 
described in this thread.
Windows XP on native hardware: Locks up entire machine when I call 
usb_bulk_read.

I'm going to experiment requesting smaller packets for the read in my 
driver and see if that alters things.

Can anyone elaborate more on this packet size problem and 
usb_reap/timeout errors.  Is it a common thing to send data smaller than 
the max packet size simply so the driver works correctly?  Should I call 
usb_bulk_read in a loop with each read reading an amount of data smaller 
than the max packet size instead of one call to usb_bulk_read with the 
whole buffer?

-Dennis

Re: [Libusb-win32-devel] question on usb_bulk_read

[Martin P. <vad...@gm...>]

>  Can anyone elaborate more on this packet size problem and
>  usb_reap/timeout errors.  Is it a common thing to send data smaller than
>  the max packet size simply so the driver works correctly?  Should I call
>  usb_bulk_read in a loop with each read reading an amount of data smaller
>  than the max packet size instead of one call to usb_bulk_read with the
>  whole buffer?

In my case my device sends packets of up to 512 bytes. I think this is
defined in the usb descriptor returned from the device, but I could be
wrong.

Here are some observations that I remember:

Bulk read of 1-511 bytes would return a failure (don't think it was a
time out) if the packet had more bytes in it than requested. If you
then called bulk read with a bigger number it would return the same
packet successfully.

Bulk read of 512 bytes would succeed if the first packet waiting in
the device was less than 512 bytes long. If the first packet was a
full 512 bytes, I think the read function would happily return without
trying to read any more packets (even if the device has a zero-length
packet waiting). I think if there was a zero length packet, it would
be read and ignored during the next bulk read.

Bulk read expecting more than 512 bytes: If the device wanted to send
exactly 512 bytes, libusb or windows would expect a second zero-length
packet (or a packet with more data) following the first packet,
signifying that the end of the transfer. If it did not see another
packet it would time out, and I think the original 512 bytes was lost.

The same sort of pattern happens with sending exactly 1024 bytes etc:
libusb/windows expects a ZLP if you request more than 1024 bytes.

Also I noticed that a bulk read requesting zero bytes always fails,
even if there's a zero length packet waiting.

Hope this helps. If the driver knows exactly how many bytes are
expected, then I think there shouldn't be any problems with expecting
zero length packets. Otherwise I guess you'd have to read it packet by
packet until you know there should be no more data.

Re: [Libusb-win32-devel] question on usb_bulk_read

[Dennis M. <djm...@gm...>]

Martin Panter wrote:
>>  Can anyone elaborate more on this packet size problem and
>>  usb_reap/timeout errors.  Is it a common thing to send data smaller than
>>  the max packet size simply so the driver works correctly?  Should I call
>>  usb_bulk_read in a loop with each read reading an amount of data smaller
>>  than the max packet size instead of one call to usb_bulk_read with the
>>  whole buffer?
> 
> In my case my device sends packets of up to 512 bytes. I think this is
> defined in the usb descriptor returned from the device, but I could be
> wrong.
> 
> Here are some observations that I remember:
> 
> Bulk read of 1-511 bytes would return a failure (don't think it was a
> time out) if the packet had more bytes in it than requested. If you
> then called bulk read with a bigger number it would return the same
> packet successfully.
> 
> Bulk read of 512 bytes would succeed if the first packet waiting in
> the device was less than 512 bytes long. If the first packet was a
> full 512 bytes, I think the read function would happily return without
> trying to read any more packets (even if the device has a zero-length
> packet waiting). I think if there was a zero length packet, it would
> be read and ignored during the next bulk read.
> 
> Bulk read expecting more than 512 bytes: If the device wanted to send
> exactly 512 bytes, libusb or windows would expect a second zero-length
> packet (or a packet with more data) following the first packet,
> signifying that the end of the transfer. If it did not see another
> packet it would time out, and I think the original 512 bytes was lost.
> 
> The same sort of pattern happens with sending exactly 1024 bytes etc:
> libusb/windows expects a ZLP if you request more than 1024 bytes.
> 
> Also I noticed that a bulk read requesting zero bytes always fails,
> even if there's a zero length packet waiting.
> 
> Hope this helps. If the driver knows exactly how many bytes are
> expected, then I think there shouldn't be any problems with expecting
> zero length packets. Otherwise I guess you'd have to read it packet by
> packet until you know there should be no more data.
> 
> ------------------------------------------------------------------------------

My problem isn't with the packet length it seems.  I always know exactly
how many bytes I should read.  I haven't narrowed down exactly what the
issue is yet.  Right now, my issue is that the 1st few times I request a
read, I get the timeout error.  After that it seems to work fine.  This
doesn't happen on Linux though.

My older issue with BSoD was related to the maximum packet size in the
descriptor.  I didn't notice the max allowed for bulk endpoints was 512
and had it set to 1024 (the device supports that.)  On Linux, libusb was
forgiving and things work right but on Windows no such luck.

The timeout issues haven't gone away though.  I've tried reading a fixed
set of bytes at a time in multiple reads or reading the entire set of
data in one read.  It doesn't seem to affect the timeout issue either way.

-Dennis

Re: [Libusb-win32-devel] question on usb_bulk_read

[Dennis M. <djm...@gm...>]

Martin Panter wrote:
>>  Can anyone elaborate more on this packet size problem and
>>  usb_reap/timeout errors.  Is it a common thing to send data smaller than
>>  the max packet size simply so the driver works correctly?  Should I call
>>  usb_bulk_read in a loop with each read reading an amount of data smaller
>>  than the max packet size instead of one call to usb_bulk_read with the
>>  whole buffer?
> 
> In my case my device sends packets of up to 512 bytes. I think this is
> defined in the usb descriptor returned from the device, but I could be
> wrong.
> 
> Here are some observations that I remember:
> 
> Bulk read of 1-511 bytes would return a failure (don't think it was a
> time out) if the packet had more bytes in it than requested. If you
> then called bulk read with a bigger number it would return the same
> packet successfully.
> 
> Bulk read of 512 bytes would succeed if the first packet waiting in
> the device was less than 512 bytes long. If the first packet was a
> full 512 bytes, I think the read function would happily return without
> trying to read any more packets (even if the device has a zero-length
> packet waiting). I think if there was a zero length packet, it would
> be read and ignored during the next bulk read.
> 
> Bulk read expecting more than 512 bytes: If the device wanted to send
> exactly 512 bytes, libusb or windows would expect a second zero-length
> packet (or a packet with more data) following the first packet,
> signifying that the end of the transfer. If it did not see another
> packet it would time out, and I think the original 512 bytes was lost.
> 
> The same sort of pattern happens with sending exactly 1024 bytes etc:
> libusb/windows expects a ZLP if you request more than 1024 bytes.
> 
> Also I noticed that a bulk read requesting zero bytes always fails,
> even if there's a zero length packet waiting.
> 
> Hope this helps. If the driver knows exactly how many bytes are
> expected, then I think there shouldn't be any problems with expecting
> zero length packets. Otherwise I guess you'd have to read it packet by
> packet until you know there should be no more data.
> 
> ------------------------------------------------------------------------------

Ok, here is some additional info with my tests:

1) I send a vendor command to my device to tell it how many bytes I want 
to read before I initiate a bulk transfer.  The device will commit 512 
byte packets until the last remaining packet, which will be the 
remainder of the amount to transfer.

2) I call usb_bulk_read in a loop where each time I request the amount 
of data to read is the length-transferred (I attempt to read all the 
data in one read if possible).

So I run the test with 1024 bytes and it works every time.  Device 
commits two 512 byte packets.. no timeouts.

Now I run the test with 1025 bytes.  The device sends:
512, 512, 1
lib usb reads 1025 bytes.

Now run the program again:
device: 512 512 1
lib usb reads 513, then attempt 512: usb_reap: timeout error.

Each time I run the program, I get this behavior.  It works once then 
fails once.

If I try reads with 768 bytes, it works every time:
device: 512 256
lib usb reads 768

Attempt with 100 I get the works/fails pattern again:
1st run
device: 100
lib usb: 100

2nd run:
device: 100
lib usb: usb_reap: timeout error.

So in summary, it seems to have everything to do with the number of 
packets being transferred.  If I transfer an odd number of packets, it 
fails every other time.  If I transfer an even number of packets, I 
haven't seen it ever time out yet.

Last example:
2049 bytes (4 512 packets + 1 byte)
device: 512 512 512 512 1
1st read: 2049 bytes attempted: returns 1537 bytes read
2nd read: 512 bytes attempted: usb_reap: timeout error.


I'm not sure why libusb's first read doesn't return the whole 2049 bytes 
and returns 1537 bytes instead (well, every other time I run the program 
it _does_ return the 2049 bytes).  Is there a device situation that 
would cause usb_bulk_read to not transfer all the data requested?  In my 
case, it seems to be when the transfer requires an odd number of packets 
but that seems weird to me.  Perhaps someone else can elaborate more.

I haven't entirely ruled out a device firmware problem.  Perhaps the 
endpoint toggle is not correct or something.

Thanks
Dennis

Re: [Libusb-win32-devel] question on usb_bulk_read

[Xiaofan C. <xia...@gm...>]

On Wed, Apr 8, 2009 at 1:58 AM, Dennis Muhlestein
<djm...@gm...> wrote:
>
> Back to the toggle problem.  On Linux, the device does get a set
> configuration and set interface command each time I run my program and
> the usb configuration methods are called.  On Windows, this doesn't
> happen.  Because I reset the endpoint toggle in the set interface
> command, when that command isn't called, the endpoint toggle is in the
> wrong state.  Hense the lost 1st packet on bulk_read.

This seems to be a device firmware bug. I believe you have to reset
the toggle when it gets the set configuration command. set configuration
is kind of lite version of device reset.

Xiaofan

Re: [Libusb-win32-devel] question on usb_bulk_read

[Xiaofan C. <xia...@gm...>]

On Wed, Apr 8, 2009 at 9:21 AM, Dennis Muhlestein
<djm...@gm...> wrote:
> I've tried resetting the toggle in both set configuration and in set
> interface.  On Windows, I receive neither a set interface OR a set
> configuration message when the program opens the device.  I do receive a
> set configuration when I first plug the device in but that of course
> doesn't solve the issue.

Are you using the filter driver or the device driver? If you are using
the filter driver, try the device driver instead (using the inf wizard
to create the INF and then install the driver).

Which version of libusb-win32 are you using? Supposedly you will
not get a  set configuration when you first plug the device in the
latest version of libusb-win32. But you will get a set configuration
when you call usb_set_configuration() every time. Please
try the latest version (0.12.1 and the Subversion version).

> I have a temporary workaround for this by creating a 0 endpoint
> interface alt setting (0) and then putting my endpoints in alt setting
> (1).  Then, I call usb_set_interface(..., 1) instead of
> usb_set_interface(...,0).  In this situation, my device does get the set
> interface command and I no longer have the read errors.
>
> So, the question is.. what is wrong with having my IO endpoints in alt
> setting 0?

I think there is nothing wrong. But I do not think it is necessary.
You can use it if it works though.

> Is this the correct behavior to not send the device a set
> interface command when the interface is 0?  Perhaps my workaround is
> better but I'm not sure about this.

I am thinking it is not a bug if the previous call to usb_set_configuration
already set the default interface to 0.

Xiaofan

Re: [Libusb-win32-devel] question on usb_bulk_read

[ddp516 <bo...@an...>]

An update:
I now use one invocation usb_clear_halt.  This is a better approach.
I notice that the libusb-win32 documentation has been enhanced. It suggests
that clear_halt should be considered.
-- 
View this message in context: http://libusb.6.n5.nabble.com/question-on-usb-bulk-read-tp10980p511713.html
Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com.

Re: [Libusb-win32-devel] question on usb_bulk_read

[Dennis M. <djm...@gm...>]

Dennis Muhlestein wrote:

> 
> I'm not sure why libusb's first read doesn't return the whole 2049 bytes 
> and returns 1537 bytes instead (well, every other time I run the program 
> it _does_ return the 2049 bytes).  Is there a device situation that 
> would cause usb_bulk_read to not transfer all the data requested?  In my 
> case, it seems to be when the transfer requires an odd number of packets 
> but that seems weird to me.  Perhaps someone else can elaborate more.
> 
> I haven't entirely ruled out a device firmware problem.  Perhaps the 
> endpoint toggle is not correct or something.


OK, I can now fully explain my timeout problem.

My device resets the endpoint toggle when the claim interface command is 
  issued.  On Windows, (from the devices perspective), set configuration 
is only called when I first plug in the device and set interface is not 
being called.  From the lib-usb perspective, This is how I config the 
device:

usb_set_configuration(...
usb_claim_interface(...
usb_set_altinterface(...

Then I proceed to do reads/writes.

Back to the toggle problem.  On Linux, the device does get a set 
configuration and set interface command each time I run my program and 
the usb configuration methods are called.  On Windows, this doesn't 
happen.  Because I reset the endpoint toggle in the set interface 
command, when that command isn't called, the endpoint toggle is in the 
wrong state.  Hense the lost 1st packet on bulk_read.

So my problem isn't so much usb_bulk_read having an issue and is more 
the endpoint toggle not being in the right state.

Is not sending set_configuration and set_interface to the device a 
libusb-win32 bug?  A windows bug?  I could send a vendor command to 
reset the toggle at the beginning of my program but that seems more of a 
hack.

-Dennis

Re: [Libusb-win32-devel] question on usb_bulk_read

[Dennis M. <djm...@gm...>]

Xiaofan Chen wrote:
> On Wed, Apr 8, 2009 at 1:58 AM, Dennis Muhlestein
> <djm...@gm...> wrote:
>> Back to the toggle problem.  On Linux, the device does get a set
>> configuration and set interface command each time I run my program and
>> the usb configuration methods are called.  On Windows, this doesn't
>> happen.  Because I reset the endpoint toggle in the set interface
>> command, when that command isn't called, the endpoint toggle is in the
>> wrong state.  Hense the lost 1st packet on bulk_read.
> 
> This seems to be a device firmware bug. I believe you have to reset
> the toggle when it gets the set configuration command. set configuration
> is kind of lite version of device reset.

I've tried resetting the toggle in both set configuration and in set 
interface.  On Windows, I receive neither a set interface OR a set 
configuration message when the program opens the device.  I do receive a 
set configuration when I first plug the device in but that of course 
doesn't solve the issue.

I have a temporary workaround for this by creating a 0 endpoint 
interface alt setting (0) and then putting my endpoints in alt setting 
(1).  Then, I call usb_set_interface(..., 1) instead of 
usb_set_interface(...,0).  In this situation, my device does get the set 
interface command and I no longer have the read errors.

So, the question is.. what is wrong with having my IO endpoints in alt 
setting 0?  Is this the correct behavior to not send the device a set 
interface command when the interface is 0?  Perhaps my workaround is 
better but I'm not sure about this.

-Dennis

Re: [Libusb-win32-devel] question on usb_bulk_read

[Dennis M. <djm...@gm...>]

Xiaofan Chen wrote:
> 
> Are you using the filter driver or the device driver? If you are using
> the filter driver, try the device driver instead (using the inf wizard
> to create the INF and then install the driver).

I'm using the device driver.  The filter driver isn't installed.  I used 
the inf wizard to create the inf file and install the driver.

> 
> Which version of libusb-win32 are you using? Supposedly you will
> not get a  set configuration when you first plug the device in the
> latest version of libusb-win32. But you will get a set configuration
> when you call usb_set_configuration() every time. Please
> try the latest version (0.12.1 and the Subversion version).

0.12.1 is installed.  Are there differences between that and the 
subversion version?

> 
> I am thinking it is not a bug if the previous call to usb_set_configuration
> already set the default interface to 0.

I can see how the set_configuration might set the interface, and then 
since the interface is already 0, the call to claim_interface and 
set_altinterface don't actually send any usb commands.  That wouldn't 
explain why I don't get any set_configuration commands though.  I get 
the set_configuration when I plug in the device but that is it. 
Starting up my program and issuing the set_configuration command does 
not generate any usb commands.  Perhaps windows sees the configuration 
is already 1 and doesn't issue a set_configuration command.  Using XP 
Pro SP3 by the way.

When I run the program on linux, I see the set_configuration and 
set_interfaces commands on the device.

-Dennis

Re: [Libusb-win32-devel] question on usb_bulk_read

[DDP516 <bo...@an...>]

This is my experience:

The first time I run my application it works.
The second time I get: usb_reap: timeout error

If I modify my application to perform a write/read cycle 3 times it works at
the third attempt
after two usb_reap timeouts.
If I call usb_resetep twice the application works every time. Not if I only
do it once.

My application sends a bulk_write message to endpoint 1.
It then reads the resulting message with a bulk_read from endpoint 1.
I believe the bulk_write is not received by the firmware in the fx2 device
causing the
subsequent read error.
The application was ported from Linux - it was OK on Linux.
My device is a Cypress EZ-USB FX2 with custom firmware based on the Cypress
framework.
Using libusb-win32 release 1.12.1; Device driver; Windows XP

Use of usb_resetep as a workaround solves my problem but I would sure like a
better
understanding of the issue.

-- 
View this message in context: http://www.nabble.com/question-on-usb_bulk_read-tp22382485p24129085.html
Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com.