Vybrid USBx_VBUS, USBx_VBUS_DETECT, USBx_VBUS_EN and USBx_VBUS_OC pins

[rod_k]

We are looking for detailed knowledge regarding the operation of the Vybrid's USB controller pins.  We are having numerous problems with the USB behavior, and Vybrid documentation does not provide enough information for us to understand what is happening.

Our version of u-boot loads the USB driver (so we can reprogram the kernel and rfs on existing boards).  If the DETECT pin is low, the u-boot driver gets stuck in a brown-out condition (ANADIG_REG_3P0, bit-16 BO_VDD3P0="1" and bit-17 OK_VDD3P0="0").  The USBx_VBUS pin looks good at a nominal 5V, so the Vybrid's 3.0V LDO regulator should be happy. The DETECT pin is not supposed to have any effect on the brown-out bit either, but bringing this DETECT pin high definitely clears the brown-out condition.  The Vybrid does not seem to care which DETECT pin is high either, as long as one of them is high.  Does anyone understand how a DETECT pin can clear the 3.0V LDO brown-out condition?

Also, we continue to have a problem where the Vybrid pulls the USB0_VBUS_EN line high - in both u-boot, and then again when the kernel is loaded.  We understand this VBUS_EN pin is intended to drive an external VBUS FET switch, but we don't want it to enable 5V to the USB connector for no reason.  We don’t see any places in the u-boot or kernel code where the USBx_VBUS_EN pin output is being specifically set or cleared (and it is not pin-muxed as a GPIO pin anyway).  When this VBUS_EN pin is pin-muxed as this particular VBUS_EN function of the USB controller, it seems to have a preprogrammed behavior, but we don’t know what this behavior is, or what config register bit(s) affect this behavior…? What conditions cause the VBUS_EN pin to be set high?  Does the Vybrid USB controller need to be configured in USB Host mode in order for this VBUS_EN pin to be driven high?  If the USB controller is configured in USB Device mode, then should this pin always be seen as a low output?

Our external VBUS FET switch (TPS2051) expects the USB0_VBUS_EN to be active-high.  When the pin is muxed to be the VBUS_EN function though, we don’t really know for sure what polarity the Vybrid part intends for this output pin to have.  Does the Vybrid set the pin high to enable, or high to disable the eternal VBUS FET switch, as switches with either polarity are available?  We have been assuming that it is an active high output (due to the pin name), but maybe this is wrong?

Does anyone know any details surrounding the preprogrammed behavior of the Vybrid USB controller's VBUS_EN pin is and what is the active polarity?

What about the VBUS_OC pin?  OC=high is an overcurrent indication from the VBUS FET switch, and OC=low is current OK?  We think the former here as well, but we don’t see anywhere that this is specifically stated.  We have had to add a single gate inverter to our hardware design to change the OC polarity for the Vybrid,  It would be nice if this polarity were programmable.

Thanks.

[richard_stulens]

Hi Rod,

I've been answering the questions via the FAE as well. I'll try to clarify the remaining issues.

1. u-boot hangs at brown-out until DETECT asserts to 5V.

Is the LDO enabled when u-boot hangs on brown-out with DETECT negated?

As I mentioned before, brown-out is the inverse of OK_VDD3P0. This OK_VDD3P0 will only turn on when the LDO is enabled (ENABLE_LINREG = 1).

Please check if this is enabled. What is the content of the ANADIG_REG_3P0?

2. Either DETECT pin will bring it out of brown-out:

In the emails it was mentioned that there is a 200 mA current into the DETECT pin. This is an indication that somehting is seriously wrong or broken.

The DETECT pins do not go to the LDO. They are comparator inputs. These draw micro-amps not 100 - 200 mA.

Such a a high current probbaly means that there is a leakage path to the PHY supply. I suspect the part may be damaged.

3. USBn_VBUS_EN & OC polarity.

This output is active high. It will be enabled when the USB controller is configured for host mode and the PortPower bit is set in the PORTSC1 register (PORTSC1.PP).

It will stay low when the controller is not in host mode.

The OC pin is indeed active high. The polarity can be inverted by setting bit 8 (OVER_CUR_POL) in the USBCx_CTRL register. No need for an external inverter.

Best regards,

Richard

[richard_stulens · Accepted solution]

Rod,

I just learned from design that the LDO will remain in current-limit mode until VBUS Valid is detected on one of the VBUS_DETECT inputs.

No one has come across this issue as in most designs VBUS and VBUS_DETECT are tied to the connector and thus both will come up at the same time.

