Babble error detected

Hi,

Case 1 : I am using a USB 3.0 host controller driver on a USB 3.1 host controller hardware, Host controller driver is loading properly with out any issues. But when i connect USB 2.0 device, enumeration is failing because , GET_DEVICE_DESCRIPTOR (Configuration descriptor ) request fails with error BABBLE_ERROR.

Case 2 : When using a same USB 3.0 host controller driver on a USB 3.0 host controller hardware, and connecting USB 2.0 device works (enumerates) properly.

Brief analysis of issue : In both working(Case 2) and not working case (Case 1) same GET_DEVICE_DESCRIPTOR (Configuration descriptor ) request with same wlength is sent, but in case 1 BABBLE_ERROR is detected.

In xHCI specification Babble error is defined as below :
“When a device transmits more data on the USB than the host controller is expecting for a transaction, it is defined to be babbling. In general, this is called a Babble Error.”

what may be the cause of babble error?

You haven’t really given us much that we can use to diagnose your problem.

The usual cause of babble errors is an error in the device itself.

I don’t suppose you have a USB bus analyzer? Because (as I often say about any USB-related problem) using an actual hardware USB bus analyzer is the way to identify the problem you’re having.

Peter

Reddy wrote:

Case 1 : I am using a USB 3.0 host controller driver on a USB 3.1 host controller hardware, Host controller driver is loading properly with out any issues. But when i connect USB 2.0 device, enumeration is failing because , GET_DEVICE_DESCRIPTOR (Configuration descriptor ) request fails with error BABBLE_ERROR.

Case 2 : When using a same USB 3.0 host controller driver on a USB 3.0 host controller hardware, and connecting USB 2.0 device works (enumerates) properly.

Brief analysis of issue : In both working(Case 2) and not working case (Case 1) same GET_DEVICE_DESCRIPTOR (Configuration descriptor ) request with same wlength is sent, but in case 1 BABBLE_ERROR is detected.

In xHCI specification Babble error is defined as below :

“When a device transmits more data on the USB than the host controller is expecting for a transaction, it is defined to be babbling. In general, this is called a Babble Error.”

what may be the cause of babble error?

Exactly what the spec says.  USB frames are all scheduled in advance. 
Before the frame starts, the host controller chooses the transfers that
will be done during that 125us period, and lays them out in order, in
specific time slots.  The host controller knows exactly how long each
transfer will be, either from the endpoint descriptor or from the
driver’s transfer request.

Here’s one scenario.  The configuration descriptor is variable length. 
The usual way to handle that is for the host to send a read of the fixed
header (about 9 bytes), which contains the total length.  It then sends
another request to get the whole thing.  If your firmware always
responds by returning the entire descriptor, even when the host only
asked for 9 bytes, that would cause babble.  You need to check your
firmware.

Babble is a serious protocol violation.  If your request happened to
come at the end of the microframe so that your babble spilled beyond the
microframe boundary, that can actually cause the whole hub to shut down.

I would look for a some time-related bug in the device. Often a newer host will have quicker turnaround in the scheduling for 2.0 traffic, and it can expose bugs in a 2.0 device. It is extremely unlikely that the host hardware or driver are doing anything wrong, as Tim and Peter said.

Hi,

Thanks for you inputs.

Below is the lecroy USB analyzer analysis

After analyzing the lecroy logs i observed that when GET_DESCRIPTOR(Configuration type , size >= 64 (endpoint zero max packet size)) is sent to device, host controller send multiple IN tokens of each 64 bytes to read the configuration descriptor, for some in tokens device is returning Bad Turnaround /Timeout error.

After getting 3 or 4 Bad Turnaround /Timeout error, host is not sending another IN token to read the data from device. So the request fails and host controller returns babble error to the driver.

what may be the cause of Bad Turnaround /Timeout error?

Thanks

Reddy wrote:

After analyzing the lecroy logs i observed that when GET_DESCRIPTOR(Configuration type , size >= 64 (endpoint zero max packet size)) is sent to device, host controller send multiple IN tokens of each 64 bytes to read the configuration descriptor, for some in tokens device is returning Bad Turnaround /Timeout error.

After getting 3 or 4 Turnaround /Timeout error, host is not sending another IN token to read the data from device. So the request fails and host controller returns babble error to the driver.

I’m interested to know more about your device.  Are you using an
off-the-shelf USB chip, or is this some custom IP?

@Tim_Roberts said:
Reddy wrote:

