-- Does the host issue IN token with sufficient frequency?
Well I am just requesting a single read of 240*512. When I use
smaller buffers and overlap the transfers, I am able to get more
data from the device than if I use a single read of 240*512..
You are confused. The IOUSBFamily queues your request to the USB
controller. The controller (hardware) issues the IN tokens. That is
what the device is actually responding to.
You MUST use a bus analyzer to answer this question. Additional
request should have no effect other than they may continue following
a short packet that causes the first request to complete. Does the
device send short packets? You need a bus analyzer to answer this
question.
>-- Does the device respond with data, or is it sending NYET tokens?
It does until the device detects a buffer over run which means that
the data wasn't pulled out fast enough.Then the device will
terminate the transaction.
You need to get a trace from a USB bus analyzer. A device cannot
"terminate the transaction" it can only return data (either 512 bytes
or something less -- if it is less than 512 bytes then we will
complete your request due to the short packet), or a STALL token.
>- Are the packets received correctly (host sends ACK), or retried?
-- Does the data toggle seem to be working correctly? (DATA0/DATA1) packets
This device works fine on different platform, so I am assuming the
data toggle is working correctly....
There are host side data toggle issues as well. If you reset
endpoints, etc that can cause the data toggle to be reset to 0. A
bus analyzer will help you determine if this is happening.
If you IOUSBPipeRead() function is timing out, that indicates your
device isn't sending the
data... Perhaps you have the timeout value set to small value, and
the device isn't ready to
start sending data yet...
The device sends the first 2 packets,but after that it detects that
the data wasn't pulled out fast enough (512 bytes in 256 us), it
terminates the transaction and stop sending data.
Since I set the IOUSBPipe->Read() function to time out after 5s of
no bus activity, and since the device stops sending data waiting for
a new request, the IOUSBPipeRead() function is timing out after 5 s.
So you are saying the device is NAKing forever. Send me a bus trace
showing that. That is not correct for a high-speed device.
> Or the device isn't handling PING correctly....
I am assuming that shouldn't be the problem since the device is
working on windows...
You will not be able to debug this problem without a bus analyzer.
Capture traces and you should be able to figure out what is going
wrong.
By the way -- are you sure your device is connected at high-speed.
If it was connected at full speed (like through a full-speed hub),
then your performance is more challenging :)
By the way, just because something "works on windows" doesn't mean
that it follows the spec -- Windows allows drivers to do things that
are non-spec compliant, and sometimes we find devices who's firmware
is coded to "what windows does" at enumeration time.
David Ferguson
USB Software Team
Apple Computer
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/usb/email@hidden
