Repairing a 5-cell Li-ion battery: dead 21700 cells replaced, but BMS still reporting error when charging

Question

I have been given a small portable vacuum cleaner with a faulty battery. The battery is an 18 V, 5-cell 21700 unit with a large BMS board on top. One cell wasn't reporting voltage so I replaced it with a brand new cell of the same spec (Samsung INR2700).

When placed back in its original charger it is still detected as faulty. Is there anything else I need to do to reset this battery so that it will charge once more?

I have found a 3.3 V header on the BMS with pins SWCLK/SWD0/GND/3.3 V/RESET pictured below. Do I just need to bridge the reset to ground?

Further investigation reveals a labelled UART 3 pin header which I will try hooking up.

Just hooked up the 3 pin serial. 115200/8/n/1 left to right GND-TX-RX and I get output via gtkterm as follows:

main - line: 00051:  mcu reset...
nvram_if - line: 00172:  calbriated_flag = 1 
nvram_if - line: 00269:  sys_record,fault:0x80,inc_soc:88739 
nvram_if - line: 00330:  bms_mode:87654321,bms_mode_size:4 
state_poweron - line: 00025:  state_initialising_entry.
state_poweron - line: 00059:  permanent defect exist :0x80.
main - line: 00077:  compile time: Dec 14 2018,  09:15:26
main - line: 00079:  software version: 01.16.0001.2018.12,13
main - line: 00083:  PCBA_PN:280796003
main - line: 00085:  sizeof test: sys_defect_t=2,cell_new_old_t=1maistate_poweron - line: 00085:  state_initialising_exit.
state_defective - line: 00033:  state_deftaskey pressed,stmach state:4
task_led - line: 00423:  update led style:5
task_debug - line: 00032:  calibration flag : 1
task_debug - line: 00034:  defect: 0080
task_debug - line: 00036:  sys state: 4 
task_debug - line: 00038:  led.style: 5
task_debug - line: 00040:  nv_life:88739 
task_debug - line: 00042:  bms_soc:0
task_led - line: 00423:  update led style:0
state_defective - line: 00076:  state_defective_exit. 
state_poweroff - line: 00025:  state_power_down_entry.
system_timing - line: 00093:  task delay warning,id:1 
state_poweroff - line: 00049:  pwr_off_#1.
task_debug - line: 00047:  cells volt(mV): 0, 0, 0, 0, 0
task_debug - line: 00051:  cell sum(mV): 0
task_debug - line: 00053:  pack volt shunt(mV): 0
task_debug - line: 00055:  pack volt(mV): 65535

added closeup of main IC

Answer 1

I can't comment since I don't have enough rep but that microcontroller looks like it could be an NXP LPC824M201JHI33 or similar variant of LPC824. The NXP logo is written sideways in your photo. :)

As someone else noted, the serial log shows it has recorded a permanent fault in the nvram.

I'm not familiar with that specific MCU but on PICs you can read and edit the EEPROM without touching the flash. Maybe if you are really lucky you could dump the entire firmware if they haven't locked it. (Unlikely)

No matter what, I think you'd have to find a way to clear that nvram recorded defect.

Answer 2

If one cell was completely at 0 V, it's an indication that, during use, its voltage actually became negative, as it was being charged in the reverse direction by current from the other cells. If so: 1) That BMS is not effective: it should have turned off the battery before that occurred; and 2) The negative voltage would have damaged that particular input on the BMS. Regardless, you have a bad BMS.

Alternatively, it's possible that the BMS was damaged first, and it drained that one cell. If so, again, you have a bad BMS.

The last possibility is that the cell was bad, and it self-discharged to 0 V. While that was a noticeable possibility 10 years ago, nowadays that is extremely unlikely, as the manufacture and quality control of Li-ion cells has improved dramatically. The fact that the BMS still doesn't work with the new cell indicates that the cell was not the problem.

It must be said, though, that some BMSs are booby trapped by design to not start up again when a cell is replaced.

Answer 3

Having a 5-serial BMS, it will control the individual voltages at all 5 cell. When the voltage differences are too high the BMS will report an error. I assume the newly inserted battery will be not pre-charged in such a way that it matches the others charge-level.

