Isochronous transfers using USBSamp driver

NTDEV
1

I’m currently trying to get isochronous transfers working using the USBSamp driver with my device.

The endpoint descriptor is (using USBview from the WinDDK)

Endpoint Descriptor:
bEndpointAddress: 0x01 OUT
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x01

Endpoint Descriptor:
bEndpointAddress: 0x81 IN
Transfer Type: Isochronous
wMaxPacketSize: 0x1400 (5120)
bInterval: 0x01

Configuration Descriptor:
wTotalLength: 0x0020
bNumInterfaces: 0x01
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0xC0 (Bus Powered Self Powered )
MaxPower: 0xFA (500 mA)

Interface Descriptor:
bInterfaceNumber: 0x00
bAlternateSetting: 0x00
bNumEndpoints: 0x02
bInterfaceClass: 0xFF
bInterfaceSubClass: 0x00
bInterfaceProtocol: 0x00
iInterface: 0x00

Endpoint Descriptor:
bEndpointAddress: 0x01 OUT
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x01

Endpoint Descriptor:
bEndpointAddress: 0x81 IN
Transfer Type: Isochronous
wMaxPacketSize: 0x1400 (5120)
bInterval: 0x01

So I’m expecting to be able to send 3 x 1024 byte packets for every micro frame.

But I only get a single IN sent to the device (which the device correctly responds with a 1024 byte packet) per microframe.

I’ve got a LeCroy analyzer hooked up so know its definitely sending the one packet but the host isn’t sending the extra IN’s

Does anyone know whether the USBSamp driver has been used to send high bandwidth isochronous transfers?

For extra information I know everyone is going to ask… I’ve asked for a 24576 byte transfer (i.e. 8 microframes x 3 packets x 1024 bytes) and the offsets in the URB are set up correcly with packet sizes of 3072 bytes. Maximum size I get back is 0x400 bytes

Thanks

Gordon Hollingworth

2

Take a look at your bus trace. Is the single packet from your device in each microframe a DATA0, a DATA1, or a DATA2 packet?

-Glen

3

They always seem to be DATA0

4

Ah,

OK I just found the reference in the USB2.0 spec, it should be DATA2 first then DATA1 and finally DATA0

Cheers

Gordon

5

Yes, if the first packet from the device is a DATA0 the host would stop at that point and assume that the device has no additional data to return in that microframe.

There are most likely some device specific endpoint configuration bits in your device you need to program differently to tell the device how many packets it should send per microframe.

For reference for anyone else reading this thread here is the relevant section of the USB 2.0 specification:

5.9.2 High Bandwidth Isochronous Endpoints

Data PID sequencing for a high-speed, high bandwidth isochronous IN
endpoint uses a repeating sequence of DATA2, DATA1, DATA0 PIDs for the
data packet of each transaction in a microframe. If there is only a
single transaction in the microframe, only a DATA0 data packet PID is
used. If there are two transactions per microframe, DATA1 is used for
the first transaction data packet and DATA0 is used for the second
transaction data packet. If there are three transactions per
microframe, DATA2 is used for the first transaction data packet, DATA1
is used for the second, and DATA0 is used for the third. In all cases,
the data PID sequence starts over again the next microframe. Figure
5-11 shows the order of data packet PIDs that are used in subsequent
transactions within a microframe for high-bandwidth isochronous IN
endpoints.

6

xxxxx@broadcom.com wrote:

I’m currently trying to get isochronous transfers working using the USBSamp driver with my device.

The endpoint descriptor is (using USBview from the WinDDK)
…
Endpoint Descriptor:
bEndpointAddress: 0x01 OUT
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x01

Endpoint Descriptor:
bEndpointAddress: 0x81 IN
Transfer Type: Isochronous
wMaxPacketSize: 0x1400 (5120)
bInterval: 0x01
…
So I’m expecting to be able to send 3 x 1024 byte packets for every micro frame.

Yep, that’s what it looks like to me. Your descriptors are not proper,
however. You should never have an isochronous endpoint that reserves
bandwidth as part of alternate setting 0. Alternate setting 0 should
have no isochronous endpoints, then put your real endpoint in alternate
setting 1. Otherwise, your device will fail to enumerate if there is
not enough available bandwidth.

But I only get a single IN sent to the device (which the device correctly responds with a 1024 byte packet) per microframe.
…
For extra information I know everyone is going to ask… I’ve asked for a 24576 byte transfer (i.e. 8 microframes x 3 packets x 1024 bytes) and the offsets in the URB are set up correcly with packet sizes of 3072 bytes. Maximum size I get back is 0x400 bytes

