BQ27421-G1 configuration Issue

FWIW, I just got done writing code for this particular gauge.  I followed the directions to the letter in the TRM and had no luck getting it to work using the method that's published.  Here's what I wound up doing that works reliably:

-Don't use the method that they outline for recalculating the checksum.  I didn't formally check, but I think there are other parameters in memory that can change when adjusting certain other parameters.  Instead of using the method outlined in the TRM, I have a routine that reads all of the registers in the range and then I use that to calculate the checksum.  I found that if I tried to write the wrong checksum to the checksum register, the gauge does not respond.  Once you have the correct checksum, the gauge will acknowledge the write.

-I also found that I had to wait about 5 seconds between operations when writing to different parts of the memory.  I think the data sheet states that you have to wait at least two seconds, but the operations were only reliable when I used 5 seconds or above.

Jake

Hi Jake,

Thanks for pointing out the problems you had with the TRM.  Did you also check the flow charts in the Quick Start Guide for the bq27421?  I wonder how different those are from what you had to implement.

By the way, one of our engineers has updated a linux version of the driver that can initialize the configuration data memory (DM) of ROM based gauges (like bq27421). It's uploaded here:

https://github.com/aneeshv/linux-bq27xxx

Instructions for cloning:

git clone https://github.com/aneeshv/linux-bq27xxx.git

branch: bq274xx-dm-init

What it does:

In addition to the regular reporting functions (Voltage(), Current(), SOC() etc.) this driver has APIs for reading and writing the DM of the gauge. These APIs are in turn used for initializing the DM of ROM based gauges.

The initialization happens at startup(about ~65s into the the startup) After startup we poll the status of ITPOR every 6 minutes and repeat the DM initialization if it’s set. The polling happens along with the polling of other parameters such as Current(), SOC() etc and the period for this polling loop is customizable.

The registers to initialized in the DM may be specified in the code in an array like this:

static struct dm_reg bq274xx_dm_regs[] = {  {82, 0, 2, 1000}, /* Qmax */  {82, 5, 1, 0x81}, /* Load Select */  {82, 10, 2, 1340}, /* Design Capacity */  {82, 12, 2, 3700}, /* Design Energy */  {82, 16, 2, 3250}, /* Terminate Voltage */  {82, 27, 2, 110}, /* Taper rate */ };

What it doesn’t:

It doesn’t have a mechanism to save and restore Ra values and Qmax as suggested in the Quick Start Guide.  This would have to be written at the application level.

Hi,

Thank your for your answers.

I agry with Jake, the TRM is not really complete.

I solved partially my problem.

I had to way 5 ms between each action. If I don't do this, the behaviour of the chip is quiet strange. (example: I don't read the right register)

The linux sources confirmed this wait of 5 ms.

Then I do a soft reset after each parameter. (it takes 1 second).

And after I write the next one.

Unlike Jake, I use the method in the TRM to calculate the checksum and it seems to work well.

The problem that I'm facing now, is that sometimes, it doesn't work.

The initialisation could works well and sudently, it fails.

It always fails on a checksum problem. I checked the routine that I'm using and I didn't see the problem.

Can anyone can give me the code that he use to calculate checksum.

I'm on a PIC so it possible in C.

I don't know why it happens and what to do in this case.

I maybe should wait 5 secondes between each parameter but in this case the initialisation will take a long long time (I'm writting 21 parameters).

It will be the same problem is I read all the block each time.

An other question is:

If I write those 21 parameters once, If the chip is switch off (no power at all), do I need to re-write the parameters or not?

Thank you for your help.

Regards

Hi Guillaume,

I have also used the method of calculating the checksum from the TRM, but sometimes it failed. But it is not the calculation that fails, it is writing/reading of the new checksum.

I think the reason for that is that you have to wait a long time, from writing the new checksum, until you can actually read it back. I am waiting 1 second. This is not very clear in TRM or datasheet.

Best regards,

Frank Andersen

Hello All,

I am having a similar problem with the B version of the device.   I can update the opConfig value successfully but when I go to write the Battery parameters following Figure 1 flow chart in the quickstart guide I get a nack from the i2C write of the checksum byte. Like above I am wondering if I am calculating the checksum correctly.  The quick start shows TMP_CHKSUM being updated but it is unclear if this is a byte by byte or word by word operation with the resulting low order byte being used as the written checksum.    

Also I have tried adding waits as described in this and other threads but with no success.

Is there any further insight into how the checksum should be calculated?

Also what is the checksum for the Subclass 82 (State) block.  I am reading 0x00 as the default/old- is this correct?

Thanks, Andrew

ps I am using an ARM based micro and not the EVM and these are the IC parameters I read from the device

Dev Type:_________ 0x0421
FW Ver:___________ 0x0108
Chem ID:__________ 0x0312

Hello All,

Well I think I have resolved my issue.  I have discovered that when accessing Subclass 82 (and I assume others), the data is not immediately stable (checksum or other value reads 0).   If I add a 1ms  delay after "I2CWriteByte(0x3F, 0x00, 100)"  as shown in the "steps to setup block Ram update" of  fig 1 of the quick start guide,  the data becomes stable.  I cannot find this documented anywhere and so I would ask the TI people supporting the device to comment on whether 1ms is acceptable delay for all subclasses or if a longer delay is needed as I suspect that it will vary by subclass (based on my experience that Subclass 64 did not need a delay).

Thanks, Andrew

Hello Frank,

Should not the wait be at least 2 seconds according to the datasheet (page 14).?

What I did was to wait 4 seconds between writing and reading the checksum and it is working. The weird thing is that the first try it does not work. It is always on the second try that I get the same checksum that I wrote. Does someone know if this is reasonable?

Update: I tried with 10 miliseconds instead of 4 seconds as it is working well...