• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 65 subscribers
  • Views 1350 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TWL6030: Attaching USB device to VBUS inputs before powering up device is causing delay on V1V8 SMPS switch

Christyan Brown
Prodigy 90 points
Part Number: TWL6030

We are using the output of the V1V8 SMPS switch outputs on a TWL6030B107CMR device as a reference voltage on a XILINX FPGA and PROM (XC6SLX45-2CSG324 and XCF16PFSG48C).

The issue we are facing is as follows:

When booting our board with nothing connected to the VBUS inputs on the TWL6030, the V1V8 power rail comes up at our FPGA device (and PROM) on average 10-15ms after the 3.3V rail (Analog input voltage supply + VBAT) and the FPGA device loads and configures correctly from the PROM.

When booting our board with USB connected to the VBUS inputs on the TWL6030, the V1V8 power rail comes up 400-450ms after the 3.3V rail and causes the FPGA configuration to fail.

Plugging the USB device in after boot does not cause the issue (the FPGA is well programmed and running by then) but is not feasible for our usage.

Is there any known issue with TWL6030 that may be causing this behavior or any leads that I can try to hunt down the cause?

  • 0
    TI__Mastermind 30280 points
    Christyan,

    Do you have a scope shot of the issue occurring that you can attach in this thread?

    I have assigned the expert on the TWL6030 to look into this question, but I think it will be very helpful for him to see the scope shot in order to debug efficiently.
  • 0
    TI__Genius 17380 points
    Hi Christyan,

    Any scope shots you can provide would be helpful, as noted by Brian.

    What about the rest of the sequence, is it delayed as well? For example, VANA or REGEN1. I see in the datasheet a few deglitch / debounce timers associated with VBUS, but they look to be around 30 ms. The only other one I noticed long enough was the Crystal Oscillator start-up time but I believe the TWL6030 should use the RC oscillator until the crystal is stable and would only delay NRESPWRON release.
  • 0 in reply to Kevin LaRosa
    TI__Genius 17380 points
    Hi Christyan,

    One other item is that if the TWL6030 won't start until the VBAT voltage is above VBATMIN_HI. So a valuable scope shot would be VBUS, VBAT, VANA, and V1V8.
  • 0 in reply to Kevin LaRosa
    Prodigy 90 points

    Kevin,

    VBUS is high before and through boot when USB is plugged in.

    C3: VBUS, C4: VBAT

    Without USB plugged in, we see a very short delay between VBAT going high and V1V8 rising:

    C3: V1V8, C4: VBAT

    With USB plugged in we consistently see a much longer delay of ~400-450ms between VBAT going high and V1V8 coming up:

    C3: V1V8, C4: VBAT

    Unfortunately REGEN1 is not connected in this instance and so cannot be probed. VANA is connected but only to two capacitors that are not easily probed.

  • 0 in reply to Christyan Brown
    TI__Genius 17380 points

    Hi Christyan,

    Thank you for the scope shots. Are you using BOOT0=1 or BOOT0=0? In the final scope shot, it looks like VBAT is still rising and BOOT0=0, then VBATMIN_HI (rising edge) is going to be 3.2V. Do you know why the 3.3V supply is still rising for the case when USB is plugged in:

    It looks flatter in the other case:

    You can check with the scope what levels you are seeing, but changing BOOT0 to 1 may solve this issue if it is not set to this already.

    If this doesn't work, let me know and please provide schematics if possible.

  • 0 in reply to Kevin LaRosa
    TI__Genius 17380 points
    Hi Christyan,

    After discussing with some colleagues, we have found that there appears to be a 400 ms debounce on the VBATMIN_HI comparator when VBUS is present in order to prevent overdrawing the USB supply. I did not find this documented in the datasheet.

    We believe the intent is to give the VBAT time to charge up before enabling all the SMPSs. Hopefully you can workaround this in your system.
  • 0 in reply to Kevin LaRosa
    Prodigy 90 points
    Kevin,

    Thank you very much. Fortunately, there are a few ways available to us to solve the issue post startup.
    We will probably either add an LDO to give a dedicated 1.8V supply for the FPGA/PROM or we will trigger the FPGA reset from a GPIO after bootup.

    Thank you very much for the help.