AM3352: USB babble interrupt

Hi,

Please post which Linux version you are using. 

Hi,

We are using a Linux 4.13 based kernel. Including AM335 patches from Robert C. Nelson / TI kernel tree.

Best regards,

Jelmer Graat

Hi Jelmer,

Have you limited the AM335x Host to Full/Low-Speed mode in your SW? I ask because I do not see USB2 Chirps in your scope plot. If so, please remove this restriction and re-test.

Hi DK,

The high-speed negotiation (USB2 Chirps) need to be initiated by the device and not the host. As the barcode reader is a full-speed device, there are no chirps visible.

When we connect a high-speed device (in this case a thumb drive) the chirps are indeed present:

Best regards,

Jelmer Graat

Hi Jelmer,

Sorry, I misunderstood that the device was indeed FS-only and thought you might be limiting the bus speed from the Host.

How many boards do you have that exhibit this issue? %? Please provide the contents of 0x47401B38 on a board that shows this babble condition.

Hi DK,

We have seen the babble interrupt occur on multiple boards. I think on approximately ~50% of the boards. On some boards, the babble interrupt seems to happen more often than other boards.

The content of 0x47401B38 is as following:

47401b38: 409f5160

Best regards,

Jelmer Graat

Hi Jelmer,

Thanks for the info. The data you provided from the register read looks fine. No issues there.

To answer you original question: no, I am not aware of a mechanism that would allow a Device to delay the first SOF of a Host.Given that this issue appears to only affect a % of your boards (rather than every one of them), I think it make sense to focus on the electrical side of things. Please try strongly coupling your USB connector shield ground to the board ground by replacing C148 with a 0-Ohm resistor and note if the problem occurrence rate changes.

Hi DK,

I replaced C148 with a 0E jumper. No change in behaviour.

Note that even if the problem is on the electrical side of things, I think it still makes sense to focus on the PHY. The data presented in the first post proves that there must be some relation between the PHY state and the bus characteristics even before the barcode reader has send any USB package. If we know what mechanism could cause the PHY to wait with sending SOF packets after reset, I think we can converge more quickly to the root cause. 

Best regards,

Jelmer Graat

Hi Jelmer,

The Linux MUSB driver has the babble recovery logic implemented, which resets the USB controller and then the USB device enumeration should go through. Is the barcode reader device enumerated properly after the babble happened on your platform?

Hi Bin Liu,

Not always: sometimes the barcode reader is enumerated properly after the babble (and corresponding USB reset) and sometimes another babble occurs again. The USB reset seems to have the same effect as unplugging and reconnecting the barcode reader.

Best regards,

Jelmer Graat

Hi Jelmer,

Yes, the babble recovery mechanism does initiate a bus reset, which in effect reproduces a unplug/plug event, but without the associated electrical noise of the connection itself. Does the problematic device eventually connect and work?

Using the same device that you tested for me earlier, please write 0x4740B538 0x409FB460 into 0x47401B38 and retest.

(edited)

Hi DK,

Eventually the barcode reader connects and works fine (and keeps working). It seems random how many babble interrupts it takes before the barcode reader is connected successfully.

I will try writing the register values you posted in the device tomorrow. What settings will be affected by this change of parameters?

Best regards,

Jelmer Graat

Jelmer,

I'm tweaking the PHYs analog trim settings. All USB PHYs must be tuned as part of their production to account for process variability and the value you provided me earlier was for me to ensure that there wasn't some sort of anomaly in our trimming. Everything looks good from our end, but because you have only seen this issue with a single device, and it eventually does connect (and works well), my suspicion is something about your board design or the trimming of the bar code reader itself is introducing marginality into the circuit. All trimming for analog PHys is done to within a range, and there may be sub-optimal overlap between the two devices at hand even though both are compliant to the specification.

The write I've asked you to do here is to move the our PHY trim down in this range as a debug test.

Hi DK,

Thanks for your input and explanation. I tried the new trim value (0x409FB460 into 0x47401B38) but unfortunately no luck: it does not seem to have any effect on the babble behaviour.

Best regards,

Jelmer Graat

Hi Jelmer,

I don't think the babble can be fully eliminated from the system. But can you please try the following kernel patch to see if it reduces the reoccurring times after the initial babble condition? It would shorten the recovering time.

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 403eb97915f8..fd341544a133 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -485,7 +485,7 @@ static int dsps_musb_init(struct musb *musb)
         * logic enabled.
         */
        val = musb_readb(musb->mregs, MUSB_BABBLE_CTL);
