Post Go back to editing

MAX17260 — model never loads when DesignCap ≥ 0x8000 (threshold bracketed to 16 LSB)

Category: Datasheet/Specs
Product Number: MAX17260

Setup

- MAX17260, external sense resistor 40 mΩ, single Li-ion cell, 4.2 V charge, ModelID = 2
- Capacity LSB = 5 µVh / 40 mΩ = 0.125 mAh, so DesignCap = capacity_mAh × 8
- 40 mΩ was chosen deliberately: the product sleeps at ~125 µA and we need resolution in that regime

The measurement

Same board, same cell, same binary. Only the DesignCap value changes. All registers read after ModelCFG.Refresh has
cleared. Status at entry 0x8082 (POR set), ModelCFG reads back 0x0020 in both cases.

DesignCap 32760 (0x7FF8) -> FullCapNom 32757 FullCapRep 32760 dPAcc preserved OK
DesignCap 32776 (0x8008) -> FullCapNom 5287 FullCapRep 0 dPAcc overwritten FAIL

16 LSB — 2 mAh — separate a working configuration from a failing one. Register 0x18 reads back exactly what was
written in both cases, so the register accepts 0x8008; it is the model load that fails. Reproduced on two separate
ICs.

For our actual cell (4900 mAh, DesignCap = 39200) the gauge reports FullCapNom = 11682 instead of 39200.

What we ruled out
- Byte order — LSB first as documented; independently confirmed: DesignCap = 26800 yields FullCapRep = 26800 exactly
- Host-side signed arithmetic — uint16_t throughout
- Failed writes — DesignCap reads back correctly
- Sequence deviations — matches §3.1 verbatim, including 44138 paired with ModelCFG = 0x8000 for a 4.2 V cell

Initialization paths tried, all failing above 0x8000
1. Option 1 (EZ Config) — four variants, including with and without writing dQAcc/dPAcc
2. Option 1 + §4.6–4.8 "Restoring capacity parameters" with WriteAndVerify — FullCapRep does take the written value,
but the resulting state is inconsistent (FullCapNom rewritten by the IC, RepSOC at 1 % while RepCap/FullCapRep = 25
%)
3. Option 2 (Custom Short INI) — we first ran an EZ Config at DesignCap = 32760, which loads correctly, read back the
resulting RCOMP0 (1248), TempCo (9790), QRTable00 and QRTable10 — so they are values the IC itself derived for this
cell — then issued a second model reload per Option 2 with DesignCap = 39200. Result: FullCapNom = 11682, i.e.
exactly the same wrong value as the plain EZ Config, with identical dQAcc/dPAcc read-backs. The IC converges to the
same state regardless of the path.

Questions
1. Is DesignCap < 0x8000 a hard limit of the ModelGauge m5 engine? Table 3 of the m5 EZ User Guide gives the Capacity
register type as full unsigned 16-bit (up to 327.675 mVh/RSENSE), which would allow 8191 mAh at 40 mΩ.
2. Would Option 3 (full custom INI with OCV table, after cell characterization) lift it? If so, what is the process to
obtain that characterization?
3. Is there any supported configuration that keeps a 40 mΩ sense resistor with a 4900–5330 mAh cell?

Register dumps for any other DesignCap value available on request — the test is fully scripted, a data point takes ten
minutes.

