USBD_STATUS_XACT_ERROR on USB isochronous IN transfers

NTDEV
1

I’m having trouble getting isochronouse transfers to work properly. I am
working with the Cypress CY7C68013 EZ-USB development kit. I’ve used both
the sample driver that comes with the development kit, as well as one that
is very close to the isousb sample driver in the Microsoft DDK, and am
seeing the same results.

I should also mention that the system I’m using is running XP Professional
with SP1, 2.8GHz P4 with 512 MB of RAM.

When an isochronous transfer completes, I’m getting back a C0000011
(USBD_STATUS_XACT_ERROR) in the USBD_ISO_PACKET_DESCRIPTOR Status field for
each packet, and the Length field of the same structure is 0.
Interestingly, even though the Status field has the error and the Length
field is zero, it does look like the data was returned correctly in the
transfer buffer.

Per section 4.15.1.1 of the EHCI spec, this error means the host controller
has set the “Transaction Error (XactErr)” bit in the transfer descriptor’s
status field. The EHCI spec indicates that this bit is set when it
encounters a CRC error, a timeout, an invalid PID, babble, or a buffer error
(under/overrun).

Has anyone seen this error, that could suggest a solution, or how to go
about troubleshooting this? The fact that the driver that Cyress shipped
with the device, as well as my driver based off the Microsoft DDK sample
driver both are showing the same results makes me think this may be some
sort of configuration problem, rather than a problem in the driver…

2

Do you have a USB protocol analyzer available? That might tell you what
went on the physical bus that might have caused the controller to raise
the XACT error.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Helmers
Sent: Monday, April 18, 2005 12:42 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] USBD_STATUS_XACT_ERROR on USB isochronous IN transfers

I’m having trouble getting isochronouse transfers to work properly. I
am
working with the Cypress CY7C68013 EZ-USB development kit. I’ve used
both
the sample driver that comes with the development kit, as well as one
that
is very close to the isousb sample driver in the Microsoft DDK, and am
seeing the same results.

I should also mention that the system I’m using is running XP
Professional
with SP1, 2.8GHz P4 with 512 MB of RAM.

When an isochronous transfer completes, I’m getting back a C0000011
(USBD_STATUS_XACT_ERROR) in the USBD_ISO_PACKET_DESCRIPTOR Status field
for
each packet, and the Length field of the same structure is 0.
Interestingly, even though the Status field has the error and the Length
field is zero, it does look like the data was returned correctly in the
transfer buffer.

Per section 4.15.1.1 of the EHCI spec, this error means the host
controller
has set the “Transaction Error (XactErr)” bit in the transfer
descriptor’s
status field. The EHCI spec indicates that this bit is set when it
encounters a CRC error, a timeout, an invalid PID, babble, or a buffer
error
(under/overrun).

Has anyone seen this error, that could suggest a solution, or how to go
about troubleshooting this? The fact that the driver that Cyress
shipped
with the device, as well as my driver based off the Microsoft DDK sample
driver both are showing the same results makes me think this may be some
sort of configuration problem, rather than a problem in the driver…

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@nvidia.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Unfortunately I don’t have access to a protocol analyzer. My company is
looking into getting one, but they are dragging their feet a little bit.
I’m hoping there is something I can troubleshoot without needing an
analyzer.

“Mark Overby” wrote in message news:xxxxx@ntdev…
Do you have a USB protocol analyzer available? That might tell you what
went on the physical bus that might have caused the controller to raise
the XACT error.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Helmers
Sent: Monday, April 18, 2005 12:42 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] USBD_STATUS_XACT_ERROR on USB isochronous IN transfers

I’m having trouble getting isochronouse transfers to work properly. I
am
working with the Cypress CY7C68013 EZ-USB development kit. I’ve used
both
the sample driver that comes with the development kit, as well as one
that
is very close to the isousb sample driver in the Microsoft DDK, and am
seeing the same results.

I should also mention that the system I’m using is running XP
Professional
with SP1, 2.8GHz P4 with 512 MB of RAM.

