TPS65950 VBUS comparator issue

Hi,

This should not happen.

In the first case do you clear interrupts before you unplug the cable? Can you measure the voltage on VBUS pin when the cable is unplugged? The threshold is 550mV, the actual level will tell if the threshold is crossed or not.

I am not sure why VBAT and VBUS should behave differently. Please let me know the above information and observation. I will try to get detailed information.

 

Regards,
Gandhar.

 

Gandhar Dighe said:

In the first case do you clear interrupts before you unplug the cable?

I guess I do, it should be handled by generic Linux code or else hardly anything would work (using latest mainline Linux kernel here).  I know it works because I can change i2c registers interactively using Linux shell, and clearing SW2VBUS causes interrupt immediately if it was missed on unplug.

 

Gandhar Dighe said:

Can you measure the voltage on VBUS pin when the cable is unplugged?

My primitive multimeter doesn't register anything at all on VBUS, the same test point shows ~5V when USB cable is plugged.

 

Thanks for checking.

I've tried this without any USB drivers compiled into kernel and it indeed works as expected. After some debugging it turned out that this is somehow caused by OTG controller on OMAP3: if POWER register of OTG block has SOFTCONN bit set, the problem shows up again. Clearing that bit with cable removed causes an interrupt, but if replugged before clearing nothing happens (but unplugging after clear generates interrupt again).

It can be seen even without any USB drivers: set up TPS65950 as before, then on OMAP3 set CM_ICLKEN1_CORE[4].EN_HSOTGUSB bit to enable OTG clock, then SOFTCONN bit on OTG POWER register (bit6 of 0x480ab001). There might be something else affecting this, but to me it looks like this is enough to reproduce the problem.

The USB driver obviously wants to keep SOFTCONN enabled at all times, as it enables USB D+/D- lines. I wonder why it breaks VBUS sensing though.

Hi,

W.R.T the following:
I've tried this without any USB drivers compiled into kernel and it indeed works as expected. After some debugging it turned out that this is somehow caused by OTG controller on OMAP3: if POWER register of OTG block has SOFTCONN bit set, the problem shows up again. Clearing that bit with cable removed causes an interrupt, but if replugged before clearing nothing happens (but unplugging after clear generates interrupt again).

Are you checking the interrupt on TPS side. Ifthat is the case then I think what yousee is correct. TPS will not be able to indicate an interrupt if the current interrupt is not cleared. So, in the above case if an interrupt is not cleared then there wont be another interrupt. In fact, it can be in the interrupt queue.

Let me know if this helps.

 

Regards,

Gandhar.

 

 

 

Gandhar Dighe said:

Are you checking the interrupt on TPS side. Ifthat is the case then I think what yousee is correct. TPS will not be able to indicate an interrupt if the current interrupt is not cleared. So, in the above case if an interrupt is not cleared then there wont be another interrupt. In fact, it can be in the interrupt queue.

I did more testing today. TPS interrupts are handled and everything works perfectly without OTG active on OMAP3, I'm seeing both VBUS interrupts on insert and remove, did several replugs to be sure.

The problem shows itself as soon as USB OTG controller is set up on OMAP3 like I wrote above - clock enabled and SOFTCONN bit set in OTG POWER register (TPS configuratio and interrupt handling is unchanged from previously working state). With these conditions USB_PRES interrupt no longer happens on unplug, and PWR_ISR register on TWL has USB_PRES bit clear after unplug. Clearing SOFTCONN on OMAP3 OTG brings everything back to normal, but the problem is that this bit needs to be set for proper USB operation.

 

Hello,

we still have this issue, and I finally was able to debug it further. I now have a small test case that demonstrates the issue:

enable VUSB3V1, VUSB1V8 and VUSB1V5
VUSB_DEDICATED1 has SW2VBAT set and SW2VBUS cleared (the default)
power on PHY (clear PHYPWD in PHY_PWR_CTRL)
enable clocks (set CLK32K_EN and REQ_PHY_DPLL_CLK in PHY_CLK_CTRL)
enable OTG block (set OTG_EN in POWER_CTRL)

and then:

set TERMSELECT and XCVRSELECT:0 on FUNC_CTRL (write 0x45)
clear DPPULLDOWN and DMPULLDOWN in OTG_CTRL (write 0)

Once the above setup is done, I get VBUS_PRES interrupt and STS_HW_CONDITIONS has STS_VBUS, even no physical USB cable is connected. VBUS measures ~2.1V, and D+ ~2.5V at this point. Enabling D+/D- pulldowns in OTG_CTRL brings VBUS voltage back to 0, VBUS_PRES interrupt triggers with STS_VBUS cleared in STS_HW_CONDITIONS. When in the same "bad" state with unwanted VBUS voltage, shorting D+ or VBUS to ground physically for a moment also has the same effect, and VBUS does not rise back any more. All this is observed on pandora board.

I've performed the same test on beagleboard b5, and it also triggers VBUS_PRES interrupt with STS_VBUS set (no cable connected), but after some milliseconds VBUS_PRES triggers again with STS_VBUS clear and no voltage is visible on VBUS. Main difference between beagle and pandora is that pandora uses charger of this chip while beagle doesn't.

These settings seem to be programmed by mentor USB IP on OMAP through ULPI while it operates, and we lose VBUS detection at this point because it gets stuck in "vbus present" state. It appears the chip is doing some kind of pullup, does anyone know why and can that be disabled somehow?

Grazvydas:

I have exactly the same problem as you after I connected a AC charger(D+ D- shorted together). Have you found a solution?

 

Regards

Luo Yang

Hi,

In you last paragraph you said - stuck in vbus present state.

In this state can you read/write anything to PHY? Is this some known state that can be cleared or you have to recycle the platform?

I dont see why Pandora would do this though it uses the charging block from this device. Does the charging block do anything with USB pins when you see this problematic behavior?

 

Regards,

Gandhar.

 

Hi Gandhar,

 

Do we have any further update regarding topic?   We met some problem to get correcnt USB_PRES interrupt after first USB plug-in, and currently unable to figure out the next debug step.

 

BR,

 

Antony

Hi Grazvydas,

We, at Recon, have similar issue as you guys had.

We have 2.1 volts on the VBUS too - which causes the USB driver not to see a normal disconnection.

How did you guys fix that?

Any errata from TI on that issue?

 

Thank you

Gil

 

Hi,

Gil had this issue because of the ESD protection diodes used on D+, D- and VBUS signals. These diodes were forward biased based on the voltage levels on D+/- and VBUS.