Bulk transaction fails on some devices.

[Jonatan44]

Hi,
I've developed a EHCI driver working with full-speed devices.
Bulk transactions work for some devices, but for other the transactions fails (QTD status is 0x42).
it's impotent to note that the configuration process is positive for all devices, means get device descriptor, get configuration, etc, are working well.
all the devices are connected through usb 2.0 hub.

my usb tracer shown that a turn-around error occurred, I've checked the specification for this kind of issue and understood that it's happening because the delay between every package the HC submit to the device is the small.
I've tried to change the micro-frame rate (by default it's set to 8 micro-frame) but with no success.
could it be related to the fact that I'm working with a usb 2.0 hub?

Thanks,
Jonatan.

[Jan Axelson]

The hub adds the complication that the host must use split transactions to access the device so you might look at where the error is occurring in relation to that.

Jan

[Jonatan44]

Hi Jan,
my driver does uses split transactions, as i noted it is working for some devices (from the same class, speed, etc..)
the turnaround error occurs on the first bulk transaction, do you have any hint about what parameters do i need to change in my driver? do you think it's related to the TT buffer?

thanks!

[Jan Axelson]

7.1.18.2 in the USB spec defines inter-packet delays and turnaround times. The minimum high-speed turnaround time is 8 bit widths. Are you sure that is the problem? Which transaction (Start Split, Complete Split) does the error occur in?

Jan

[Jonatan44]

Hi Jan
There is only one transaction (Start Split) for now.
as i sad he transaction works for some devices (from the same manufacture)  but for others it just doesn't work.
my USB Tracer shows that there is a turn-around problem for the transaction, I did try to program FLADJ register to every combination but it's seems that it don't solve the problem.
im pretty sure it's really a turn-around problem, i'm just not sure were is the next place to try fixing the problem.

hope you could help me.
Jonatan.

[Jan Axelson]

>my usb tracer shown that a turn-around error occurred, I've checked the specification for this kind of issue and understood that it's happening because the delay between every package the HC submit to the device is the small.

The USB spec defines turnaround time as the delay when switching directions, for example, between token and data IN packets or between data OUT and handshake packets, not between packets in the same direction.

I would look for timing data that verifies the problem. If your turnaround time is 8 bit widths or more, the problem is elsewhere.

Jan

[Jonatan44]

There shouldn't be more then one packet submitted to the issued bulk endpoint, so from the driver point of view, there should not be and turnaround problems.
I just though on the next scenario:
as I mention before, some of the devices DO works for my EHCI driver, but some (from a different manufacture) aren't, BUT all of them do work with UHCI driver, which works with periodic scheduling system,
in my EHCI driver works with asynchronous scheduler, so could it be that some devices support only periodic scheduling while others support both async and periodic?

many thanks.

[Jan Axelson]

The biggest difference is UHCI doesn't use split transactions.

Every full-speed device should work with UHCI, OHCI, and EHCI + hub.

What host hardware does your driver run on?

Attach one of the problem devices via a hub to a Windows or other PC with an EHCI driver and watch the host traffic with an analyzer. Compare to your driver.

Every transaction has multiple packets: token plus data and/or status. The only transactions without a turnaround are isochronous OUT. But again, without timing data, it's hard to say turnaround is the problem.

Jan

[Jonatan44]

So your saying that the full speed device itself doesn't care if the scheduler uses periodic or async method?

my tracer pointed already on the problem (turnaround), should I need to have and doubts about his accuracy on this one? and if so, shouldn't those turnaround problems need
to disappear by programming the FLADJ register?

thanks,
jontan.

[Jan Axelson]

The host needs to comply with the USB spec. Different host controllers use different methods to do so.

I don't know the answer to your question about the FLADJ register.

Jan