MAX17320 plethora of issues. Charge and discharge termination lead to OVP and UVP, FETs do not get deactivated, poor documentation

Hello,

The behavior described above is definitely not the expected behavior.  The OVP and UVP are configurable values and the CHGFET should open when the cell voltage of any cell exceeds the OVP threshold and the DISFET should open when the cell voltage of any cell drops below the UVP threshold.  If you can provide the Complete INI file that should be generated by the EVKIT GUI, we are happy to review the settings to see if anything is not configured properly.

Regarding the charging behavior, the MAX17320 will not limit the charge and stop it once the termination current is reached.  The external charger should be used to limit the charging and stop it at the appropriate time.  The MAX17320 will open the CHG FET if the OVP threshold is exceeded.  When the current tapers to the configured IChgTerm value, the Fuel gauge will report 100%, but it doesn't stop the charging.

Thanks

Dear GenevaC thank you for mentioning jcole97 

Dear jcole97, thanks for your answer, and apologies for the late reply.

For context, we are using a custom 3S battery pack (2500 mAh nominal). Our MAX17320 is a custom board and is controlled by an ESP32-S2 via I2C. We use the EVkit Wizard as an INI file generator, which we manually load using our custom firmware.

Here is the latest INI file we have been working with for your consideration. Below, I will describe the most recent issues we have been facing for the past weeks or so.