Parents
  • Additional informations 

    Setup
    - MAX17260, ModelGauge m5 EZ, single Li-ion cell (Samsung INR21700-50E / -53G, NCA, 4900–5140 mAh at 0.2 C).
    - R_SENSE = 40 mΩ, so DesignCap = capacity × 8 = 39200 (0x9920) for 4900 mAh.
    - ModelCFG = 0x8020 (Refresh, ModelID = 2, VChg = 0), IChgTerm and VEmpty per UG6597.
    - CGain = 0x0400 (default), COff = 0.

    Procedure: UG6595 Rev 3 (5/21), §2.1 Option 1, applied verbatim
    - POR detected (Status.POR = 1), then wait for FSTAT.DNR = 0.
    - Save HibCFG, then exit hibernate (0x60 = 0x90, 0xBA = 0, 0x60 = 0).
    - Write DesignCap, IChgTerm, VEmpty, then ModelCFG with the Refresh bit set. Poll until Refresh = 0, then restore
    HibCFG.
    - Clear POR with WriteAndVerifyRegister (verified).
    - No other gauge register is written. There is no charging during init, and the cell is relaxed (UG6595 p.6).

    Observation (fresh POR, cell at 3555 mV, VFSOC = 9312 ≈ 36 %)

    ┌───────────────────┬─────────────────────────────┐
    │ Register │ Read back │
    ├───────────────────┼─────────────────────────────┤
     │ DesignCap (0x18) │ 39200 Heavy check mark │
    ├───────────────────┼─────────────────────────────┤
     │ FullCapNom (0x23) │ 39200 Heavy check mark │
    ├───────────────────┼─────────────────────────────┤
    │ FullCapRep (0x10) │ 0 │
    ├───────────────────┼─────────────────────────────┤
    │ RepCap (0x05) │ 0 │
    ├───────────────────┼─────────────────────────────┤
    │ RepSOC (0x06) │ 100 % (while VFSOC is 36 %) │
    └───────────────────┴─────────────────────────────┘

    Other variants tested (same board and cell, all with DesignCap = 39200)
    1. dQAcc/dPAcc written before Refresh. Tried both the MAX17055 guide values (DesignCap/32, 44138) and the UG6595
    §2.3.5 values (DesignCap/2, 0x0C80). Both give the identical result: dQAcc/dPAcc read back 12864/12800 regardless
    of what was written, FullCapNom = 6432 = 39200 − 32768, and FullCapRep = 0.
    2. FullCapRep, MixCap, AvCap and RepCap written after the Refresh (VFSOC/25600 × DesignCap), i.e. the tail of §2.3.5.
    RepCap was written as 39322 and read 0 again less than 107 s later. FullCapRep kept 39200.
    3. Threshold bracketed on the same board, cell and firmware, by changing only DesignCap (sequence of variant 1):
     - DesignCap = 0x7FF8 → FullCapNom 32757, FullCapRep 32760, SOC consistent Heavy check mark
    - DesignCap = 0x8008 → FullCapNom 5287, FullCapRep 0 ✘
    4. Control: same hardware with CGain = 0x0200 and DesignCap = 19600 (capacity × 4). Everything is consistent:
    FullCapNom 19599, FullCapRep 19600, RepCap tracks the coulomb counter, and QH/dQ agree with the expected current.

    Our reading of the data
    - The capacity registers are documented as 16-bit unsigned (UG6597 Table 3, 0–65535 LSB). Storage behaves that way:
    0x8008 and 0x9920 are accepted and read back unchanged.
    - Values computed by the algorithm do not. At DesignCap ≥ 0x8000, FullCapRep and RepCap collapse to 0, which looks
    like a negative value clamped to 0. FullCapNom, when derived from dQAcc/dPAcc, wraps modulo 0x8000.
    - The transition is sharp at 0x8000 (bracketed within 16 LSB).
    - The MAX17055 Software Implementation Guide (same m5 engine) recommends DesignCap between 0x0640 and 0x6000. We could
    not find this rule in the MAX1726x documentation (UG6595, UG6597, MAX17260 datasheet).

    Questions
    1. Does the MAX17260 m5 EZ algorithm require DesignCap, and more generally every capacity quantity including learned
    FullCapRep/FullCapNom, to stay below 0x8000 (or below 0x6000, as for the MAX17055)? If so, is this documented
    anywhere for the MAX1726x?
    2. Is the internal arithmetic on capacity values signed 16-bit? That would explain FullCapRep/RepCap = 0 as a clamped
    negative result, and FullCapNom = DesignCap − 0x8000.
    3. Is CGain = 0x0200 with a physical 40 mΩ shunt (DesignCap, IChgTerm and thresholds computed for an effective 20 mΩ)
    a supported configuration, in the spirit of UG6597 p.19–20 (copper trace sensing)? Are there side effects on
    learning, empty compensation, IChgTerm detection or the current/QH registers that we should be aware of?
    4. If neither applies, what is ADI's recommended configuration for a 4.9–5.3 Ah cell with a 40 mΩ shunt?

    We can provide register dumps (including DevName 0x21), firmware source excerpts and raw logs.




