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.

TPS82130: EN pin pulled High after turn ON

Part Number: TPS82130

Preconditions:

  • TPS82130 is turned-on by GPIO pin from STM32 F3 controller (STM32F334K6T6).
  • MCU GPIO-pin and EN-pin of the TPS82130 are connected dirrectly with a single trace (no additional protection circuitry).
  • MCU is powered by separate traditional 3.3V LDO.

Problem:

  • STM32 MCU dies after 2min when the board powered form 11V battery.
  • STM32 MCU dies after 10min when the board powered from 7V battery.

The output of TPS82130 powers up 3x 1W LEDs with controlled current-sink circuitry driven by DAC-outputs from the same MCU. The purpose of the project - is to have a power-LED modulated with arbitrary waveform from DAC.

I have no issues with LED current-sink circuit, the whole thing was tested and performed well with another traditional BUCK module (MP1584). Now I am just reworking my design from desk-evaluation prototype to field-testing prototype, so decided to go with TPS82130 to save the board space.

LEDPOWER_EN was initially connected directly to STM32 GPIO, without (!!!) any additional protecting circuitry (like current-limiting resistor with Zener  diode).

After reflow and powering up - the board worked for like 10 minutes, then controller died. It took me one more dead STM32 until I've figured out what was the root cause.

It appears that when MCU drives EN-pin to logical 1 (3.3V) - the TPS82130 turns on, what is obviously expected. But then the module pulls the EN-pin up, way higher than the logical 1 - up to the level of battery voltage. 

STM32's built-in protection circuitry for GPIO is tolerant to 5V on the pins, so this design died after 10 min with 7V battery (and like 2 min with 11V battery).

Problem was fixed by scrapping-off the soldermask from the trace and cutting it to fit-in a 330k resistor between MCU GPIO pin and EN-pin of the TPS82130. This forms some sort of voltage divider between internal resistance of GPIO and the level of EN-pin. GPIO pin now stays at the level of 3.6V. So it all works now, but I've wasted 6 hours of my time and thrown away two damaged STM32 controllers into the trash until figured out this strange behavior of EN-pin.

  • Can anyone from TI engineering explain this behaviour of EN-pin?
  • Why it is not mentioned in DataSheet that EN-pin will be pulled up to Vin level after it was driven above 0.9V threshold?
  • If you not gonna fix this in further revisions - please add a distinctive note to a DataSheet that GPIO protection circuitry is strongly recommended.
  • I found nothing but some words about internal 400k pull-down, which is disconnected when TPS82130 turns on - is it just to save some 8uA of power?

