2

I've been trying to create a new battery pack for an old (and long discontinued) Sony product. Luckily the battery pack in question uses standard smart battery specification. So I've designed a new PCB and instead of using the old fuel gauge/protector combo I've gone and used modern Maxim MAX17320 fuel gauge/protector IC. And here is where I am having some trouble...

Upon connecting a 2 cell RC battery to it (for testing purposes) and shorting the discharge/charge pin to the battery positive terminal (to wake the IC up) the IC starts communicating with the MAX17320 programming software. Problem is that immediately upon doing so it goes into permanent failure. The below two screenshots:

Fresh battery 1

Fresh battery 2

Upon clearing the PermFail flag the FET failure indicators turn green and the pack starts working. My initial thought was that this was due to the parameters being wrong so I went through configuration (hopefully setting up everything correctly) and writing the configuration to RAM. But again upon doing so and rebooting the IC goes into PermFail mode...

Configured battery 1

Configured battery 2

Since clearing the fault works - the battery behaves as expected based on a short test in the actual product - I tried to write the working configuration into non volatile memory. But I can't do so because the software complains that I need to fix the permanent failure first. Any ideas on what I am doing wrong? Why is it going into pfail in the first place?

Some additional info: I am not using any permanent protections on the PCB - so I have the PFAIL output connected to ground with 1k resistor as described in the datasheet. When going through the programming wizard I also disabled permanent failure protection and unchecked the option for disabling programming in case of permanent failure. But that doesn't seem to do anything.

EDIT: Schematic for my board is here... it's mostly based on the evaluation board:

Board schematic

Link to datasheet: https://datasheets.maximintegrated.com/en/ds/MAX17320.pdf

roli
  • 149
  • 4
  • Link to datasheet? Schematics? – Null Dec 22 '21 at 15:22
  • Some schematics would be helpful... – citizen Dec 22 '21 at 15:28
  • Page 50 of the Datasheet mentions a few reasons for which the Permanent Failure flags are raised. Do any of them possibly apply to your situation ? – citizen Dec 22 '21 at 15:36
  • DIS FET Shorted: If discharging is detected during discharge fault, nBattStatus.DFETFs is set and written to NVM. • CHG FET Shorted: If charging is detected during charge fault, nBattStatus.CFETFs is set and written to NVM. – citizen Dec 22 '21 at 15:37
  • Also you show that the "TooColdC - Undertemperature for charging" flag is raised on at least one occasion ? Can you dispel any of these situations ? – citizen Dec 22 '21 at 15:42
  • @citizen The TooColdC is because when initially started (without programming) the board assumes a different thermistor. After storing the data into RAM that error disappears and the temperature read is correct. As for other errors... seeing how the board works normally after the flag is cleared I don't think it's anything wrong with FETs. – roli Dec 22 '21 at 18:13
  • It may be that you have a brief current surge that raises the FET flags. It may be worth looking with a scope at the FET drivers to confirm they are being switched off, or whatever may be happening during the time you have the Permanent Failure flags raised... – citizen Dec 23 '21 at 09:15
  • @citizen I tried scoping out gate pins for both the FETs and the Q1 seems a bit weird. When powering on the module (and it goes into fault mode) the gate pin is at about 7V (meanwhile the Q2 gate pin is at around 500mV). When clearing the fault both gate voltages rise to around 14V. I don't really have a good understanding of how this is supposed to work, but those 7V in permanent fault mode seem wrong. – roli Dec 23 '21 at 15:30
  • Hmm yes ... You may want to cut/disconnect the track to the 7V gate MOSFET (and turn this MOSFET on permanently) and see if this removes this odd behaviour by checking the scope on the gate drive if it continues doing the same thing ... – citizen Dec 23 '21 at 15:45
  • @citizen So I removed the R8 resistor (the fastest way to disconnect the chip from the gate) and measured the chip side of it... it was at 8V. So, yes. Same behavior. Similarly the chip also went into permanent fault mode. – roli Dec 23 '21 at 16:30
  • I guess you may want to contact Maxim and ask if this is normal behaviour, and if it isn't it may be a damaged chip that you have, or otherwise they may suggest if this is normal and expected etc ... let us know of your outcome, hope this helps ... – citizen Dec 24 '21 at 13:03

2 Answers2

2

I've found the problem - it seems to be with the configuration wizard for the chip itself. Upon further investigation the programming .ini file that it produces contains this line:

0x1A8 = 0x8000 //nBattStatus Register

If we look at the bit that is set by this (bit 15) that bit is actually permFail bit. So basically the board would be programmed with the permFail bit set already. Changing the value of this register to 0 has cleared the issue. I'll be contacting Maxim to let them know about the error and to see if they have any other solutions - but generally the values that you select in the configuration wizard quite often seem to be ignored.

roli
  • 149
  • 4
  • Well even better !! that's a definite solution if you have confirmed the cause. Let them know I'm sure it was a simple oversight ... thanks for sharing the solution ... – citizen Jan 04 '22 at 10:47
0

Check the thermistor for cell2. Its temperature is showing zero degrees. That is probably why you are getting the perm fail.

VictorTito
  • 400
  • 1
  • 4
  • I don't have two thermistors. When going through setup I set it to only use one thermistor as well. – roli Dec 22 '21 at 18:11