The terminology is important here. It’s not 3 x 1024-byte packets. It
is a 3072-byte packet that is transferred in 3 transactions. You need
to set up the URB with 8 packets of 3072 bytes. From your last
sentence, I suspect that’s what you have done, but I’m not exactly sure.

This has implications. If the first transaction is less than 1024
bytes, the whole packet is considered to be complete, so you will not
get another IN token until the next microframe.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

REALLY “not proper”?? Or do you mean “setup in a way that might lead to behavior you don’t anticipate”??

I’m soooooo not an expert on isochronous, so you can feel free to tell me I don’t know what I’m talking about… but I don’t RECALL anything actually WRONG (that is, contrary to the USB spec or Windows architecture) with having ISO endpoints in Alt 0.

I’m not trying to split hairs here… there’s an important difference between a spec or architecture violation (“not proper”) and some behavior that’s less than desirable.

Peter
OSR

8

xxxxx@osr.com wrote:

REALLY “not proper”?? Or do you mean “setup in a way that might lead to behavior you don’t anticipate”??

I’m soooooo not an expert on isochronous, so you can feel free to tell me I don’t know what I’m talking about… but I don’t RECALL anything actually WRONG (that is, contrary to the USB spec or Windows architecture) with having ISO endpoints in Alt 0.

I’m not trying to split hairs here… there’s an important difference between a spec or architecture violation (“not proper”) and some behavior that’s less than desirable.

It is an excellent question, and I have never shied away from splitting
hairs. Section 5.6.3 of the USB 2.0 specification says, and I quote:

“All device default interface settings must not include any isochronous
endpoints with non-zero data payload sizes (specified via
/wMaxPacketSize/ in the endpoint descriptor).”

So, his descriptors actually violate the spec. Now, both Windows and
Linux happen to handle this case, although grudgingly. If your device
exceeds the available bandwidth, Windows will fail the SET_CONFIGURATION
request.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

So, yes… your initial post was spot-on. His configuration is, indeed, “not proper” – Both Windows and Linux might be TOLERANT of this impropriety, but it is not proper just the same.

Thank you, Tim. Hmmm… I learned something today.

Peter
OSR

10

Thanks everyone, just trying to put it all right…

Can anyone tell me what the best way is to re-install a driver after a quick build? In general I’ve normally just unplugged my device and overwritten the .sys file… But it doesn’t seem to work anymore I’m assuming windows is caching the driver (or its still loaded)

11

>I’m assuming windows is caching the driver (or its still loaded)

It is not cached, just check for it to be really unloaded on device re-plug or DevMgmt’s disable.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

12

Do an update from Device Manager, then use .kdfiles in WinDbg to reload new
images as you build them.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@broadcom.com
Sent: Thursday, August 12, 2010 5:07 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Isochronous transfers using USBSamp driver

Thanks everyone, just trying to put it all right…

Can anyone tell me what the best way is to re-install a driver after a quick
build? In general I’ve normally just unplugged my device and overwritten
the .sys file… But it doesn’t seem to work anymore I’m assuming windows
is caching the driver (or its still loaded)

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

13

What’s your target OS?

Before you overwrite, does windbg indicate that your driver is loaded or
unloaded?

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Thursday, August 12, 2010 10:45 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Isochronous transfers using USBSamp driver

Do an update from Device Manager, then use .kdfiles in WinDbg to reload new
images as you build them.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@broadcom.com
Sent: Thursday, August 12, 2010 5:07 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Isochronous transfers using USBSamp driver

Thanks everyone, just trying to put it all right…

Can anyone tell me what the best way is to re-install a driver after a quick
build? In general I’ve normally just unplugged my device and overwritten
the .sys file… But it doesn’t seem to work anymore I’m assuming windows
is caching the driver (or its still loaded)

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

14

xxxxx@broadcom.com wrote:

Can anyone tell me what the best way is to re-install a driver after a quick build? In general I’ve normally just unplugged my device and overwritten the .sys file… But it doesn’t seem to work anymore I’m assuming windows is caching the driver (or its still loaded)

I just copy the .sys file into place and do a “devcon restart”.

However, if you have an application that is keeping a handle open, or if
you have two devices plugged in, that won’t work. In the two device
case, you can do “devcon disable” twice, then “devcon enable” twice. If
you have a dangling application handle, you have to kill the
application, or restart.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.