After analyzing the lecroy logs i observed that when GET_DESCRIPTOR(Configuration type , size >= 64 (endpoint zero max packet size)) is sent to device, host controller send multiple IN tokens of each 64 bytes to read the configuration descriptor, for some in tokens device is returning Bad Turnaround /Timeout error.

After getting 3 or 4 Turnaround /Timeout error, host is not sending another IN token to read the data from device. So the request fails and host controller returns babble error to the driver.

I’m interested to know more about your device. Are you using an
off-the-shelf USB chip, or is this some custom IP?

Hi,

The device i am using is normal USB 2.0 webcam device.

When host driver sends GET_DESCRIPTOR(Configuration type, size = 2349(USB 2.0 webcam device complete configuration descriptor length)), hardware is returning babble error.

  1. GET_DESCRIPTOR(Configuration type, size = 2349(USB 2.0 webcam device complete configuration descriptor length)) is sent to endpoint 0, control endpoint.
  2. Endpoint 0 max_packet_size = 64 bytes.

Reddy wrote:

> I’m interested to know more about your device.  Are you using an
> off-the-shelf USB chip, or is this some custom IP?
The device i am using is normal USB 2.0 webcam device.

That’s not a helpful answer.  Everyone thinks their USB device is
“normal”, but very few are.  What is the USB chip?  Is it an
off-the-shelf USB interface chip, or is it one you developed?

When host driver sends GET_DESCRIPTOR(Configuration type, size = 2349(USB 2.0 webcam device complete configuration descriptor length)), hardware is returning babble error.

That’s a very large descriptor, but still within the spec.  I believe
you said that the descriptor does get partially transferred.  Does it
get through the same amount every time? When you get the “bad turnaround
/ timeout” errors, can you tell which one it is?  That is, is there a
long time between the IN token and your response?  Does the Lecroy
report any DATA0/DATA1 errors?

@Tim_Roberts said:
Reddy wrote:

I’m interested to know more about your device. Are you using an
off-the-shelf USB chip, or is this some custom IP?
The device i am using is normal USB 2.0 webcam device.

That’s not a helpful answer. Everyone thinks their USB device is
“normal”, but very few are. What is the USB chip? Is it an
off-the-shelf USB interface chip, or is it one you developed?

It is an off-the-shelf USB interface chip.

When host driver sends GET_DESCRIPTOR(Configuration type, size = 2349(USB 2.0 webcam device complete configuration descriptor length)), hardware is returning babble error.

That’s a very large descriptor, but still within the spec. I believe
you said that the descriptor does get partially transferred. Does it
get through the same amount every time? When you get the “bad turnaround
/ timeout” errors, can you tell which one it is? That is, is there a
long time between the IN token and your response? Does the Lecroy
report any DATA0/DATA1 errors?

When there is no “bad turnaround / timeout” error, time taken for IN token to get response is <2.5 micro seconds, and in error case it is more then 4.3 micro seconds.
There are no DATA0/DATA1 errors seen in lecroy logs.

Note : If Microsoft inbuilt host controller driver is installed on same host controller (Windows 10 OS), camera device is enumerated properly.
My host controller driver is installed on same host controller for Windows 7 OS (as Microsoft doesn’t provide driver for windows 7), camera enumeration fails as mentioned earlier.

Reddy wrote:

It is an off-the-shelf USB interface chip.

WHICH off-the-shelf USB interface chip?

When there is no “bad turnaround / timeout” error, time taken for IN
token to get response is <2.5 micro seconds, and in error case it is
more then 4.3 micro seconds.

I believe that’s in the spec, 7.1.19.2.  You get 816 bit times to
respond, which would be about 2.1us.

Note : If Microsoft inbuilt driver is installed on same host controller (Windows 10 OS), camera device is enumerated properly.

My driver is installed on same host controller for Windows 7 OS (as Microsoft doesn’t provide driver for windows 7), camera enumeration fails as mentioned earlier.

You never thought to mention this hugely important fact before? So, you
are on a USB 3.0 host controller, and the failure only happens with the
vendor’s XHCI driver?  Have you tried a machine with a different host
controller?  Some of the vendor-supplied USB 3.0 driver stacks were crap.

@Tim_Roberts said:
Reddy wrote:

It is an off-the-shelf USB interface chip.

WHICH off-the-shelf USB interface chip?

