SLUUB65B May 2015 – December 2022
To provide increased flexibility for capacity-based interrupts to the host, the fuel gauge incorporates a Battery Trip Point (BTP) function that allows the system to dynamically update the traditional SOC1 Set Threshold and SOC1 Clear Threshold at runtime using the BTPSOC1Set() and BTPSOC1Clear() standard commands. These thresholds are used to trigger an interrupt on the HDQ pin whenever the set or clear thresholds are crossed following an update to the BTPSOC1Set() and BTPSOC1Clear() values. Configuration of the interrupt polarity and enable/disable of the feature is provided via the Pack Configuration [INTPOL] and Pack Configuration C [BTP_EN] bits, respectively, while initialization values for the interrupt set and clear thresholds are programmed in SOC1 Set Threshold and SOC1 Clear Threshold as normal.
Enabling of the BTP feature automatically disables all other interrupt sources on the HDQ pin, so care must be taken in configuring the fuel gauge for each particular end application, especially if non-BTP interrupts such as overtemperature, internal short detection, Tab Disconnect Detection, and battery low and high indications are required in the system.
When BTP is enabled, the fuel gauge continuously compares RemainingCapacity() with the values programmed in BTPSOC1Set() and BTPSOC1Clear() to determine whether or not it has crossed below the set or above the clear threshold. Once a threshold is crossed, additional conditions are verified to guard against an unintended interrupt trigger. For the BTP set threshold, the direction of current flow is checked to confirm that a discharge event is occurring. If true, the Flags()[SOC1] bit is set to 1 and an interrupt asserts on the HDQ pin. For the BTP clear threshold, the device again checks the direction of current flow to ensure that a charge event is occurring. Afterwards, an internal variable is examined to determine whether or not a change in the state of Flags()[SOC1] has already occurred due to a prior clear threshold crossing. If true, no change is made and a new interrupt will not fire; however, it is implied that a pre-existing interrupt will still be asserted. If false, the current state of Flags()[SOC1] is flipped to its opposite value and an interrupt subsequently triggered on the HDQ pin. In this way, the correct behavior is guaranteed in cases where the host updates the BTP set and clear thresholds diligently based on HDQ interrupts, but also when there is a failure to update the thresholds. If, at any time, new values are written to either BTPSOC1Set() or BTPSOC1Clear(), then the [SOC1] flag automatically reinitializes to 0 and the HDQ pin de-asserts to its default state. The entire functional flow of the BTP feature is illustrated in Figure 6-1, BTP Algorithm Flow.
In normal usage, the BTP thresholds are continuously updated by the host system at predetermined increments, each time reinitializing the Flags()[SOC1] bit to 0 and waiting for the crossing of the next threshold to trigger a new interrupt. If the thresholds are always updated after each interrupt, then it is implied that the crossing of a set or clear threshold always triggers a new interrupt. This is highlighted below in Figure 6-2, BTP Configuration with Multiple Thresholds.
However, it is possible that the host may fail to write new thresholds or experience a significant delay in attempting to do so. In this case, there could be an occurrence where the clear threshold is crossed after an interrupt due to a prior set threshold crossing. Thus, the [SOC1] bit would experience a change but a new interrupt would not be triggered on HDQ. Thus, continued crossings without updates to BTPSOC1Set() or BTPSOC1Clear() will only result in changes to Flags()[SOC1]. Figure 6-3, BTP Configuration with Shared Thresholds, shows the case where identical thresholds are written to BTPSOC1Set() or BTPSOC1Clear(). Figure 6-4, BTP Configuration with Separate Thresholds, shows the alternate case where unique thresholds are written to BTPSOC1Set() or BTPSOC1Clear().