Device = MAX173xx
Title = EVKIT Configurator Profile Generated on 2025/11/06 16:38:37
0x180 = 0x0000		//nXTable0 Register
0x181 = 0x0000		//nXTable1 Register
0x182 = 0x0000		//nXTable2 Register
0x183 = 0x0000		//nXTable3 Register
0x184 = 0x0000		//nXTable4 Register
0x185 = 0x0000		//nXTable5 Register
0x186 = 0x0000		//nXTable6 Register
0x187 = 0x0000		//nXTable7 Register
0x188 = 0x0000		//nXTable8 Register
0x189 = 0x0000		//nXTable9 Register
0x18A = 0x0000		//nXTable10 Register
0x18B = 0x0000		//nXTable11 Register
0x18C = 0x0000		//nVAlrtTh Register
0x18D = 0x0000		//nTAlrtTh Register
0x18E = 0x0000		//nIAlrtTh Register
0x18F = 0x0000		//nSAlrtTh Register
0x190 = 0x0000		//nOCVTable0 Register
0x191 = 0x0000		//nOCVTable1 Register
0x192 = 0x0000		//nOCVTable2 Register
0x193 = 0x0000		//nOCVTable3 Register
0x194 = 0x0000		//nOCVTable4 Register
0x195 = 0x0000		//nOCVTable5 Register
0x196 = 0x0000		//nOCVTable6 Register
0x197 = 0x0000		//nOCVTable7 Register
0x198 = 0x0000		//nOCVTable8 Register
0x199 = 0x0000		//nOCVTable9 Register
0x19A = 0x0000		//nOCVTable10 Register
0x19B = 0x0000		//nOCVTable11 Register
0x19C = 0x0100		//nIChgTerm Register
0x19D = 0x0000		//nFilterCfg Register
0x19E = 0x0000		//nVEmpty Register
0x19F = 0x0000		//nLearnCfg Register
0x1A0 = 0x1050		//nQRTable00 Register
0x1A1 = 0x8002		//nQRTable10 Register
0x1A2 = 0x078C		//nQRTable20 Register
0x1A3 = 0x0880		//nQRTable30 Register
0x1A4 = 0x0000		//nCycles Register
0x1A5 = 0x0A6C		//nFullCapNom Register
0x1A6 = 0x08CC		//nRComp0 Register
0x1A7 = 0x223E		//nTempCo Register
0x1A8 = 0x0000		//nBattStatus Register
0x1A9 = 0x08FC		//nFullCapRep Register
0x1AA = 0x0000		//ndQTot Register
0x1AB = 0x0000		//nMaxMinCurr Register
0x1AC = 0x0000		//nMaxMinVolt Register
0x1AD = 0x0000		//nMaxMinTemp Register
0x1AE = 0x0000		//nFaultLog Register
0x1AF = 0x0000		//nTimerH Register
0x1B0 = 0xB695		//nCONFIG Register
0x1B1 = 0x0204		//nRippleCfg Register
0x1B2 = 0x0000		//nMiscCFG Register
0x1B3 = 0x08FC		//nDesignCap Register
0x1B4 = 0x0008		//nSBSCFG Register
0x1B5 = 0x4205		//nPACKCFG Register
0x1B6 = 0x083B		//nRelaxCFG Register
0x1B7 = 0x2241		//nConvgCFG Register
0x1B8 = 0x0AC0		//nNVCFG0 Register
0x1B9 = 0x0102		//nNVCFG1 Register
0x1BA = 0xBE2D		//nNVCFG2 Register
0x1BB = 0x0909		//nHibCFG Register
0x1BC = 0x0000		//nROMID0 Register
0x1BD = 0x0000		//nROMID1 Register
0x1BE = 0x0000		//nROMID2 Register
0x1BF = 0x0000		//nROMID3 Register
0x1C0 = 0x0000		//nChgCtrl1 Register
0x1C1 = 0x0000		//nPReserved1 Register
0x1C2 = 0x2061		//nChgCfg0 Register
0x1C3 = 0x00E1		//nChgCtrl0 Register
0x1C4 = 0x0000		//nRGain Register
0x1C5 = 0x0000		//nPackResistance Register
0x1C6 = 0x0000		//nFullSOCThr Register
0x1C7 = 0x0000		//nTTFCFG Register
0x1C8 = 0x4000		//nCGAIN Register
0x1C9 = 0x0001		//nCGTempCo Register
0x1CA = 0x7135		//nThermCfg Register
0x1CB = 0x0000		//nChgCfg1 Register
0x1CC = 0x0000		//nManfctrName Register
0x1CD = 0x0000		//nManfctrName1 Register
0x1CE = 0x0000		//nManfctrName2 Register
0x1CF = 0x01F4		//nRSense Register
0x1D0 = 0x784F		//nUVPrtTh Register
0x1D1 = 0x3700		//nTPrtTh1 Register
0x1D2 = 0x5528		//nTPrtTh3 Register
0x1D3 = 0x21E7		//nIPrtTh1 Register
0x1D4 = 0x2C60		//nBALTh Register
0x1D5 = 0x2D05		//nTPrtTh2 Register
0x1D6 = 0x2A58		//nProtMiscTh Register
0x1D7 = 0x0D00		//nProtCfg Register
0x1D8 = 0x3243		//nJEITAC Register
0x1D9 = 0xF659		//nJEITAV Register
0x1DA = 0x34D3		//nOVPrtTh Register
0x1DB = 0x61F5		//nStepChg Register
0x1DC = 0xAFB5		//nDelayCfg Register
0x1DD = 0x4F99		//nODSCTh Register
0x1DE = 0x4355		//nODSCCfg Register
0x1DF = 0xAFAB		//nProtCfg2 Register
0x1E0 = 0x0000		//nDPLimit Register
0x1E1 = 0x0000		//nScOcvLim Register
0x1E2 = 0x0000		//nAgeFcCfg Register
0x1E3 = 0xA5B9		//nDesignVoltage Register
0x1E4 = 0x0000		//nVGain Register
0x1E5 = 0x0000		//nRFastVShdn Register
0x1E6 = 0x0000		//nManfctrDate Register
0x1E7 = 0x0000		//nFirstUsed Register
0x1E8 = 0x0000		//nSerialNumber0 Register
0x1E9 = 0x0000		//nSerialNumber1 Register
0x1EA = 0x0000		//nSerialNumber2 Register
0x1EB = 0x0000		//nDeviceName0 Register
0x1EC = 0x0000		//nDeviceName1 Register
0x1ED = 0x0000		//nDeviceName2 Register
0x1EE = 0x0000		//nDeviceName3 Register
0x1EF = 0x0000		//nDeviceName4 Register