When an isochronous transfer completes, I’m getting back a C0000011
(USBD_STATUS_XACT_ERROR) in the USBD_ISO_PACKET_DESCRIPTOR Status field
for
each packet, and the Length field of the same structure is 0.
Interestingly, even though the Status field has the error and the Length
field is zero, it does look like the data was returned correctly in the
transfer buffer.

Per section 4.15.1.1 of the EHCI spec, this error means the host
controller
has set the “Transaction Error (XactErr)” bit in the transfer
descriptor’s
status field. The EHCI spec indicates that this bit is set when it
encounters a CRC error, a timeout, an invalid PID, babble, or a buffer
error
(under/overrun).

Has anyone seen this error, that could suggest a solution, or how to go
about troubleshooting this? The fact that the driver that Cyress
shipped
with the device, as well as my driver based off the Microsoft DDK sample
driver both are showing the same results makes me think this may be some
sort of configuration problem, rather than a problem in the driver…

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@nvidia.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Jeff Helmers wrote:

Has anyone seen this error, that could suggest a solution, or how to go
about troubleshooting this? The fact that the driver that Cyress shipped
with the device, as well as my driver based off the Microsoft DDK sample
driver both are showing the same results makes me think this may be some
sort of configuration problem, rather than a problem in the driver…

Also possibilities: a problem with your USB host controller hardware
(can’t keep up with the flow of data) or your firmware (can’t supply the
data fast enough or is sending invalid length packets).

I don’t know how/where you’re generating your data, but I assume you
heeded the Cypress warnings about not trying to do much (read: “just
about any”) processing in your firmware for each iso data packet.

MarkOv’s recommendation to throw a USB analyzer on the bus is right
guidance. That’s what we had to do to diagnose a similar problem.

FWIW, there are now a few good alternatives to the (very expensive, but
excellent) CATC. For example, we use an Ellisys Explorer 200 and
absolutely LOVE it.

Peter
OSR

5

Thanks for the info Peter, I’ll push to get the protocol analyzer in here
quicker. We had been looking at the CATC, but were a little hesitant about
the price…I’ll take a closer look at the Ellisys.

Right now I’m not doing any processing on the packets that come back, so
that shouldn’t be causing the problem. If I get the analyzer, and the data
coming across the USB bus looks good, how would I go about troubleshooting
the host controller hardware? I’d assume it’s pretty rare that a problem to
be in that area, is that correct?

6

Jeff Helmers wrote:

Right now I’m not doing any processing on the packets that come back, so
that shouldn’t be causing the problem.

He’s not talking about processing the packets that come back, he’s
talking about doing processing in the 8051 firmware. How much
customizing have you done in the firmware? Have you adjusted the
desciptors to enable an isochronous pipe? Are you checking for isoch
reads in the main loop? Where are you getting the data to send back?

–

7

Jeff,

If you can get hold of it, Compuware’s DriverWorks has a set of
sample drivers for the EZ-USB kit, including a driver that if my
memory doesn’t fail me is called “ISOCH”. I played with it about
one year ago but I don’t remember having any trouble with the
hardware; yet I did not use the sample driver that comes with
the kit. I also remember having to run their application, which
had a pile and a half of settings and controls that I had to
flip before I could convince the EZ-USB to do isoch, so, there’s
a remote possibility that you may have skipped something
important in the setup sequence. But then, it’s been a while and
I don’t quite remember it anymore, so, take my word with a pinch
of salt!

Alberto.

----- Original Message -----
From: “Jeff Helmers”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”

Sent: Monday, April 18, 2005 3:42 PM
Subject: [ntdev] USBD_STATUS_XACT_ERROR on USB isochronous IN
transfers

