External Power Supply on USB OTG with TPS65950

Hi,

Yes, you can connect it the way you said.

The reason for this is, it will be possible for the device and OMAP to detect VBUS. When you have external VBUS, ensure that the internal CP is not turned ON by software.

Regards,

Gandhar.

Hi Gandhar

How can I turn off the internal CP by software? As in TPS65950 TRM & DM, the register OTG_CTRL's DRVVBUS bit is set to 0 after reset.

And as the USB OTG's specification, in the runtime, the internal CP is turned on and off by its "dual roles" feature.

My question is should I change the USB driver code to turn off the internal CP and which software file should I change?

Regards

Wu Dong

Hi, Gandhar

During OTG 's operation, it can act as both USB host and USB device role.

When it isin USB host mode, the CP is turned on by driver, when it is in USB device mode, the driver will turn off the CP.

Since the OTG IP core in OMAP3530 is designed by Mentor Graphics, so I think the driver code should be in "musb" folder.

But I cannot find the exact position, so would you please check it?

Thanks in advance.

Wu

The following change disables the TPS VBUS supply, but when I attach my external supply, devices are not detected.  Does anyone know what else to check or if the below is not correct?

Thanks,

Cliff

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 705cc4a..193f2f5 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -902,7 +902,8 @@ void musb_start(struct musb *musb)
 
        } else if (is_host_enabled(musb)) {
                /* assume ID pin is hard-wired to ground */
-               devctl |= MUSB_DEVCTL_SESSION;
+               // disable turning on VBUS power supply
+               //devctl |= MUSB_DEVCTL_SESSION;
 
        } else /* peripheral is enabled */ {
                if ((devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS)

A few more observations with the PMIC internal supply disabled:

- when I plug in a device, the D+ line increase from 20mV to 180mV, so it looks like the pullup in the device is trying to pull up the line.

- I don't see any evidence that the Host initiates a USB RESET (drives both lines low), or the chirp sequence for HS negotiation ever starts.

So it seems to me that the USB Host is not active for some reason.

If I go back to the internal TPS VBus supply, I see the expected negotiation sequence as shown in the below diagrams.

So I guess the first question is why can't the device pull the D+ line high?  It seems the Host is holding the lines low for some reason.

I cross posed this issue in the Linux forum here to see if we can get some attention from the PSP folks who are more familiar with the USB driver, the issue is getting out of the scope of the PMU forum but since it is so tied to the original query I did not want to split the thread up just yet.

This sounds like there is something about the change to the USB driver that is messing things up, there are several other places in the driver that reference that MUSB_DEVCTL_SESSION value, however I have not traced through every one of them to see if this could impact them, it would likely be easier to do that by inserting some printk() calls, which is probably what I would try next on your end.

Another angle to take on this from a more hardware perspective (though it implies board modification), would be to physically disconnect the VBUS rail being generated by the TPS65950 and leave the Linux driver to initiate it, than see if you can still enumerate properly using your external 5v supply. This would help to narrow down the problem a bit, if it still works here than we can be fairly sure there is some other driver dependency that is missing, if it still fails when you do this than the 5v supply you have implemented is likely causing a problem.

Gandhar Dighe said:

CP is controlled by DRVVBUS bit. If you want to turn it off I would guess it would be done using the drivers.

Is the DRVVBUS bit the only way to activate the VBUS charge pump? I have been digging through the USB driver code and I cannot find anywhere that this bit is used in the driver, so it seems that the VBUS charge pump is being activated in some other fashion, is it possible this is being done over the ULPI interface as opposed to I2C?

If this is so, would it be ok to let the CP get turned on, and than disable it in software using the DRVVBUS bit over I2C?

Is there any problem with leaving both the external and internal VBUS supplies on and connected?  Will anything melt in the TPS?

Thanks,
Cliff

Hi Bernie,

Thanks for the suggestion to debug the external 5V supply. I dont know how the Linux drivers are written, so cannot comment on how the CP is activated. It can be done via ULPI but I really doubt if it is done that way. I say this because it is much simpler to do it via I2C, I may be wrong though. You can try to look at the ULPI drivers and see if you can find that the DRVVBUS bit is written using the ULPI interface.

You can stop the CP using I2C.

Cliff,

I do not recommend keeping both the VBUS supplies ON. It is not a good idea to drive a single node with two supplies. I dont think TPS will melt but I cannot guarantee and cannot visualize how this will affect the functionality and the application.

It may help if you use Bernie's suggestion to debug your platform.

Regards,

Gandhar.

I'm still looking for a resolution to this same issue.

There is no code in the PSP drivers to write to OTG_CTRL however the registers are clearly defined in usb/otg/twl4030-usb.c.  I find that if in that driver I attempt to clear DRVVBUS bit via 'twl4030_usb_write(twl, TWL4030_OTG_CTRL_CLR, TWL4030_OTG_CTRL_DRVVBUS);'  PMIC VBUS does go to 0V but some other driver/code immediately sets the big and VBUS goes back up to 5V again.

I also find that Cliffs recommendation to not set MUSB_DEVCTL_SESSION in drivers/usb/musb_core.c does in fact somehow (?) clear the OTG_CTRL[5]:DRVVBUS bit and as Cliff mentions also keeps your bus from enumerating thus it has some other effects.  Its not clear to me why this was suggested - I believe the MUSBHDRC specs are not publicly available thus I can't  investigate that driver much.

I find it very frustrating that the responses here from TI seem very knowledgeable about the hardware end but never have any clue as to the software end that the PSP group is working on.

Any suggestions?

Thanks,

Tim

I think this is wrong as it disables SRP which is still needed for enumeration to occur.   I believe in the case of the PSP drivers for the PMIC that the OTG_CTL[5]:DRVVBUS is getting set via ULPI but its not clear to me where - I think its being done internally by the MUSBHDRC.  Part of the confusion is likely the fact that the MUSBHDRC documentation is not publicly available and I don't currently have access to this.  Perhaps that documentation eludes to something in the musb registers written to in musb_core.c that ends up controlling DRVVBUS.

Hi Tim,

I am sorry that you havent got a satisfying reply to your question. I have copied your question on the Linux form and I hope someone looks at it and replies soon.

http://e2e.ti.com/support/embedded/f/354/p/84650/291976.aspx#291976 

Regards,

Gandhar.

Hi.

I also have a design where OTG is always a host and I am using external 5V Power Supply that is connected to VBUS pin and to the connector.

In our products,charge pump capacitor is equipped. And when we use USB devise powerd by external 5V,an unexpected current flows into VBUS pin of TPS65930.

For resolving this problem,we will remove charge pump capacitors.Is it OK?

(To tell the truth,we want to resolve this problem by changing software only. How can we resolve it?)

But many of our products have were shipped already,it is difficult for us to remove charge pump capacitor from now.

Our products hardly use USB funtion.USB is used to upgrade its software. For example, we use USB function in our product for 15miniutes per a month or so.

The rest time we don't initiate USB driver in our product,and both of internal charge pump and external 5V are OFF.

In that case,are there any troubles in TPS65930? Do we have to remove a charge pump after all?

According to our evaluation,if both of internal charge pump and external 5V are on simultaneously,an unexpected current(about 20mA) flows into VBUS pin of TPS65930.

And a surface temperature of TPS65930 increased 5 degrees.All of our products (quantity about 1000) looks operating correctly now.