MAX17261 ALERT Pin Occasionally Stuck Low - Status Register Not Clearing Consistently

[Gowri_M]

Hi

I am using the MAX17261 fuel gauge IC and my MCU is STM32U5G7VJTXQ. According to fuel gauge's datasheet, the ALERT pin (active low pin) is asserted under the following conditions:

• SOC change
• SOC crossing minimum or maximum thresholds
• Voltage crossing minimum or maximum thresholds
• Other configured alert sources

I have implemented the initialization sequence as recommended in the device’s Software Implementation Guide .

Expected Behaviour

Whenever an alert condition occurs:

1. The ALERT pin is asserted low.
2. The corresponding bit in the STATUS register is set.
3. The MCU detects the alert via an interrupt (triggered on a rising/falling edge).
4. In the interrupt handler, the STATUS register is read and cleared.
5. Once cleared, the ALERT pin should de-assert, allowing subsequent alerts to generate new interrupts.

Observed Issue

For most cases, the behavior works as expected - each SOC change triggers an alert, the MCU receives the interrupt, and the STATUS register is cleared in the interrupt handler.

However, occasionally, the STATUS register does not get cleared successfully, even though the clear operation is performed in the interrupt handler. When this happens:

• The ALERT pin remains asserted low.
• No further interrupts are received by the MCU, since the interrupt is edge-triggered.
• The system effectively stops receiving any further alerts.

This issue is rare and non-deterministic. So far, I have observed it only three times, and I have not been able to reliably reproduce the issue, which makes debugging difficult.

Questions

1. Are there known corner cases where the STATUS register may fail to clear?
2. Is there a recommended sequence for reading and clearing STATUS bits to ensure proper ALERT de-assertion?
3. Are there any best practices recommended to handle such rare ALERT-stuck conditions?

Any insights or suggestions for diagnosing or mitigating this issue would be greatly appreciated.


Thank you!

[bmckenney]

This sounds like a race of some sort (or maybe an unnoticed transaction failure).

Try re-reading the STATUS register after writing it

Are you writing STATUS to =0, or only clearing the bits you're interested in?

[Gowri_M]

Hi,

I'm reading the status register on every second. That's how I noticed, the bits are not getting cleared. 

Initially I was clearing the bits corresponding to the alert generated, but this too created the same issue. So now I'm clearing the entire status register, when an alert is raised. But even this too is failing.

[Andrew Neil]

---

@Gowri_M wrote:

Questions

1. Are there known corner cases where the STATUS register may fail to clear?
2. Is there a recommended sequence for reading and clearing STATUS bits to ensure proper ALERT de-assertion?
3. Are there any best practices recommended to handle such rare ALERT-stuck conditions?

---

None of this has anything to do with ST or STM32.

These all relate to the MAX17261, which is an AD product - nothing to do with ST.

You need to go to AD for support with their product:

https://www.analog.com/en/support.html

https://ez.analog.com/search?engineerzone%5Bquery%5D=MAX17261

https://www.analog.com/en/products/max17261.html

[bmckenney]

If, in response to re-reading, you write STATUS=0 (again), does it "stick" then? Supposing that you (eventually) succeed, I suspect that will be your workaround.

I didn't find an Errata sheet for the MAX17261. If you're convinced that your status-clearing transaction isn't silently failing, then, as Andrew points out, you probably need to ask Maxim (ADI). 

[Edit: I notice that BegoonLab's driver in Github (here) includes a write-verify function (3 retries). Maybe they know something we don't.]

[Andrew Neil]

---

@Gowri_M wrote:

Any insights or suggestions for diagnosing or mitigating this issue would be greatly appreciated.

---

1. Use an oscilloscope to verify that the I2C lines are clean, good edges, etc.
2. Use a logic analyser to capture the transaction; verify that your timing, etc, is well within specified limits;
   try to capture both working and non-working cases.
3. Instrument your code for visibility of what's going on