Heavily discharged battery returning bad diagnostic data

[MarvinOl]

Using original FT232R as far as I can tell.

I get strange response from the battery:

>>> m.health()
Reading battery. This will take 5-10sec

Type: 40 [5Ah XC (5s2p 18650)]
E-serial: 8862340 (does NOT match case serial)
Manufacture date: 2017-03-13
Days since 1st charge: 0
Days since last tool use: -32472
Days since last charge: 0
Pack voltage: 19.881
Cell Voltages (mV): [3983, 3876, 4004, 4004, 4014]
Cell Imbalance (mV): 138
Temperature (deg C): 25.17

CHARGING STATS:
Charge count [Redlink, dumb, (total)]: 65535, 65535, (4294967295)
Total charge time: 1193046:28:15
Time idling on charger: 1193046:28:15
Low-voltage charges (any cell <2.5V): 65535

TOOL USE STATS:
Total discharge (Ah): 1193046.47
Total discharge cycles: 238609.29
Times discharged to empty: 65535
Times overheated: 65535
Overcurrent events: 65535
Low-voltage events: 65535
Low-voltage bounce/stutter: 65535
Total time on tool (>10A): 15 days, 4:05:00
Time @   10-20A: 18:12:15  5% XXXXX
Time @   20-30A: 18:12:15  5% XXXXX
Time @   30-40A: 18:12:15  5% XXXXX
Time @   40-50A: 18:12:15  5% XXXXX
Time @   50-60A: 18:12:15  5% XXXXX
Time @   60-70A: 18:12:15  5% XXXXX
Time @   70-80A: 18:12:15  5% XXXXX
Time @   80-90A: 18:12:15  5% XXXXX
Time @  90-100A: 18:12:15  5% XXXXX
Time @ 100-110A: 18:12:15  5% XXXXX
Time @ 110-120A: 18:12:15  5% XXXXX
Time @ 120-130A: 18:12:15  5% XXXXX
Time @ 130-140A: 18:12:15  5% XXXXX
Time @ 140-150A: 18:12:15  5% XXXXX
Time @ 150-160A: 18:12:15  5% XXXXX
Time @ 160-170A: 18:12:15  5% XXXXX
Time @ 170-180A: 18:12:15  5% XXXXX
Time @ 180-190A: 18:12:15  5% XXXXX
Time @ 190-200A: 18:12:15  5% XXXXX
Time @   > 200A: 18:12:15  5% XXXXX

>>> m.read_all()
Response from: 0x0000: 00 05
Response from: 0x0002: 00 00
Response from: 0x0004: 00 28 87 3A 84
Response from: 0x000D: 01 09 11 03
Response from: 0x0011: 58 C6 53 80
Invalid response from: 0x0015 Response: 82 04
Invalid response from: 0x0019 Response: 82 04
Response from: 0x0023: 55 6E 64 65 66 69 6E 65 64 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D
Response from: 0x0037: 58 C6 FF 07
Response from: 0x0069: 00 02
Response from: 0x007B: 00
Invalid response from: 0x4000 Response: 82 04
Response from: 0x400A: 0F 8F 0F 24 0F A4 0F A4 0F A9
Response from: 0x4014: 02 A0
Invalid response from: 0x4016 Response: 82 04
Invalid response from: 0x4019 Response: 82 04
Invalid response from: 0x401B Response: 82 04
Invalid response from: 0x401D Response: 82 04
Invalid response from: 0x401F Response: 82 04
Invalid response from: 0x6000 Response: 82 04
Invalid response from: 0x6002 Response: 82 04
Invalid response from: 0x6004 Response: 82 04
Invalid response from: 0x6008 Response: 82 04
Invalid response from: 0x600C Response: 82 04
Response from: 0x9000: AA 45 02 00 FF FF FF FF 58 C6 53 80 FF FF FF FF 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Response from: 0x903A: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Response from: 0x9074: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Response from: 0x90AE: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Response from: 0x90E8: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Response from: 0x9122: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Response from: 0x9152:
Response from: 0xA000: FF FF FF FF FF FF

And this is repeatable, always the same output for the first invalid response etc.

I tried playing with the baudrate, got the exact same output for m.read_all() with 2400 and 1200 bauds (just much slower), so I don't think it's a speed issue.

I can successfully pretend to be a charger:

>>> m.simulate_for(3)
Simulating charger communication for 3 seconds...
Duration:  3.363016366958618
>>>

On the battery the lights turn on during that command.

m.reset works:

>>> m.reset()
True

Voltages:
m.idle():
J1=0.936V
J2=0.285V

m.high():
J1=3.265V
J2=13.77V

TTL shifter built using BS170 with 10k pullups.
OS debian.

[MarvinOl]

Additional note - the manufacture date matches the date on the bottom of the case and the reported cell voltages/pack voltage are correct.

That's what makes it even more strange, 2 way communication seems to be working for some time and then something goes wrong.

[Tool-Scientist]

I think everything is working, it's just that your diagnostics are borked. Nearly everything in the 0x9000 block is at max value. Could be that it wasn't initialised properly at the factory, or some glitch happened afterwards.

It's a shame that it's a 2017 battery, so it prob doesn't have flash codes that we could compare

[Tool-Scientist]

I'm thinking your clock is broken or battery wasn't initialised.

Your current date (0x0037) and date of last charge (0x9008) are the same as date of manufacture (13 March 2017). Your date of first charge (0x9000) is 10 Jul 2060 (!)

Use read_id() and save the output. Do it again a few minutes later and I suspect the 'current time' register (id 8) will still be the same.

[MarvinOl]

The battery seems to count time:
8 0x0037 4 date Current date 2017-03-14 06:07:56
24 0x9000 4 date Date of first charge (rounded) 2060-07-10 01:40:16
25 0x9004 4 date Date of last tool use (rounded) 2106-02-07 06:28:15
26 0x9008 4 date Date of last charge (rounded) 2017-03-13 08:08:32
27 0x900C 4 date Unknown date (often zero) 2106-02-07 06:28:15

A few minutes later:
8 0x0037 4 date Current date 2017-03-14 06:10:20
24 0x9000 4 date Date of first charge (rounded) 2060-07-10 01:40:16
25 0x9004 4 date Date of last tool use (rounded) 2106-02-07 06:28:15
26 0x9008 4 date Date of last charge (rounded) 2017-03-13 08:08:32
27 0x900C 4 date Unknown date (often zero) 2106-02-07 06:28:15

And with read_id() it is the same, most of the information is 65535.

Background information: I received the battery almost fully discharged, total voltage only about 2V (not per cell but the total battery, heavily discharged), I revived it by charging the cells one by one and got it to match pretty nicely:
12 0x400A 10 cell_v Cell voltages (mV) 1: 4002, 2: 4023, 3: 4009, 4: 4008, 5: 4019

Could it be that something was stored in volatile memory and with a total discharge that was lost?

As I revived the battery yesterday it seems that the time counter at least started to run from the manufacturing date:
4 0x0011 4 date Manufacture date 2017-03-13 08:08:32

So what next... I tried shorting pin 2 and 4 on HD1 to reset the chip but it does not change anything.

[Tool-Scientist]

Some of the diagnostics seem to be in volatile memory, and others in non-volatile. I think this is why some of the values don't update until after they are read. Maybe as the MCU is shutting down from power loss, it scrambles the diagnostics to indicate that failure. Seems dumb as they could just scramble/set/clear one piece of data to indicate power loss.

@mnh-jansson did mention once that he had to reset his boards occasionally. He is using removed PCBs powered by a resistor network. He may have a better reset procedure.