When there is no “bad turnaround / timeout” error, time taken for IN
token to get response is <2.5 micro seconds, and in error case it is
more then 4.3 micro seconds.

I believe that’s in the spec, 7.1.19.2. You get 816 bit times to
respond, which would be about 2.1us.

Note : If Microsoft inbuilt driver is installed on same host controller (Windows 10 OS), camera device is enumerated properly.

My driver is installed on same host controller for Windows 7 OS (as Microsoft doesn’t provide driver for windows 7), camera enumeration fails as mentioned earlier.

You never thought to mention this hugely important fact before? So, you
are on a USB 3.0 host controller, and the failure only happens with the
vendor’s XHCI driver? Have you tried a machine with a different host
controller? Some of the vendor-supplied USB 3.0 driver stacks were crap.

Hi,
find the below summary
Board 1 = xHCI 1.0 host controller which has USB 3.0 ports
Board 2 = xHCI 1.1 host controller which had USB 3.0 ports

  1. USB 2.0 Camera enumeration works fine on Board 1 with
    a. Windows 10 OS and Microsoft provided inbuilt host controller driver.
    b. Windows 7 OS and vendor’s host controller driver.
  2. USB 2.0 Camera enumeration work fine on Board 2 on Windows 10 OS and with Microsoft provided inbuilt
    host controller driver.
  3. USB 2.0 Camera enumeration fails on Board 2 on Windows 7 OS and with vendor’s host controller driver.( The issue which i am facing currently)

Note: Same vendor provided host controller driver is used on both Board 1 and Board 2.
Note : Same USB 2.0 Camera device is used on all boards.

Reddy wrote:

find the below summary

Board 1 = xHCI 1.0 host controller which has USB 3.0 ports
Board 2 = xHCI 1.1 host controller which had USB 3.0 ports

* USB 2.0 Camera enumeration works fine on Board 1 with
a. Windows 10 OS and Microsoft provided inbuilt host controller driver.
b. Windows 7 OS and vendor’s host controller driver.
* USB 2.0 Camera enumeration work fine on Board 2 on Windows 10 OS and with Microsoft provided inbuilt
host controller driver.
* USB 2.0 Camera enumeration fails on Board 2 on Windows 7 OS and with vendor’s host controller driver.( The issue which i am facing currently)

Note: Same vendor provided host controller driver is used on both Board 1 and Board 2.

What vendor is the XHCI host controller?  Are you sure you have the most
recent driver, and that it supports both models of the host controller? 
Have you tried other machines with different XHCI host controllers? 
Have you tried more than one instance of the second system?

Really, what you’re describing here is an XHCI host controller driver
bug.  Have you contacted the vendor to see if there is an errata list? 
They probably aren’t going to be interested in fixing a bug in a product
they no longer develop for a dead-end operating system.

@Tim_Roberts said:
Reddy wrote:

find the below summary

Board 1 = xHCI 1.0 host controller which has USB 3.0 ports
Board 2 = xHCI 1.1 host controller which had USB 3.0 ports

  • USB 2.0 Camera enumeration works fine on Board 1 with
    a. Windows 10 OS and Microsoft provided inbuilt host controller driver.
    b. Windows 7 OS and vendor’s host controller driver.
  • USB 2.0 Camera enumeration work fine on Board 2 on Windows 10 OS and with Microsoft provided inbuilt
    host controller driver.
  • USB 2.0 Camera enumeration fails on Board 2 on Windows 7 OS and with vendor’s host controller driver.( The issue which i am facing currently)

Note: Same vendor provided host controller driver is used on both Board 1 and Board 2.

What vendor is the XHCI host controller? Are you sure you have the most
recent driver, and that it supports both models of the host controller?

I am i.e my company is the vendor of xHCI host controller driver, but hardware is provided by synopsis .

Have you tried other machines with different XHCI host controllers?
Have you tried more than one instance of the second system?

Yes, the driver is not working on any xHCI1.1 host controller hardware.

Really, what you’re describing here is an XHCI host controller driver
bug. Have you contacted the vendor to see if there is an errata list?
They probably aren’t going to be interested in fixing a bug in a product
they no longer develop for a dead-end operating system.

I know it is an driver issue, but i don’t know or i am not sure why it is giving that problem with xHCI 1.1 host controller hardware.
where should i look start looking, as i need to fix this problem?
It looks like some timing issue, after checking in xHCI 1.1 spec, still i am not able to figure out root cause of the issue

Any inputs are accepted.