I'll add this to the reference manual.

If you have a 5V permanently available and one of the controllers is always host, then you can tie that VBUS and VBUS_DETECT to the 5V supply (before the switch) to satisfy u-boot.

The other option is to ignore the state of the LDO until VBUS_DETECT is at a valid VBUS level. This can be detected in the OTGSC register, bit 9 (AVV). A change of this bit can also generate an interrupt.

In re-checking the email, it seems I misunderstood the 200 mA. The increase of 200 mA system current will not go into the PHY. It is more likely that the CPU frequency is turned up and more peripherals are enabled.

Best regards,

Richard

[rod_k]

Richard,

Thanks for all the help to past few days!

OK this makes sense regarding the DETECT pin vs. the brown-out bit, as we definitely see the brown-out bit is set until one of the DETECT pins go high.  To test this, we programmed the Vybrid to stay in an endless loop in u-boot, just polling the ANADIG_REG_3P0 register.  We can pull either DETECT high or low and see the VDD_OK bit (bit 17) go away and the brown-out bit (bit 16) get set (and vice versa).  Note that for sure we see the brown-out bit getting set (I guess I don't see a current limit bit anyway in this register)...

We are using the USB Device mode driver in both u-boot and the kernel for USB #0.  For whatever reason, the EN pin continues to be driven high.  We will check the driver code for what value it is writing to the PP bit, but it is definitely not be programmed as in USB Host mode.  I have also verified this with the D+ line.  When the USB Device mode driver is loaded, I have verified that the D+ line is driven high when the DETECT line goes high (as per your earlier input).  I have done this for both the USB #0 and USB #1 ports (separately) and this behavior is what we expect.

We are still trying to figure out the EN pin, but we are starting to think we should pin-mux it as a GPIO and not the USB_VBUS_EN function.  It is true that the writing the port power (PP) bit is just like controlling the VBUS_EN line like a GPIO?  We realize the USB controller may also have access to the VBUS_EN function (like when a VBUS_OC occurs) and this might be desirable.

Note the problem we saw with excess 200 mA current was a being caused by contention in our hardware on the DETECT line.  We were trying to read the DETECT line (it was not intuitive to us that we can read the value on the AVV bit), but the GPIO we were trying to read the value on was set as an output pin with value =0.  So pulling the DETECT line high was causing us to sink significant current into this other GPIO.  Sorry about that.

I will let you know right away what we discover.

Thanks,

Rod

[richard_stulens]

Rod,

About VBUS_EN; I think there is an error in the reference manual.

Bit 9 in the USBCx_CTRL register is labeled as Power Mask, but I think it is in fact Power Polarity, similar to Over-Current Polarity

If I'm correct, toggling the bit will invert the VBUS_EN output from its previous state.

Design checked it in the data base and confirmed my suspicion. I don't have a debug capable setup just now so I cannot test it myself.

The new bit description will be as follows:

This bit should be set according to power switch's enable polarity.

• 1 Power switch has an active-high enable input
• 0 Power switch has an active-low enable input

Can you check the code to see if this is causing VBUS_EN to turn on? It can explain what you observe on the system.

Regards,

Richard

[rod_k]

Hi Richard,

We decided to install some work-arounds to help overcome some of the limitations between the Vybrid’s USB capabilities and our requirements.  The most important one is that we are going to use a GPIO to drive the VBUS_EN line. 

We decided this because:

1. It appears from the Vybrid manual that the PP bit may only be programmable one-time after a reset
2. The Tower and Phytec boards do not use this VBUS_EN line and instead use a GPIO
3. We can’t figure out why it is high at power on and maybe it doesn't matter if we have to use a GPIO.

I think we can get the part to do what we need it to do now, so a sincere thanks for you expert help.

Rod

[richard_stulens]

Rod,

Thanks for the feedback.

You can indeed use a GPIO for this functionality, but in host mode the PP bit must still be set for the controller to start operating.

The TWR board uses a GPIO because the PTA lines are used for the trace port.

The PP bit is not a one-time programmable though, it can be turned on and off as required.

The reason why it is high after reset is most likely because these pins have a 100K pull-up resistor and the pin is not driven after reset. I just checked that in the reference manual.

So, if you wanted to use the VBUS_EN pins, you could put a 10K pull-down on the pin to override the 100K pull-up, or use an active-low BUS switch combined with setting Bit 9 in the USBCx_CTRL register to invert the VBUS_EN signal.

Best regards,

Richard

[YixingKong]

This request has been assigned to Richard.

Thanks,

Yixing