> I’m having trouble getting isochronouse transfers to work
> properly. I am
> working with the Cypress CY7C68013 EZ-USB development kit.
> I’ve used both
> the sample driver that comes with the development kit, as well
> as one that
> is very close to the isousb sample driver in the Microsoft
> DDK, and am
> seeing the same results.
>
> I should also mention that the system I’m using is running XP
> Professional
> with SP1, 2.8GHz P4 with 512 MB of RAM.
>
> When an isochronous transfer completes, I’m getting back a
> C0000011
> (USBD_STATUS_XACT_ERROR) in the USBD_ISO_PACKET_DESCRIPTOR
> Status field for
> each packet, and the Length field of the same structure is 0.
> Interestingly, even though the Status field has the error and
> the Length
> field is zero, it does look like the data was returned
> correctly in the
> transfer buffer.
>
> Per section 4.15.1.1 of the EHCI spec, this error means the
> host controller
> has set the “Transaction Error (XactErr)” bit in the transfer
> descriptor’s
> status field. The EHCI spec indicates that this bit is set
> when it
> encounters a CRC error, a timeout, an invalid PID, babble, or
> a buffer error
> (under/overrun).
>
> Has anyone seen this error, that could suggest a solution, or
> how to go
> about troubleshooting this? The fact that the driver that
> Cyress shipped
> with the device, as well as my driver based off the Microsoft
> DDK sample
> driver both are showing the same results makes me think this
> may be some
> sort of configuration problem, rather than a problem in the
> driver…
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

8

I would agree with peter on this one about the possibility of USB host
controller hardware issues. Are you using an EHCI PCI add-in card? I
have found that some of these controllers have trouble when dealing with
a lot of data where their buffers overflow, or they can’t get it across
the PCI bus in time. My guess is that you are doing a pretty high
bandwidth Isoch stream.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Viscarola
(OSR)
Sent: Monday, April 18, 2005 1:22 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] USBD_STATUS_XACT_ERROR on USB isochronous IN
transfers

Jeff Helmers wrote:

Has anyone seen this error, that could suggest a solution, or how to
go
about troubleshooting this? The fact that the driver that Cyress
shipped
with the device, as well as my driver based off the Microsoft DDK
sample
driver both are showing the same results makes me think this may be
some
sort of configuration problem, rather than a problem in the driver…

Also possibilities: a problem with your USB host controller hardware
(can’t keep up with the flow of data) or your firmware (can’t supply the

data fast enough or is sending invalid length packets).

I don’t know how/where you’re generating your data, but I assume you
heeded the Cypress warnings about not trying to do much (read: “just
about any”) processing in your firmware for each iso data packet.

MarkOv’s recommendation to throw a USB analyzer on the bus is right
guidance. That’s what we had to do to diagnose a similar problem.

FWIW, there are now a few good alternatives to the (very expensive, but
excellent) CATC. For example, we use an Ellisys Explorer 200 and
absolutely LOVE it.

Peter
OSR

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

Randy Aull wrote:

I would agree with peter on this one about the possibility of USB host
controller hardware issues. Are you using an EHCI PCI add-in card? I
have found that some of these controllers have trouble when dealing with
a lot of data where their buffers overflow, or they can’t get it across
the PCI bus in time. My guess is that you are doing a pretty high
bandwidth Isoch stream.

He’s using a Cypress EZ-USB. It’s USB 1.1. An EHCI controller can
handle those at full throttle without even breaking a sweat.

However, it’s not entirely clear to me that he has an EHCI controller.

–

10

Hello,

The CY7C68013 is the EZ-USB FX2 (USB 2.0). Cypress’ newer part is the new
low-power part (CY7C68013A) called EZ-USB FX2LP. In addition to being lower
power, it has twice as much code/data RAM. It also has a fix in place for
PID sequencing errors that can occur with the older FX2 version.

My advice is to read the CyStream white paper on the Cypress web site. It
comes with example firmware and a CyStream driver that is useful for
debugging ISO mode. On the Cypress web site, search for “Cystream.”

Pay particular attention to the number of transfers per microframe, and Data
PID sequencing. If you are using the FX2 part, there is no automatic
zero-length packet commit if your firmware/hardware does not supply ISO
packets fast enough. This will cause a PID sequencing error. The FX2LP
(CY7C68013A) has provision for committing zero-length packets automatically
on underrun.

