SLUUBY2B September 2020 – May 2022 BQ76952
The BQ76952 device integrates a suite of checks on battery operation and status that can trigger a Permanent Fail (PF) if conditions are considered so serious that the pack should be permanently disabled. The various PF checks can be enabled individually based on configuration settings, along with associated thresholds and delays for most checks. When a Permanent Fail has occurred, the BQ76952 device can be configured to either simply provide a flag (see PF Status A–D() subcommands), or to indefinitely disable the protection FETs (if the Settings:Protection:Protection Configuration[PF_FETS] bit is set), or to assert the FUSE pin (if the Settings:Protection:Protection Configuration[PF_FUSE] bit is set) to permanently disable the pack. The FUSE pin can be used to blow an in-line fuse and also can monitor if a separate secondary protector IC has attempted to blow the fuse.
Since the device stores Permanent Fail status in RAM, that status would be lost when the device resets. To mitigate this, the device can write Permanent Fail status to OTP when the Settings:Protection:Protection Configuration[PF_OTP] bit is set. OTP programming may be delayed in low-voltage and high-temperature conditions until OTP programming can reliably be accomplished. Note: writes to OTP during operation are only allowed if Settings:Manufacturing:Mfg Status Init[OTPW_EN] is set. If Settings:Protection:Protection Configuration[PF_OTP] is set but Settings:Manufacturing:Mfg Status Init[OTPW_EN] is clear, Permanent Fail status is saved to RAM (and will be preserved during a partial reset) but will not be programmed to OTP. If Settings:Protection:Protection Configuration[PF_OTP] is not set, Permanent Fail status will be lost on any reset, including a partial reset through the RST_SHUT pin.
The information that can be written to OTP when a Permanent Fail occurs includes the values of PF Status A ~ D and a Fuse Flag byte, which indicates whether the fuse has been blown or not. This information can be read using the 0x0053 SAVED_PF_STATUS() subcommand, which reports the information saved in RAM, even if the write to OTP has not yet completed.
Normally, a Permanent Fail causes the FETs to remain off indefinitely and the fuse may be blown. In that situation, no further action would be taken on further monitoring operations, and charging would no longer be possible. To avoid rapidly draining the battery, the device may be configured to enter DEEPSLEEP mode when a Permanent Fail occurs by setting the Settings:Protection:Protection Configuration[PF_DPSLP] configuration bit. Entrance to DEEPSLEEP mode will still be delayed until after fuse blow and OTP programming are completed, if those options are enabled.
When a Permanent Fail occurs, the device may be configured to either turn the REG1 and REG2 LDOs off (if Settings:Protection:Protection Configuration[PF_REGS] is set) or to leave them in their present state (if Settings:Protection:Protection Configuration[PF_REGS] is cleared). Once disabled, they may still be reenabled through command.
The Permanent Fail checks incorporate a programmable delay, to avoid triggering a PF fault on an intermittent condition or measurement. When the threshold is first detected as being met or exceeded by an enabled PF check, the device will set a PF Alert signal, which can be monitored using the PF Alert A–D() commands and can also trigger an interrupt on the ALERT pin using the Alarm Status()[MSK_PFALERT] register bit and its associated mask settings.
Note: the device only evaluates the conditions for Permanent Fail at one second intervals while in NORMAL and SLEEP modes, it does not continuously compare measurements to the Permanent Fail fault thresholds between intervals. Thus, it is possible for a condition to trigger a PF Alert if detected over threshold, but even if the condition drops back below threshold briefly between the one second interval checks, the PF Alert would not be cleared until it was detected below threshold at a periodic check.
A Permanent Fail can be cleared by issuing a full reset to the device. The now-obsolete PF_RESET() subcommand is no longer recommended for use.