Cause of USBD_STATUS_ISO_NOT_ACCESSED_BY_HW

NTDEV
1

Hello all,

I am doing high speed isochronous streaming, 1 URB per frame=millisec on XP sp2. The USB endpoint descriptor has a bInterval of 1, so it polls every microframe = 1/8 millisec. The problem I’m having is that some microframes I attempt to read, return with a status of:

USBD_STATUS_ISO_NOT_ACCESSED_BY_HW – “The host controller did not access the transfer descriptor (TD) that is associated with this packet. The USB stack reports this error in the packet status field of an isochronous transfer packet.” (MSDN)

… and thus these microframes fail to read, even when the overall URB reports success. I know that isochronous transfer does not guarantee delivery, but I do hope to learn whether there are any general, preventable causes of this error.

I can reproduce the problem by performing disk access concurrently with streaming. This is on an older desktop machine – 1 GHz single core Athlon, 256 MB RAM.

What’s odd to me is that some of the microframes in the URB succeed – and furthermore, the good and bad microframes are intermingled. For example, within one frame I had microframe indexes 0, 2, 5, and 7 that failed with the above error, while indexes 1, 3, 4, and 6 were successfully read. That intuitively suggests to me that it’s not a scheduling failure in terms of my submitting the request too late, or else I would expect contiguous microframes at the beginning to fail.

What has been your experience with this error? What causes the host controller to “not access the TD” for these random(?), individual microframes?

Regards,
Andrew

2

xxxxx@yahoo.com wrote:

I am doing high speed isochronous streaming, 1 URB per frame=millisec on XP sp2. The USB endpoint descriptor has a bInterval of 1, so it polls every microframe = 1/8 millisec. The problem I’m having is that some microframes I attempt to read, return with a status of:

USBD_STATUS_ISO_NOT_ACCESSED_BY_HW – “The host controller did not access the transfer descriptor (TD) that is associated with this packet. The USB stack reports this error in the packet status field of an isochronous transfer packet.” (MSDN)

… and thus these microframes fail to read, even when the overall URB reports success. I know that isochronous transfer does not guarantee delivery, but I do hope to learn whether there are any general, preventable causes of this error.

I can reproduce the problem by performing disk access concurrently with streaming. This is on an older desktop machine – 1 GHz single core Athlon, 256 MB RAM.

What’s odd to me is that some of the microframes in the URB succeed – and furthermore, the good and bad microframes are intermingled. For example, within one frame I had microframe indexes 0, 2, 5, and 7 that failed with the above error, while indexes 1, 3, 4, and 6 were successfully read. That intuitively suggests to me that it’s not a scheduling failure in terms of my submitting the request too late, or else I would expect contiguous microframes at the beginning to fail.

What has been your experience with this error? What causes the host controller to “not access the TD” for these random(?), individual microframes?

This tends to be caused by some kind of hardware problem. Some USB host
controllers just suck. They’re known to be flaky, and isochronous
transfers are the ones that trigger the flakiness. Even Intel had an
errata on one of their early host controllers about this very issue.
There was no solution, short of using a replacement host controller. Do
you see this on any other machine? What host controller is in your
older machine?

One of my clients was seeing this when he had a 32-bit PCI card plugged
into a 64-bit PCI slot, suggesting perhaps that excessive PCI bus errors
were causing the host controller to miss its DMA timing.

Are you 100% certain that your device has data to send at every
microframe? Remember that, with USB, each packet corresponds exactly to
one interval, whether or not your device has anything to send. If your
device skips a microframe, you’ll get an error for that packet entry,
even though the URB as a whole succeeds.

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

3

>> This tends to be caused by some kind of hardware problem. Some USB host controllers just suck.

> Do you see this on any other machine? What host controller is in your older machine?

I was only seeing it on the old machine. Based on your suggestion, I swapped out the controller for a different one (Via VT6212L –> NEC D720101GJ), and the problem entirely went away. I’m going to blame it on the host hardware.

Thanks for sharing your expertise on this, Tim.