USB issue moving from PSP 04.06.00.07 to 04.06.00.08

Max,

The patch you referred is to fix the issue as in its comments. We don't see the issue you described on AM335xEVM. Have you done any change in MUSB driver for your custom board? Does the issue go away if you revert this patch?

Hi Bin,

Yes, you cannot see the issue with EVM, because EVM has correct 150 uF capacitor on USB1 Host port. And yes, the issue goes away reverting back the patch. Let's me add interrupts logs and some more details to clarify:

1 - This is what happens at boot with EVM and PSP 04.06.00.08:
[    1.333567] musb-hdrc musb-hdrc.1: --------- INTERRUPT: usbintr (100) epintr(0)
[    1.333606] musb-hdrc musb-hdrc.1: VBUS on (a_idle), devctl 19
...and when I plug a device:
[  679.071727] musb-hdrc musb-hdrc.1: --------- INTERRUPT: usbintr (10) epintr(0)
[  679.079286] musb-hdrc musb-hdrc.1: ** IRQ host usb0010 tx0000 rx0000
[  679.085911] musb-hdrc musb-hdrc.1: <== Power=e0, DevCtl=5d, int_usb=0x10

2 - This is what happens at boot with our board and PSP 04.06.00.08:
[    1.258605] musb-hdrc musb-hdrc.1: --------- INTERRUPT: usbintr (100) epintr(0)
[    1.258636] musb-hdrc musb-hdrc.1: VBUS on (a_idle), devctl 19
...and when I plug a device:
[   44.756286] musb-hdrc musb-hdrc.1: --------- INTERRUPT: usbintr (80) epintr(0)
[   44.763854] musb-hdrc musb-hdrc.1: ** IRQ peripheral usb0080 tx0000 rx0000
[   44.771026] musb-hdrc musb-hdrc.1: <== Power=e0, DevCtl=88, int_usb=0x80
[   44.778015] musb-hdrc musb-hdrc.1: VBUS_ERROR in a_idle (88, <AValid), retry #0, port1 00000100

3 - This is what happens at boot with our board and PSP 04.06.00.07:
[    0.987426] musb-hdrc musb-hdrc.1: --------- INTERRUPT: usbintr (100) epintr(0)
[    0.987457] musb-hdrc musb-hdrc.1: VBUS on (a_wait_vrise), devctl 19
...and when I plug a device:
[   99.025573] musb-hdrc musb-hdrc.1: --------- INTERRUPT: usbintr (80) epintr(0)
[   99.033142] musb-hdrc musb-hdrc.1: <== Power=e0, DevCtl=88, int_usb=0x80
[   99.045410] musb-hdrc musb-hdrc.1: VBUS_ERROR in a_wait_vrise (89, <AValid), retry #1, port1 00000100
[   99.097869] musb-hdrc musb-hdrc.1: --------- INTERRUPT: usbintr (100) epintr(0)
[   99.110137] musb-hdrc musb-hdrc.1: VBUS on (a_wait_vrise), devctl 19
[   99.890594] musb-hdrc musb-hdrc.1: --------- INTERRUPT: usbintr (10) epintr(0)
[   99.898162] musb-hdrc musb-hdrc.1: <== Power=e0, DevCtl=5d, int_usb=0x10

The code lines to focus on are the ones of the patch in ti81xx_interrupt function, and those related to MUSB_INTR_VBUSERROR handling in musb_stage0_irq function (not modified by the patch).

Due to the patch changes, when the very first interrupt (100 aka USB_INTR_DRVVBUS) occurs (both on EVM and on our board), execution falls in the following if-case: (devctl & MUSB_DEVCTL_SESSION) && !(devctl & MUSB_DEVCTL_BDEVICE) && !(devctl & MUSB_DEVCTL_HM). Therefore musb->xceiv->state is not set to OTG_STATE_A_WAIT_VRISE (as was within previous PSP): you can see also in the logs, at the second line.

When MUSB_INTR_VBUSERROR interrupt occurs on plug event (only with our custom board), the musb_stage0_irq will restart the session if state is one of the following: OTG_STATE_A_HOST OTG_STATE_A_WAIT_BCON or OTG_STATE_A_WAIT_VRISE. But withing new PSP state is OTG_STATE_A_IDLE, so session bit is not set again to restart.