If the BMS is a balanced one, maybe waiting helps if the difference are not too high.

I would charge all 5 cell outside of the vacuum cleaner with a lap-bench power supply to not more than 80% of the nominal voltage and constantly monitor the process because now the cells are unprotected.

Answer 4

Unfortunately it sounds like the old 'elf and safety' situation. Li-ion batteries store a lot of energy and no manufacturer wants a lawsuit involving their product. I assume this manufacturer has designed the BMS to constantly monitor each cell during charge/discharge and incorporate a 'trip' in the software to ensure it fails safe. Changing cells won't, (and shouldn't) reset the trip as there may still be a safety issue somewhere with that battery and you, as a repairer could be liable if anything blows up! Most manufacturers provide new replacement batteries in the first twelve months and you just have to hope the battery reliability improves or the price comes down as more are manufactured. Putting group pressure on the original manufacturer would be the most effective way of doing this.

Answer 5

I have a similar issue with a pack here, so spent a day trying to see if I could fix it, I've learnt a bit but I think it's now completely dead due to trying to fix the lack of calibration error. Essentially, you need a debugger which you can attach to the SWD header pins (SWCLK, SWDIO, ground) then read the code out for the LPC824. In the hex file, you'll see the code, you'll also see some strings which seem to indicate that the UART should be able to accept data somehow but I wasn't able to work out how. Right at the bottom is a lot of empty space (0xff) then a few bits of data - this is the "nvram" which the debug out mentions. I was able to clear the error by screwing with the last line of data (on mine I had 3 lines). This got rid of the defect error - great you're probably thinking, but not great, because then it boots but gives a calibration data error because of a checksum failure. I didn't try charging it at this point, did try shorting the calibration pins on the board out but it didn't seem to do anything, even after a reset. I managed to mess up at this point seemingly by one of the wires shorting out I think, as the battery pack now appears completely dead and I can't establish any communication with the MCU on the board, so a nice big shoutout to vax for creating a lousy bunch of ewaste. If you need another hex file to compare to (maybe you can work out what the checksum is or what the data bytes are) just say and I can upload it.

Answer 6

Other people have already mentioned some potential issues, in particular the fact that the BMS has stored some failure state in NVRAM and needs resetting, or it has already "bricked" itself because of its fault (be it for safety reasons or for planned obsolescence).

I'll add another, safety-related, possibility. Although the BMS is designed to balance the 5 cells independently, it could still compare the performance of the cells and if some cells behave in a wildly different way, then consider it a fault.

In other words, it may be that you need to replace all the cells and not only the faulty one. In general this is a sound practice because if a cell failed because it reached its end of life then it is likely that also the other cells (if they are from the same batch, as they should) are dying.

So a sensible BMS strategy is to detect that some cells charge in a different way than the others and if big difference are found then block the whole thing. In fact, even if the BMS wasn't programmed to avoid cells substitution, it could have been programmed to ensure that all the cells are more or less in the same health conditions.

In fact in many applications where the BMS is integral part of the battery pack the circuit is designed to compensate for differences in manufacturing for single cells of the same batch, not to provide balancing between new and old cells.

Therefore such a BMS could not be able to balance the cells if their health status is wildly different and a BMS able to do this would be more expensive because the circuit and the algorithm would have to "mix and match" cells that intrinsically cannot be easily balanced (if a cell is much older than the others, it could never achieve the same capacity; this means that for keeping the balance the newer ones won't be charged fully, at least with some simpler balancing strategies).

And this is a sound repair strategy in general: if a cell has failed not due to some random defect, but because it reached end of life, it could well be that the other ones are going to fail soon anyway.

Moreover if a single cell is defective, the manufacturer can replace it during warranty period, whereas if it is end of life and the user requests a replacement (assuming the service is available) most probably it is more economically viable for the manufacturer to replace the whole pack (the work needed for replacing a single cell could well cost more than a single new pack and you don't risk the user coming after you in a month because another cell in the pack failed and the repair is still under warranty).