• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 106 subscribers
  • Views 14974 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335X: USB babble interrupt

Peng Liu50174
Expert 1480 points
Other Parts Discussed in Thread: AM3359

Hi,

We noticed one thing during the EMC Electrical Fast Transient test. When one full-speed device such as one barcode reader is connected to the AM335X USB host port(USB port 1 on our board), during EFT test when adding noise to the system power input, there will be USB babble interrupt, and the AM335X automatically switches off the usb power through USB1_ DRVVBUS signal. in order to recover, the software has to reset the host controller.

We also could reproduce the babbe interrupt through just simply shorting both USB1 DP and DM signals to high logic level in full-speed mode (SE1 bus state). 

We are wondering why SE1 bus state can cause AM335X report babble interrupt? because we all say that  A babble error occurs when the hots computer or the device receives more data than the specific maximum packet size.

Is there any setting in the AM335X USB module register that we can use to prevent AM335X from reporting babble error when signals DP and DM are in the SE1 bus state?

 

BTW: when we place one high-speed USB hub between the AM335X USB host port and the USB full-speed device such as one barcode reader, never see the hub switches off barcode reader power when the port to the barcode reader is in SE1 state.

Thanks,

Peng

  • 0
    TI__Guru**** 393215 points
    Hi Peng,
     
    This has been escalated to the factory team. They should reply on this thread.
  • 0
    TI__Guru*** 125646 points

    Peng Liu50174 said:
    during EFT test when adding noise to the system power input, there will be USB babble interrupt, and the AM335X automatically switches off the usb power through USB1_ DRVVBUS signal.

    This is specified in the USB Specs - disable the port.

    Peng Liu50174 said:
    in order to recover, the software has to reset the host controller.

    Yes, this is how to recover from the babble condition.

    Peng Liu50174 said:

    We also could reproduce the babbe interrupt through just simply shorting both USB1 DP and DM signals to high logic level in full-speed mode (SE1 bus state).

    Please don't do that, SE1 is not a valid usb state.

    Peng Liu50174 said:
    because we all say that  A babble error occurs when the hots computer or the device receives more data than the specific maximum packet size.

    This is not accurate. The USB Specs say that "Babble: Unexpected bus activity that persists beyond a specified point in a (micro)frame."

    Peng Liu50174 said:
    Is there any setting in the AM335X USB module register that we can use to prevent AM335X from reporting babble error when signals DP and DM are in the SE1 bus state?

    You can disable the babble interrupt, but this is not a right thing to do. Because the controller already turned off the session when babble happened regardless the babble interrupt disabled/enabled.

  • 0 in reply to Bin Liu
    Prodigy 60 points

    I've been looking at this problem on the Beaglebone board as we spotted exactly the same issue under faily low transients ( a fan switching ). It is a weakness in the BB design which we are trying to find a work around for. One thing that we're struggling to understand is the fall time of the transient injected into the D- line. We believe that the mechanism is a SE1 state being detected which the BB then handles by restarting the link.

    When we look at the D- line transient event using a HS scope with suitable transient precautions for a true measurement we see the decay time looking exponential (repeated 50% decay time is constant).If we assume the drivers are disabled at this point or just after then it should be a simple RC decay and we can calculate the capacitance (or RC) on the line. When we do this and add capacitance then the decay time changes in a way that suggests the pull down is 150k or more. But if we add parallel resistance it suggests that the capacitance is actually several hundred pF. We added 20pF to evaluate the resistance so the two substitution tests suggest to me that there is another driver on the bus. We only have a cable with a 1k5 pullup on the D+ to fool BB into trying to start a link. Can anyone shed any light on this? Our original thought was that the static protection diodes on the bus were rectifying the transients and causing the problem, so we need to understand how the energy is removed to try to best resolve this design problem.

  • 0 in reply to Ian Holmes
    Prodigy 60 points

    I.m wondering if anyone read the last post I made. It seems lots of people have this problem. I can add some more data here.

    All Windows laptops we have tried as USB host do not have this problem at this same level. I see the factory say that the USB spec says a babble should result in the link being reset (by the host - it should issue a USB reset state, it doesn't need the processor to be reset). SE0 and SE1 states can and do occur under transient conditions - the system has to be resiliant against these. We find that adding a CM choke to the D+/D- at the processor end can help - but it does limit the length of line that the USB can drive (due to mismatched drive impedance into the line we think).

    I would like to have a sensible conversation hardware to hardware engineer about this so we can attempt to devise a strong solution to this - which means we need to understand the difference between the USB drivers on the various platforms we have tested. You will appreciate that it is difficult to measure USB data under transient conditions without disturbing things, so much of our testing has had to be poke and report the effect in approach - but we do have data traces that clearly show the difference between AM3359 USB and other systems.

    Can we discuss this with the factory?

  • 0
    Prodigy 10 points

    hi Peng,

    perhaps, u can  chech this barcode reader which including usb barcode scanner which i used before.it's gdod enough for me.

    i hope it's helpful.

    BR,

    zada

  • 0
    Expert 1115 points
    We have the same problem, where you able to solve this issue mr Peng ?
    A full reset of the host controller seems a bit overkill ?
  • 0 in reply to Steve Deschryver
    TI__Guru*** 125646 points

    Steve,

    Steve Deschryver said:
    A full reset of the host controller seems a bit overkill ?

    Please check the MUSB driver in latest kernels, it does not reset the controller for babble handling.

  • 0 in reply to Bin Liu
    Expert 1115 points

    Thanks Bin,

     MUSB driver is that Linux ?  We are using Windows CE, but I know that most development is going on at Linux and Android now.

    Ok, I just read your other answer.

    regards,

    Steve

  • 0 in reply to Bin Liu
    Prodigy 50 points

    I'm experiencing this exact problem on BBBv2 at a very critical time in development, we are just sending out boards now for fab.

    what is the answer to this necessary reboot? it is completely prohibitive and we seem to be committed to the AM335x at this point.

    I am desperate for a solution ASAP

    thanks very much,

    Michael

  • 0 in reply to Michael Cecere
    Prodigy 60 points

    Part of the cause of this is a weak hardware design in the face of Common Mode interference. We had (have) this issue and have implemented the USB mandated reset of the hardware and restart of the service but we see lots of babble events when we try to use the device in a real environment (semi industrial).

    What we have also done, which may work for you, is to add a common mode choke filter to the USB input to the board just before the connector. In our case we added a USB cable with 2.5 turns onto a split ferrite core (the snap on type) - and the USB devices connect after that. I suspect only a small amount of ferrite is needed but ours was based on extensive EMC testing in the lab using a fan heater connected to a timer switch to generate transients :-)

    Subsequent to those tests we have qualified the machine containing the devices in a real EMC facility and gained approval, but bearing in mind there are a number of elements that come together to give the immunity.

    So, it's probably worth giving this a go. It isn't "just shove a ferrite on it", there is a soound technical reason to do this. Also bear in mind that the USB circuit is exposed to static etc so you might want to review whether you should add more protection over all before committing your layout.

    Hope this helps

    Ian