Question about pipes and ugen

[Julian Elischer]

M. Warner Losh wrote:

>In message: <41B0E6AE.4030207 at elischer.org>
>            Julian Elischer <julian at elischer.org> writes:
>: on our usb-scope the first commands on open are :
>: 
>: bmRequestrType    (setup packet to EP0) 80 06 01 03 00 00 00 02 00
>: followed by an IN from EP0 to retrieve a descriptor string.
>: the IN never completes..
>
>That's like the device that I've noticed the problem on.  I usually
>see a ClearFeature(Halt) go to the device before the first request to
>an endpoint after a pipe has been opened with ugen.  Are you not
>seeing that?
>
>: so the full picture is:
>: 
>: OUT to EP2  (1 byte  command requesting status to be fetched from EP3)
>: program exits due to some unspecified reason.. so IN on EP3 is never done..
>: [device apparently times out somehow and sets  HALT feature "HALT" on EP3]
>
>  
>


>Is this the ClearFeature(Halt) packet to endpoint 1?  I'm guessing
>not, but thought I'd ask.  Our device at least will accept the packet,
>but the firmware on the device goes catatonic until we send the write
>command a few more times and issue the reset a few more times.
>  
>

I take that back Here's a better description.

endpoints are:
0   setup
1 control channel in
2 control channel out
3 data in


the request for status is made to 2  (OUT, 1 byte)
the read that never happens would be on 1

On Linux:
After a large delay, we (after restarting the program) try to do the OUT 
to EP2 again.
(this is the first USB wire transaction since restarting the program)
we get  288000 NAKS (literally) before we time out.
To get things going again, linux libusb sends a ClearFeature(HALT) to EP2
and then follows it with a GetStatus(EP2) to check
and then retries the OUT to EP2 again, which now succeeds,


On FreeBSD 4-stable, the action of openning ugen.1 results in

mRequestrType    (setup packet to EP0) 80 06 01 03 00 00 00 02 00
followed by an IN on EP0 which just hangs.  (apparently the backing
firmware is still waiting to respond to an IN on EP1.)

Since the setup packet is part of the open() of ugen 0.1 and 0.0
we don't know to do a ClearFeature(HALT) to EP1 or EP2 
as we never are able to get to teh point of trying the write.

I will see if I need to MFC somethign in usb.c or usbdi.c or ugen.c
to do the endpoint clear as needed.



>
>older linux never sends the ClearFeature(Halt) packets on pipe open,
>so that matches what I'm seeing as well.
>
>: libusb does, times out and doesn the ClearFeature(Halt)
>: which apparently fixes everything. and then continues on its merry way.
>:
>: as ai said.. the device seems broken..
>
>Yes.  And in a different way than my device is broken :-)
>

not working on a check scanner are you?
 :-)

>  
>