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).