1. Regarding the discharging configuration (Step 8/21 in the Wizard); we set an empty voltage of 3V and a UVP of 2.8V. However, when discharging the pack, both the alert and protection kick in at 3V, and the MAX17320 disables the DIS FET, which "kills" the pack output.

2. With regards to cell balancing, we just recently faced a major issue with one of our battery packs, where one of the cells deviated from the others as far as ~200mV. This resulted in the MAX17320 reporting a wrong Time to Empty (TTE) value, and the SOC was stuck at 60% despite the cells' voltages being around 4,2, 4.18 and 4.0V. At the time of typing this, one of the cells (using a different set of Li-Ion batteries) is reporting a spread of ~600mV.

We have monitored the thermals of our custom board, and we have noticed that the balancing resistors get pretty hot (despite using the same value and rating from the EVKit schematic). At some point, one of the resistors (the one attached to BT2 - the "offending" lowest cell) showed some sort of "thermal flickering" or "pulsating" behaviour, which can be evidently related to variations in the current passing through this resistor. I will assume that this is a result of the internal FETs trying to balance the cells; however, there seems to be something wrong with them.

It is important to mention that, at first, we thought that our battery holders could be the issue, since we were using spring-loaded type 18650 battery holders. We assumed that these could potentially introduce some stray resistance between cell nodes. However, we just changed our approach, and we are spot-welding our cells.

3. This very morning, after flashing the shadow RAM with the INI settings, we proceeded to commit these to the NVM (we now have only 5 remaining NVM commits). We attached a fresh set of batteries, and after pressing the "Wakeup" button, the battery would NOT turn on the "pack voltage" at the output terminals. The only way to make it come to life was by keeping the button pressed WHILE plugging in the charger input. This is NOT a very desirable behaviour. Imagine having to tell this to our customers?

4. Similarly, at the time of writing this, my colleague just noticed something VERY wrong with the SOC. Despite the battery pack measuring a voltage of ~12.4V, the SoC reports only 17.2%. Why?! We are also showing all the voltages per cell here. Please note that these images don't show the spot-welded version of the battery pack. We had to temporarily go back to the cell holders to continue our tests

These are the most pressing issues at the moment. We will DEFINITELY come back with more issues since this is still a work in progress.

Thanks for your help in advance

EDIT:

The last picture of the battery cells' voltages is wrong. For some reason, I uploaded one of the pictures showing the wrong voltage. I accidentally took my shot while my colleague was moving the test leads. The last cell voltage was close to the one reported in the serial terminal

The MAX17320 is very good at keep cells balanced.  However, it is HIGHLY recommended that the cells start off well balanced, and the MAX17320 can try to keep them balance.  But if they are starting off with a very large delta, it may be more than the MAX17320 can help with.  What typically will happen is one cell will reach full first and limit how full the pack is charged.  It may also trip the OVP fault if that single cell is too much higher than the rest.  Or a single cell may reach UVP first, and limit how much can be discharged out of the pack before tripping UVP.  

The MAX17320 measures each cell individually for UVP and OVP protection.  The fuel gauge also uses the higher or lower cells when estimating the SOC.  So if there is a big imbalance, this can impact the fuel gauge behavior.

For best results, I would recommend balancing the cells individually before assembling into a pack.

The MAX17320 does require a charge source connection to wake it up the first time the batteries are connected to a pack.

Dear jcole97 

Thanks for your answer.

Here are some very much needed clarifications to your answers.

"The MAX17320 is very good at keep cells balanced."

Unfortunately, we have to strongly disagree with this statement. We are still actively experiencing huge imbalances between cells. We need to clarify that we are effectively using pre-balanced cells (using an external charger) where all cells measure 4.15V +/- 0.05V (More of this later)