-       if (val & MUSB_BABBLE_RCV_DISABLE) {
+       if (0) {
                glue->sw_babble_enabled = true;
                val |= MUSB_BABBLE_SW_SESSION_CTRL;
                musb_writeb(musb->mregs, MUSB_BABBLE_CTL, val);

Hi Bin Liu,

Thank you for your input. We will try to test the kernel patch as soon as possible, but as our software development team is working on a deadline this might take a while.

For clarification; will the kernel patch possibly reduce the reoccurring times (such that the babble condition only occurs once) or does it reduce the time each 'babble' condition takes? How does the patch work?

Best regards,

Jelmer Graat

Hi Jelmer,

When a babble condition happens, the babble recovery handler in the musb driver checks some registers and takes corresponding actions to recover it. But when enumerating the usb device after the recovery, babble might happen again, then the recovery handler kicks in again. This cycle might happen multiple times in some cases.

I have found that if the driver babble handler is simplified to only take the conservative action, the babble condition happens much less after the recovery, or even is reduced to only once.

So what the patch does is to simplify the babble handler to only take the conservative action, so babble condition might be reduced to only once or very few times after the usb device is attached. The patch won't reduce the time for each babble and its recovery take.

Hi Bin Liu,

Thank you for your explanation. Our software engineers have installed the kernel patch. Unfortunately, it doesn't solve the issue but does change its behavior. The USB/VBUS reset seems to be performed more early (just after the host USB reset is disabled) and the USB bus doesn't recover any more (VBUS is kept low until a reboot is performed):

(D+ = green, D- = yellow, VBUS = red)

In console, no babble is observed anymore but a different error:

[  139.676086] usb 1-1: new full-speed USB device number 3 using musb-hdrc
[  144.876077] usb 1-1: device descriptor read/64, error -110
[  160.236088] usb 1-1: device descriptor read/64, error -110
[  160.506070] usb 1-1: new full-speed USB device number 4 using musb-hdrc
[  165.676082] usb 1-1: device descriptor read/64, error -110
[  181.036088] usb 1-1: device descriptor read/64, error -110
[  181.306072] usb 1-1: new full-speed USB device number 5 using musb-hdrc
[  191.826081] usb 1-1: device not accepting address 5, error -110
[  191.976083] usb 1-1: new full-speed USB device number 6 using musb-hdrc
[  202.546069] usb 1-1: device not accepting address 6, error -110
[  202.552560] usb usb1-port1: unable to enumerate USB device

Best regards,

Jelmer Graat

Hi Jelmer,

It turns out that the kernel version you use - v4.13 is not TI supported kernel and it has a bug which could cause the babble handler to not be triggered. Please apply the following patch to fix the bug and test along with the previous patch.

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 87cbd56cc761..bff7085a8ca3 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -906,7 +906,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 int_usb,
         */
        if (int_usb & MUSB_INTR_RESET) {
                handled = IRQ_HANDLED;
-               if (devctl & MUSB_DEVCTL_HM) {
+               if (is_host_active(musb)) {
                        /*
                         * When BABBLE happens what we can depends on which
                         * platform MUSB is running, because some platforms
@@ -916,9 +916,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 int_usb,
                         * drop the session.
                         */
                        dev_err(musb->controller, "Babble\n");
-
-                       if (is_host_active(musb))
-                               musb_recover_from_babble(musb);
+                       musb_recover_from_babble(musb);
                } else {
                        musb_dbg(musb, "BUS RESET as %s",
                                usb_otg_state_string(musb->xceiv->otg->state));

Hi Bin Liu,

With the new patch, the original behaviour is back again (babble's). The reoccurring times do not seem to have changed. The babble interrupt still can occur multiple times after each other before successful connection:

[  +0.061019] musb-hdrc musb-hdrc.1: Babble
[  +3.200017] musb-hdrc musb-hdrc.1: Babble
[  +3.189981] musb-hdrc musb-hdrc.1: Babble
[  +3.200102] musb-hdrc musb-hdrc.1: Babble
[  +3.199895] musb-hdrc musb-hdrc.1: Babble
[  +3.200002] musb-hdrc musb-hdrc.1: Babble
[  +3.200057] musb-hdrc musb-hdrc.1: Babble
[  +3.199938] musb-hdrc musb-hdrc.1: Babble
[Feb 6 16:22] musb-hdrc musb-hdrc.1: Babble
[  +3.200003] musb-hdrc musb-hdrc.1: Babble
[  +3.199998] musb-hdrc musb-hdrc.1: Babble
[  +3.200053] musb-hdrc musb-hdrc.1: Babble
[  +3.199946] musb-hdrc musb-hdrc.1: Babble
[  +3.200006] musb-hdrc musb-hdrc.1: Babble
[  +3.199994] musb-hdrc musb-hdrc.1: Babble
[  +3.199998] musb-hdrc musb-hdrc.1: Babble
[  +3.288996] usb 1-1: new full-speed USB device number 24 using musb-hdrc
[  +0.061017] musb-hdrc musb-hdrc.1: Babble
[  +3.288981] usb 1-1: new full-speed USB device number 25 using musb-hdrc
[  +0.181528] usb 1-1: New USB device found, idVendor=05f9, idProduct=4204
[  +0.007145] usb 1-1: New USB device strings: Mfr=2, Product=1, SerialNumber=3
[  +0.007591] usb 1-1: Product: Handheld Barcode Scanner
[  +0.005444] usb 1-1: Manufacturer: Datalogic ADC, Inc.
[  +0.005421] usb 1-1: SerialNumber: S/N G19D30866

Best regards,

Jelmer Graat

Hi Jelmer,

Thanks for testing the patch. The intention was to check if it can improve the babble handling, but the test result shows it doesn't.

Here is another patch to test. I don't have much hope this patch will change much, but it doesn't hurt to give it a try. Please keep the bug fix patch for musb_core.c I just sent an hour ago in the kernel, but revert the patch I sent yesterday for musb_dsps.c and apply the following patch instead.

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index bc6a9be2ccc5..1018542e434c 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -729,7 +729,6 @@ static struct musb_platform_ops dsps_ops = {
        .disable        = dsps_musb_disable,

        .set_mode       = dsps_musb_set_mode,
-       .recover        = dsps_musb_recover,
        .clear_ep_rxintr = dsps_musb_clear_ep_rxintr,
 };

Hi Bin Liu,

Thank you for your input. We tested the patch this morning, it doesn't seem to affect the behaviour.

Best regards,

Jelmer Graat

Hi Jelmer,

Thanks for testing all the patches. The results confirmed the software doesn't affect the babble behavior.

Hi DK,

Unfortunately, it is still unclear what causes the babble. I have full tested the PI and SI (Power and Signal Integrity) of both the barcode reader and our device and it is all good. We tested several patches proposed by TI, but no luck.

I am convinced that the best way forward would to dive deeper in the PHY. You answered that you are not aware of a mechanism that would allow a device to delay the first SOF of a host. Let me rephrase the question in a more general way:

How can a USB device influence the host USB PHY in any way before the first package is sent?

The data in the first post shows that the the device does influence the host before the first package is sent. It would be really helpful if we would know how.

Best regards,

Jelmer Graat

Hi Jelmer,

I'm running this by our internal PHY analog team for comment. Hopefully will have something in a day or two.

Jelmer,

To get ahead of this, could you please remove all in-line components from the USB bus and retest? The PHY team will ask for this first. This includes removal (and then bridging) of common mode chokes, ESD devices, and inductors. Please also verify that you have >=120uF of capacitance on VBUS.

Hi DK,

Thank you for running this by your internal PHY analog team, it's highly appreciated.

I just removed the ESD diodes, removed and shorted the series common mode choke, increased the VBUS capacitance from ~100uF to ~150uF. No change in behaviour, the babble still occurs. Additionally, I removed and shorted a bead which is placed in series with VBUS supply and the VBUS connector pin. Again no change in behaviour.

Best regards,

Jelmer Graat

Hi Jelmer,

Met with a member of the PHY design team and he had a theory on what could cause this. He suggestion was that perhaps there is an impedance discontinuity in the USB path with this specific device that causes a signal reflection to be latched before we can turn off our receiver and complete the transition to output mode at the end of reset. The controller expects the bus to be idle prior to sending the first SOF so any activity (such as the aforementioned reflection) could possibly delay it. This latched reflection would also result in a babble condition.

It would be interesting to insert a very long and very short USB cable in the path to see if the issue changes.

Hi DK,

Thank you very much for your response, I think we are on the right track. Previous week, I have shared a report with our contact at TI with additional information (SI measurements, observations). In this report it is stated that the cable length indeed has an effect on the babble behaviour. When the cable is extended with a sufficient length, the babble behaviour disappears. I have done some additional tests:

The results are is in line with your proposed theory of the impedance discontinuity in the USB path that causes a signal reflection before the receiver is turned off.

- Would it be possible to fully verify this theory by somehow 'measuring' the signal reflection/receiver turn-off time margin?

- Is there a solution available? Is the receiver turn-off time configurable or fixed?

Best regards,

Jelmer Graat