I do believe that my experience depends on actual  GPIO implementation, so MCUs form other manufacturers could have this tolerated better (haven't tried it with Cortex-M from TI though).

 

  • Hi Oleksandr,

    Thank you for your detailed explanation.

    There is no internal pull-up structure on the TPS82130's EN pin. So, this voltage must come from outside the device. Did you monitor the EN pin with a scope to see the voltage rise to Vin? I could think of leakage through a solder short or very close PCB traces which cause some leakage that could cause the voltage to rise. You might also try adding a ~100k pull down on EN to see if this clamps whatever leakage is pulling EN up.

    If you had an EVM of TPS82130 and your MCU, you could wire them together to prove that EN is not being driven higher.

    As well, we have this reference design for the discrete device which might be applicable to your designs: http://www.ti.com/tool/PMP9762 How are you controlling the LED current in your design?

    Finally, I doubt that 1000uF output cap is a good idea or necessary. Combined with the small SS cap value, this is quite some inrush current during startup to charge up the 1000uF.
  • Hi Chris, 

    Thank you for prompt reply.

    Yes, that is exactly what I did. I've used the digital scope with 10x probe (Siglent SDS1072CML) to measure the voltage at EN-trace:

    • After desolating the MCU and powering up the board - floating LEDPOWER_EN pad (whhich is connected directly to EN-pin) stays at GND level.
    • So there isno current leak. +BATT pin is sits right next to EN-pin - so I've had the very same thought about possible reflow failure (like a solder-paste short-circuit between two pins).
    • With a resistor added between 3.3V line and LEDPOWER_EN pad of the MCU (to simulate logical 1) - the module turns ON, but the LEDPOWER_EN pad gets to the level of BATT voltage.

    I can make the screen shot from the scope of the rising slope later tonight (if you really need it).

    And here is the fix to my problem - cutting the trace to solder-in 330k resistor. Luckily I had long-enough trace section on the back side of the board.

    Now, with the new STM32 MCU soldered back in place - the LEDPOWER_EN pin goes only up to 3.6V (when firmware flips it up). What seems safe for GPIO operation. Passed 1 hour duration DC current test on all three LEDs (2.5A on the TPS82130 module).

    Here is the PCB-layout section screenshot, maybe this will help with some cllues on other current leaks or shortages:

    Also, could it happen that TPS82130 will start having this side-effect if it was overheated and somewhat damaged during reflow? I am using very cheap reflow oven from china - T962 with all the hacks to improve its performance from Unified Engineering. It works OK, but have non-uniform heating inside, so some sections could slightly overheated above desired values.

    I've actually even re-soldered another TPS82130 with hot-air rework station - still the same behavior (though it could be  manufacturing defect of one item).

    Here is a DAC-to-LED current controller schematic, which is pretty basic:

    • Using op-amp with 1 Ohm 1 W sensing resistor feedback. 
    • The first stage is a DAC buffer recommended by STM32 application note for faster DAC performance (10k feedback forms an inverting A=1 gain with internal 10..15k resistance of the MCU DAC module)
    • Then goes a resistor divider R205-R204 to limit the LED current slightly under 1A. OSRAM SFH4726S is rated at 1A continuous DC, so LEDs are safe. After implementing and debugging the firmware I will try switch divider values to allow overdrive up to 1.5..2.0A on pulsed AC signals.  So I've added that overkill 1000uF cap you mentioned to compensate for the pulsed current surges in the future (all three LEDs all-to-gather will suck up to 6A) This is not a strong requirement for my application, its a personal hobby project I am having fun with.
    • Added R209 to slightly pull up the sensing feedback from the rail. OpAmp is Rail-To-Rail, but it can drive the output only down to somewhat 25mV. So the feedback and reference input from DAC will work together in the range which is slightly shifted closer to virtual ground at 1.6V. Allowing to turn off the MOSFET completely.
    • C205 - is a bypass for the dual OpAmp package.

    I did the research on available LED drivers and neither of what I've found fits my needs. My application requires an LED to be modulated with nice sine-waveforms or even something more complex than that, so it would be easy to extract the signal from noise in receivers DSP. Already done experimenting with simple square waveforms, since  they are the sequence of multiple fading harmonics what due to intolerances in the sensor's analog-filtering circuitry produces huge non-linear effects in its output data. Yes I can modulate 10kHz since wave with say 500kHz PWM, but that is still not clean-enough approach for me. So current-sink I've got looks better and easier in firmware implementation. I am using adjustable BUCK only to tune the LED voltage to slightly above the required drop, so MOSFET working in ohmic-mode will-not overheat (it will have deal with way smaller remaining voltage drop ).

    Thank you,

    Alex

  • Thanks for all the details.

    With hand soldering and 'cheap' reflow, there's no way to tell what kind of flux residue, etc. is stuck under the IC that could make a leakage path. There is no such path inside the IC. You might want to order a TPS82130 EVM and wire it into your original circuit, just to prove that EN doesn't go high on its own. The external EVM wouldn't need to drive the LEDs, but just be turned on with the same Vin level.

    On your layout, both the input and output caps need to have their GNDs be close to the IC's GND with a direct connection there. In fact, just swap the locations of the input cap and input connector. The input cap needs to be right next to the IC.
  • Hi Chris,

    Your comments about my mistakes in board layout helped me to fix the issue.
    So the were some induction effects, maybe caused by capacitors grounded through vias. I had 400mV peak-to-peak spikes at 2MHz frequence (switching frequency of this power module). I've fixed the issue adding two by-pass 100nF capacitors on top layer. One between battery pins. And one between ground pin and output pin of the module. No ripple is closer normal (20 mV peak-to-peak) and no high voltage effects on EN pin.

    Thanks,
    Alex
  • Thanks for sharing your results!