"However, it is HIGHLY recommended that the cells start off well balanced, and the MAX17320 can try to keep them balance."

We have been totally aware of this since the beginning of this project. We have now tested 15 well-matched cells (binning the closest ones in terms of voltage and freshly installed after charging finishes), yet we are still facing these issues and triggering all sorts of alerts and protections.

"But if they are starting off with a very large delta, it may be more than the MAX17320 can help with.  What typically will happen is one cell will reach full first and limit how full the pack is charged.  It may also trip the OVP fault if that single cell is too much higher than the rest.  Or a single cell may reach UVP first, and limit how much can be discharged out of the pack before tripping UVP. "

We fully agree with this, and it is (partially) the behaviour that we have observed on several occasions. The main drawback here is that we have to programmatically remove the fault, which complicates the control algorithm on our system. We are dealing with a consumer-grade device, and the end-user should not have to deal with any issues arising from the fuel gauge itself.

"The MAX17320 measures each cell individually for UVP and OVP protection.  The fuel gauge also uses the higher or lower cells when estimating the SOC.  So if there is a big imbalance, this can impact the fuel gauge behavior."

While this statement makes a lot of sense "on paper", it is far from reality. We have provided evidence in our last response where the SOC was reported at 17.2% while the worst-case cell was merely at 4.095V. There is no way that this makes any mathematical sense.

"For best results, I would recommend balancing the cells individually before assembling into a pack."

While this is totally understandable, we ARE indeed assembling packs with well-balanced batteries (as mentioned before). However, once we cycle the battery pack with any load, the cells start spreading apart.

For instance, here is a clear example of what I am trying to explain (part of it, at least). We observed this imbalance WHILE charging a freshly pre-charged pack (all cells to 4.16V +/-0.05V). Cell 2 suddenly started deviating from the rest of them. We first discharged them for a while, reaching 9V per pack (approx. 3.15V/ per after bouncing back with a worse deviation of 300mV - unnaceptable but we carried on)

Regardless of the observed imbalance, we continued charging this same pack. One of our cells reached 4.26V (!!) and, evidently, OVP got triggered.

This cannot be any clearer.

What is the point of setting a charging voltage to 4.15V (at room temperature - we are at 26C here in the shop), an OVP at 4.28V and an OVP release at 4.26V in step 5 if the MAX17320 will not try to keep the cells at such levels? It seems to us as if the MAX17320 was simply ignoring the settings it has in the NVM.

Please note that our PCB is basically a "carbon copy" of the Evaluation board provided for this chip, and thus, we are using the same values and ratings from the provided BOM.

"The MAX17320 does require a charge source connection to wake it up the first time the batteries are connected to a pack."

Based on the hardware we have on the bench (two custom MAX17320 boards), this is not entirely true. One of the boards showed the behaviour that you describe here (as we did before, where we had to connect the charger WHILE pressing the wakeup button). On the other hand, we did NOT need to do this with the second board. Attaching a pack and pressing the wakeup button was enough to wake it up. Both systems are running the same NVM configuration from the same INI file we shared before.

We are exploring all possibilities to get this system up and running as intended. We have invested time, effort and quite a lot of money in prototyping these systems. We want to extinguish all chances of changing our design and delve into a different chip. If we do not see any other option, we will have to migrate our design to a TI chip or similar. Our system will invariably hit the market in the thousands of units per month, and we originally thought that the MAX17320 was our best bet.

We are now questioning our choices.

Dear jcole97 

Thanks for your answer.

Here are some very much needed clarifications to your answers.

"The MAX17320 is very good at keep cells balanced."

Unfortunately, we have to strongly disagree with this statement. We are still actively experiencing huge imbalances between cells. We need to clarify that we are effectively using pre-balanced cells (using an external charger) where all cells measure 4.15V +/- 0.05V (More of this later)