The related comment in musb_stage0_irq can be interesting and seems to fit my case (voltage drop transient, due to low value capacitor):

        /* During connection as an A-Device, we may see a short
         * current spikes causing voltage drop, because of cable
         * and peripheral capacitance combined with vbus draw.
         * (So: less common with truly self-powered devices, where
         * vbus doesn't act like a power supply.)
         *
         * Such spikes are short; usually less than ~500 usec, max
         * of ~2 msec.  That is, they're not sustained overcurrent
         * errors, though they're reported using VBUSERROR irqs.

Regarding the patch, I have a question: it checks the host mode bit (MUSB_DEVCTL_HM) in devctl register not to be set, and both on EVM and on our custom board check result is true. But on both boards the USB port I'm testing is configured as Host only (USB1), so I suppose bit is expected to be set and check to fail, isn't it?!

The patch seems to handle an OTG-specific scenario, so I wonder if that check is there to identify OTG configuration of the port: in this case it seems not to work as expected because execution falls there also for Host-only ports...

Max

Max,

It looks like this patch produces a new issue on USB1. Since the MUSB on your board is in HOST only mode, does it use a type-A receptacle? If so, your project is not affected by the issue described in the patch since you don't use a micro-A-male --> type-A-female adapter cable. Is it possible you revert this patch for your project to avoid the new issue?

We will fix the issue soon.

Hi Max,

I raised a bug ticket to track this issue:

https://cqweb.ext.ti.com/cqweb/main?command=GenerateMainFrame&service=CQ&schema=SDO-Web&contextid=SDOWP&entityID=SDOCM00095254&entityDefName=IncidentReport&username=readonly&password=readonly

Qmax said:

Ajay, hope you will read this message.

Ajay is not working with TI anymore.

Thanks,

Sekhar

Max,

I was trying to reproduce the issue and fix it, but I got a question - the USB1 port on the EVM is in Host mode and uses type-A receptacle. There should be no USB_INTR_DRVVBUS interrupt when insert a device since VBUS should be already enabled during MUSB init. Have you used USB1 differently on your board?

I also modified ti81xx.c as following, not exactly the same, but close to VBUSERROR, both USB0 & USB1 have no enumeration issue on EVM. I guess the last thing I could try is to change a low capacitor for USB1. What capacitance do you use for USB1 on your board?

@@ -962,8 +962,7 @@ static irqreturn_t ti81xx_interrupt(int irq, void *hci)
                u8 devctl = musb_readb(mregs, MUSB_DEVCTL);
                int err;

-               err = is_host_enabled(musb) && (musb->int_usb &
-                                               MUSB_INTR_VBUSERROR);
+               err = 1;
                if (err) {

Bin,

Yes, the USB_INTR_DRVVBUS is at board startup during kernel boot, as USB1 is in Host mode with type-A receptacle. On our board with old PSP, I suppose it arises again after VBUSERROR because the USB Controller is re-set in session, so in some way it is re-init. That's my supposition.

The code flow does not fall inside the if (err) { case, but in the following } else if (is_host_enabled(musb) && drvvbus) { case. In fact patch changes occur here. If you move the dev_dbg to dev_err or enable the debug, you should see "Only micro-A plug is connected" on console, also with EVM.

The capacitor we use is 10 microFarad. We are also investigating the effect of the current limiter we have on USB1: probably when plugging a device, the load on VBUS voltage could cause it to fall under threshold, due to current limiter and law capacitor, causing the VBUSERROR detection by the Controller.

Your first suggestion is right, we could probably revert back the patch, as it fixes a case which is not our one, but I would like to understand as much as possible the current situation to be sure not to have issues in the future due to hw o sw weaknesses.

Sekhar, thanks for opening a ticket to track the issue. I'm sorry Ajay is no more in the team. Thanks for your support.

Best regards, Max

Max,

I don't think I understand the flow when VBUSERROR occurs on your board. But anyway, I removed the R558 resister on the AM335xEVM, which leaves only 4.7uF on USB1, then USB1 is still able to enumerate any device without VBUSRRROR.

Do you think the VBUSERROR is caused by something else on your board?

Ravi B,

I did try the patch suggested in your last post, but it didn't work.

Bell

Hi Ravi,

I've just tested the patch with my kernel which is based on PSP 04.06.00.08. Before testing I've also restored the original commit that I had to revert back as a workaround for my custom board scenarios. The patch seems working fine! That's what I see on kernel logs when plugging USB devices:

[  585.434112] ti81xx_interrupt 1007: VBUS error workaround (delay coming)
[  587.426766] ti81xx_interrupt 1007: VBUS error workaround (delay coming)
[  587.966760] usb 1-1: new high-speed USB device number 2 using musb-hdrc
[  588.107318] usb 1-1: New USB device found, idVendor=0781, idProduct=556b
...

The two first lines are new, and come out only when I plug some USB devices (I suppose those that require more current causing the voltage drop), but all the devices seems working fine now. I will run further tests.

Can you add some comments/details about the patch: does it will be committed on git staging branch and included in future releases? Can it be considered as validated/stable or still in validation process?

I don't know if Bell had exactly the same issue, probably is something different.

Thanks for your support.

Max