Dear Sirs,
In trying to evaluate this product, which is intended for a low cost 12V lithium battery for small rural home storage system, I am being frustrated by the presentation of information in the Data sheet.
In going through the documentation, so far I have found a (number of) conflicts in what a register is supposed to be e.g.:
00Fh MixCap/MiscCfg?
1FDh NV Ram update count /History Page Flags?
Also, so far I have a number of address ranges that are not documented:
171h -17Fh, 169h – 16Dh, 150h -166h, 140h – 14Bh
Other than that, It would also be nice to have this device in a somewhat larger package – as an option. I’m finding it quite difficult to solder these using hand placement and hot air.
I would also like to stop the device going to sleep if there is no active communication - The device in my application needs to be autonomous - with push button wake-up, but not return to sleep mode unless the battery voltage goes low. Is this possible by clearing the EnHib bit in nHibCfg register?
There is also missing information relating to timers:-
nDelayCfg Register (1DCh)
Factory Default Value: AB3Dh
Set nDelayCfg to configure debounce timers for various protection faults. A fault state is concluded only if the condition
persists throughout the duration of the timer.
Table 30. nDelayCfg (1DCh) Format
all of the timers in this register have a given range eg 2.8 to 5.625s (for UVP Timer) BUT NO REFERENCE is made to what sets this range....
Page 120: AtAvSOC Register (0CEh) should read 0DEh.
I2c Address: For programming the IC address space is actually 0bh and 36h, i.e. the addresses are shifted 1 place to the left or right depending which way you look at this. The read/write bit is not normally included in the address.
debian@beaglebone:/var/lib/cloud9$ i2cdetect -y -r 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- 0b -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- 36 -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
I've also discovered a peculiarity whilst charging: The CHARGE FET Turns OFF, and the recommended charging amps immediately goes to zero!!.
Now I have a second device under test, this is also exhibiting strange charging behaviour.
The status register is reading back 0x8000 (PA flag set)
The Protection status register (0d9h) is alternating between 0x0000 and 0x0200 (Q overflow flag set / Clear approx 1 second cycle)
The ProtAlrt register (0AFh) is set to 0x0200 - Q overflow flag set.
The charge current is pulsing every second as the charge fet is cycled with the Q overflow flag.
Qh and Ql (04d/04e) are 0x0066 and Ql counting rapidly.
Why should this be happening, when the Qh register is non zero, and not overflowing?
Is there a way to disable the Q overflow feature? Some reference is made in the text to the possibility of disabling this, but I can't find any direct reference (again).
Updated charging fault.
[edited by: MikeD2 at 8:57 PM (GMT -5) on 6 Feb 2023]