"However, it is HIGHLY recommended that the cells start off well balanced, and the MAX17320 can try to keep them balance."

We have been totally aware of this since the beginning of this project. We have now tested 15 well-matched cells (binning the closest ones in terms of voltage and freshly installed after charging finishes), yet we are still facing these issues and triggering all sorts of alerts and protections.

"But if they are starting off with a very large delta, it may be more than the MAX17320 can help with.  What typically will happen is one cell will reach full first and limit how full the pack is charged.  It may also trip the OVP fault if that single cell is too much higher than the rest.  Or a single cell may reach UVP first, and limit how much can be discharged out of the pack before tripping UVP. "

We fully agree with this, and it is (partially) the behaviour that we have observed on several occasions. The main drawback here is that we have to programmatically remove the fault, which complicates the control algorithm on our system. We are dealing with a consumer-grade device, and the end-user should not have to deal with any issues arising from the fuel gauge itself.

"The MAX17320 measures each cell individually for UVP and OVP protection.  The fuel gauge also uses the higher or lower cells when estimating the SOC.  So if there is a big imbalance, this can impact the fuel gauge behavior."

While this statement makes a lot of sense "on paper", it is far from reality. We have provided evidence in our last response where the SOC was reported at 17.2% while the worst-case cell was merely at 4.095V. There is no way that this makes any mathematical sense.

"For best results, I would recommend balancing the cells individually before assembling into a pack."

While this is totally understandable, we ARE indeed assembling packs with well-balanced batteries (as mentioned before). However, once we cycle the battery pack with any load, the cells start spreading apart.

For instance, here is a clear example of what I am trying to explain (part of it, at least). We observed this imbalance WHILE charging a freshly pre-charged pack (all cells to 4.16V +/-0.05V). Cell 2 suddenly started deviating from the rest of them. We first discharged them for a while, reaching 9V per pack (approx. 3.15V/ per after bouncing back with a worse deviation of 300mV - unnaceptable but we carried on)

Regardless of the observed imbalance, we continued charging this same pack. One of our cells reached 4.26V (!!) and, evidently, OVP got triggered.

This cannot be any clearer.

What is the point of setting a charging voltage to 4.15V (at room temperature - we are at 26C here in the shop), an OVP at 4.28V and an OVP release at 4.26V in step 5 if the MAX17320 will not try to keep the cells at such levels? It seems to us as if the MAX17320 was simply ignoring the settings it has in the NVM.

Please note that our PCB is basically a "carbon copy" of the Evaluation board provided for this chip, and thus, we are using the same values and ratings from the provided BOM.

"The MAX17320 does require a charge source connection to wake it up the first time the batteries are connected to a pack."

Based on the hardware we have on the bench (two custom MAX17320 boards), this is not entirely true. One of the boards showed the behaviour that you describe here (as we did before, where we had to connect the charger WHILE pressing the wakeup button). On the other hand, we did NOT need to do this with the second board. Attaching a pack and pressing the wakeup button was enough to wake it up. Both systems are running the same NVM configuration from the same INI file we shared before.

We are exploring all possibilities to get this system up and running as intended. We have invested time, effort and quite a lot of money in prototyping these systems. We want to extinguish all chances of changing our design and delve into a different chip. If we do not see any other option, we will have to migrate our design to a TI chip or similar. Our system will invariably hit the market in the thousands of units per month, and we originally thought that the MAX17320 was our best bet.

We are now questioning our choices.

I think this may be getting much more in depth that we can continue on the EngineerZone page.  The best course of action here is to redirect you to the Select Support Type  · Support Portal to open a support ticket and get connected to someone on our Central Apps Team to continue this discussion.

We thought that we were already dealing with Technical Support. Oh, well...

So, open a ticket and start over again. Very nice.

We need to get to the bottom of this. 

I stand by my initial claims. Maxim/ADI are leaving us customers alone in the dark.

In any case, thanks for your help, jcole97 

Hi dmelendrez