MAX17303G+ nTPrtTh1 register spontaneously changes value, blocking charging.

The NVrecall command works in getting the correct settings in the RAM and resume operations.
I still want to know why the shadowRAM keeps changing and how to prevent it

Hello,

This is not the expected behavior.  Do you have a datalog showing this behavior?  What value does it change to?  What is the cell voltage, current, temperature, protstatus, etc when this occurs?

When LOCK5 is set, you should not be able to write the ShadowRAM nor make any changes to the value copied to NVM.  So it at least seems that is working correctly.

hi,

many thanks for your answer.
The register changes to different values, the latest is 0x0246,

for datalog i have a trace file from my saleae logic analyzer capturing the event.

* cell voltage (measured with analyzerr):3,578V
* cell voltage (reported by fuel gauge): 0xB2CC = 3.5759 V
* current +-1A from the pack to my device
* current (reported by fuel gauge): 0xFFBC = -44 over a 2mOhm resistor is -34mA.
* temperature (reported by the fuel gauge internal sensor): 0x1A67 = 26,402 degrees celcius.
* prottsatus (0D9h): 0x0000.
* state of charge (as reported by the fuel gauge): 3%.

something else of note:

vertical yellow line is the moment my uC detected the change of value in nTPrtTh1 register. a second after that the fuel gauge disconnected the battery completely for 55 seconds, after that the discharge FET is the only one opened. (the right part of the yellow horizontal trace (PCPK) is a 0.5V lower then the battery voltage. Which makes sense because the measured temperature is 24 degrees while the "to hot setting is 2 degrees and the "to-cold" setting is 70 degrees.

I think that if this is the result of the fuel gauge detecting a fault and therefore disconnecting the battery, the Charge pump would not be turned off.
if the SoC was to low the discharge FET should stay turned off,

So could it be that the fuel gauge resets for some reason and how can i best confirm if it is a reset?
I do not have acces to the ProtAlrt Register (0AFh) because I have a 17303 IC. there is not another register that has an error logging function right?

some more info about the board for context: I have a uC that monitors the state of charge of the accupack (3 cells of 18650-35E in parallel) via the fuel gauge. The board uses about 3-4 Watts until the fuel gauge reports a SoC smaller then 10%. after that the uC turnes of everyting it can and goes into a sleep mode (the sleep mode is disabled in my traces because i need the uC to read the nTPrtTh1 register and trigger the logic analyser). the only thing drawing power at that moment is the 3V3 buck converter because that is controlled by the user via an on/off button.

If you need more information of have suggestions for me to try, I am more than happy to help.

It happened again,

This time with a full battery pack, while the charger was connected.

I cannot see any voltage dips or other circumstances that would create glitches or stuff like that.

battery voltage: 4,177V
current: 100mA or so,
temperature: 30 degrees celcius
prottsatus (0D9h): 0x0000.

SoC: 45%.

new temperature setting: 0x5C21 = 92 to hot and 33 to cold.

The idea that the problem can be related to a bad batch problem has been floated around.
so I have checked all of my products, they are all from the same batch (nr: 39x) except for one that was build 1.5 years ago. that one has batch number 29x.

the one with 29x doesn't seem to have the temperature register problems.
can it be a fault in the production batches?

I apologize for the lack of response, our system still had this marked at 'Awaiting Customer Response' so I never came back to see your additional responses.

The Status.POR bit is set to 1 at power up and can be cleared by your system.  It will remain cleared until a another reset occurs, so you can clear that bit monitor if it is ever reset to 1.

We have not had another other customers run into this issue, so I am not thinking it is a batch issue.  I searched through the internal FW source code and confirmed the firmware does not write that register, it only reads from it to determine the temperature thresholds.

Is there any other I2C communication on your bus that could be accidentally writing the register?

hey, good to hear from you,

No, There is nothing writing to the fuel gauge, I used firmware that only does read requests on the I2C bus. The change even happens with the relevant RAM write protected.

I have searched trough the logger for write commands with the values the temperature register changes to but came up empty.

hey, good to hear from you,

No, There is nothing writing to the fuel gauge, I used firmware that only does read requests on the I2C bus. The change even happens with the relevant RAM write protected.

I have searched trough the logger for write commands with the values the temperature register changes to but came up empty.

Is there anyway to hook up the EVKIT SDA/SCL/GND lines to device in your system and use the EVKIT GUI to the log all of the registers to try to capture this behavior? I guess you'd also have to disable your host that is reading so that there is only one I2C Master on the bus.  But this may give us some insight onto what could be triggering this behavior.

I do not have the EVAL kit (yet), is there something specific you are looking for?