While the Cystream driver is not very useful for doing real work, it is a
useful debugging tool.

Sincerely,

Howard M. Harte

========================

Harte Technologies, LLC.

(925) 551-0120 (voice)

(925) 551-0125 (fax)

http://www.hartetechnologies.com/

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Randy Aull wrote:
>
>>I would agree with peter on this one about the possibility of USB host
>>controller hardware issues. Are you using an EHCI PCI add-in card? I
>>have found that some of these controllers have trouble when dealing with
>>a lot of data where their buffers overflow, or they can’t get it across
>>the PCI bus in time. My guess is that you are doing a pretty high
>>bandwidth Isoch stream.
>>
>
> He’s using a Cypress EZ-USB. It’s USB 1.1. An EHCI controller can handle
> those at full throttle without even breaking a sweat.
>
> However, it’s not entirely clear to me that he has an EHCI controller.
>
> –
> - Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

11

We are using an EHCI controller. It’s not an add-on PCI card, it’s one that
came with the computer…if I’m reading the info in the device manager
correctly, it’s an Intel 82801DB/DBM USB 2.0 enhanced host controller.

I will eventually need to do fairly high bandwidth, but in trying to get
this working, I’ve scaled it down to where I’m doing very small
transfers…I’m only reading 8 bytes at a time, using 1 byte packets. ( I’ve
tried experimenting with different packet and buffer sizes, but the results
are the same) The error shows up in the very first isochronous transfer
that happens, so I don’t think I’m stressing out the host controller at all,
but I still need to get a bus analyzer to see exactly what is coming
across…

We have ordered some of the CY7C68013A parts from Cypress that fix the PID
sequencing errors, but again since I’m getting this error on the first
isochronous transfer, I don’t think that is what is causing the problem
either.

Thanks everyone for all the help and suggestions!
Jeff

12

Hello Jeff,

I have seen this problem before when using the FX2 part. My
suggestion of reading the Cystream app note is what eventually lead me to
fix the problem. I can’t remember exactly what the problem was, but it was
related to PID sequencing, the number of ISO IN packets per frame, and the
packet length.

Installing the CyStream driver and running the CyStream firmware and
application allows you to verify the data rate that you want to do before
you spend a lot of time writing your own firmware/driver. I highly
reccommend it. The CyStream firmware uses firmware-generated test pattern
packets. Only the packet headers change though, so firmware can source
these packets very rapidly. If nothing else, CyStream is a baseline that
will confirm that your host controller, PC, hardware, etc, are working
properly.

Howard M. Harte

========================
Harte Technologies, LLC.
(925) 551-0120 (voice)
(925) 551-0125 (fax)
http://www.hartetechnologies.com/

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Helmers
Sent: Tuesday, April 19, 2005 6:30 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] USBD_STATUS_XACT_ERROR on USB isochronous IN transfers

We are using an EHCI controller. It’s not an add-on PCI card, it’s one that
came with the computer…if I’m reading the info in the device manager
correctly, it’s an Intel 82801DB/DBM USB 2.0 enhanced host controller.

I will eventually need to do fairly high bandwidth, but in trying to get
this working, I’ve scaled it down to where I’m doing very small
transfers…I’m only reading 8 bytes at a time, using 1 byte packets. ( I’ve
tried experimenting with different packet and buffer sizes, but the results
are the same) The error shows up in the very first isochronous transfer
that happens, so I don’t think I’m stressing out the host controller at all,
but I still need to get a bus analyzer to see exactly what is coming
across…

We have ordered some of the CY7C68013A parts from Cypress that fix the PID
sequencing errors, but again since I’m getting this error on the first
isochronous transfer, I don’t think that is what is causing the problem
either.

Thanks everyone for all the help and suggestions!
Jeff

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@hartetec.com To unsubscribe
send a blank email to xxxxx@lists.osr.com