Reply
  • Additional informations 

    Setup
    - MAX17260, ModelGauge m5 EZ, single Li-ion cell (Samsung INR21700-50E / -53G, NCA, 4900–5140 mAh at 0.2 C).
    - R_SENSE = 40 mΩ, so DesignCap = capacity × 8 = 39200 (0x9920) for 4900 mAh.
    - ModelCFG = 0x8020 (Refresh, ModelID = 2, VChg = 0), IChgTerm and VEmpty per UG6597.
    - CGain = 0x0400 (default), COff = 0.

    Procedure: UG6595 Rev 3 (5/21), §2.1 Option 1, applied verbatim
    - POR detected (Status.POR = 1), then wait for FSTAT.DNR = 0.
    - Save HibCFG, then exit hibernate (0x60 = 0x90, 0xBA = 0, 0x60 = 0).
    - Write DesignCap, IChgTerm, VEmpty, then ModelCFG with the Refresh bit set. Poll until Refresh = 0, then restore
    HibCFG.
    - Clear POR with WriteAndVerifyRegister (verified).
    - No other gauge register is written. There is no charging during init, and the cell is relaxed (UG6595 p.6).

    Observation (fresh POR, cell at 3555 mV, VFSOC = 9312 ≈ 36 %)

    ┌───────────────────┬─────────────────────────────┐
    │ Register │ Read back │
    ├───────────────────┼─────────────────────────────┤
     │ DesignCap (0x18) │ 39200 Heavy check mark │
    ├───────────────────┼─────────────────────────────┤
     │ FullCapNom (0x23) │ 39200 Heavy check mark │
    ├───────────────────┼─────────────────────────────┤
    │ FullCapRep (0x10) │ 0 │
    ├───────────────────┼─────────────────────────────┤
    │ RepCap (0x05) │ 0 │
    ├───────────────────┼─────────────────────────────┤
    │ RepSOC (0x06) │ 100 % (while VFSOC is 36 %) │
    └───────────────────┴─────────────────────────────┘

    Other variants tested (same board and cell, all with DesignCap = 39200)
    1. dQAcc/dPAcc written before Refresh. Tried both the MAX17055 guide values (DesignCap/32, 44138) and the UG6595
    §2.3.5 values (DesignCap/2, 0x0C80). Both give the identical result: dQAcc/dPAcc read back 12864/12800 regardless
    of what was written, FullCapNom = 6432 = 39200 − 32768, and FullCapRep = 0.
    2. FullCapRep, MixCap, AvCap and RepCap written after the Refresh (VFSOC/25600 × DesignCap), i.e. the tail of §2.3.5.
    RepCap was written as 39322 and read 0 again less than 107 s later. FullCapRep kept 39200.
    3. Threshold bracketed on the same board, cell and firmware, by changing only DesignCap (sequence of variant 1):
     - DesignCap = 0x7FF8 → FullCapNom 32757, FullCapRep 32760, SOC consistent Heavy check mark
    - DesignCap = 0x8008 → FullCapNom 5287, FullCapRep 0 ✘
    4. Control: same hardware with CGain = 0x0200 and DesignCap = 19600 (capacity × 4). Everything is consistent:
    FullCapNom 19599, FullCapRep 19600, RepCap tracks the coulomb counter, and QH/dQ agree with the expected current.

    Our reading of the data
    - The capacity registers are documented as 16-bit unsigned (UG6597 Table 3, 0–65535 LSB). Storage behaves that way:
    0x8008 and 0x9920 are accepted and read back unchanged.
    - Values computed by the algorithm do not. At DesignCap ≥ 0x8000, FullCapRep and RepCap collapse to 0, which looks
    like a negative value clamped to 0. FullCapNom, when derived from dQAcc/dPAcc, wraps modulo 0x8000.
    - The transition is sharp at 0x8000 (bracketed within 16 LSB).
    - The MAX17055 Software Implementation Guide (same m5 engine) recommends DesignCap between 0x0640 and 0x6000. We could
    not find this rule in the MAX1726x documentation (UG6595, UG6597, MAX17260 datasheet).

    Questions
    1. Does the MAX17260 m5 EZ algorithm require DesignCap, and more generally every capacity quantity including learned
    FullCapRep/FullCapNom, to stay below 0x8000 (or below 0x6000, as for the MAX17055)? If so, is this documented
    anywhere for the MAX1726x?
    2. Is the internal arithmetic on capacity values signed 16-bit? That would explain FullCapRep/RepCap = 0 as a clamped
    negative result, and FullCapNom = DesignCap − 0x8000.
    3. Is CGain = 0x0200 with a physical 40 mΩ shunt (DesignCap, IChgTerm and thresholds computed for an effective 20 mΩ)
    a supported configuration, in the spirit of UG6597 p.19–20 (copper trace sensing)? Are there side effects on
    learning, empty compensation, IChgTerm detection or the current/QH registers that we should be aware of?
    4. If neither applies, what is ADI's recommended configuration for a 4.9–5.3 Ah cell with a 40 mΩ shunt?

    We can provide register dumps (including DevName 0x21), firmware source excerpts and raw logs.




Children
No Data

Before You Switch


Switching languages will make ADI Explorer unavailable. Resume your session by switching back to English and reopening ADI Explorer.