This happens during charging via USB-C PD of a LiFePo4 battery when the battery is getting full.
Then the VBAT_OVP_STAT stats flag turns on and seconds later the chip
burns. Relying on the MCU to set CHG_EN to zero is too much risk. I would expect that battery over-voltage protection actually protects by itself and does not rely on the MCU. however, in reality it burns down and even kills the MCU every time by putting an overvoltage onto I2C. Four ESP32 S3Pro are dead too.
Any suggestion? This should not happen at all and without a robust solution I cannot recommend using this TI chip for any project.
settings written by MCU after startup in this sequence:
* CE off on MCU startup and keep it off while writing configuration to registers
* Cell-count 4S
* ADC control enabled
* Charging current control enabled
* SYS voltage limit 12V
* BAT voltage limit 14.5V (LiFePo4 battery top-off voltage; the TI chip fried with lower voltage goals too)
* BAT current limit 1A
* Input voltage limit 20V
* Input current limit 3A
* HVDCP enabled (connected to USB-C PD resulted in 12V/1.5A mode)
* CE on (after settings written), and CHG_EN bit also enabled
MCU runtime:
* reading voltages and fault status
* BAT_OVP
