BQ27621-G1: Read Checksum fails randomly

bhargav kinnal

Part Number: BQ27621-G1
Other Parts Discussed in Thread: BQSTUDIO, EV2400

In the application, design capacity, along with other battery parameters are updated during the system initialization.

Application note in TRM section 3.1 is followed.

Unseal--> Enter CFG mode --> Enter Block mode --> Read Checksum --> Recalculate checksum --> Write parameters and checksum --> Soft reset --> Seal Device.

It works most of the times. But when the device is shutdown unexpectedly like reset from debugger/ pulled into deep sleep mode due to some system changes. The read checksum stage fails when the device resets and re initializes. Read checksum returns nothing and no acknowledgement is received. While any other command, like reading DEVICE TYPE, etc still work but only read checksum fails.

I tried,

1. adding delays in between stages to ensure I give enough time for the response

2. retried several times before logging failure

It is good to know that when the my uC is sleeping (Deep sleep mode in Atmel) I hibernate the Fuel gauge instead of shutting it down.

This issue could my application specific logic, however I want to know what are the conditions when the Read checksum could fail? even after retries. Since the issue occurs randomly and more probably when there is an unexpected reset, I guess my fuel gauge is not in right state?

Thanks in advance

over 4 years ago

0 Andy Liu (BMS) over 4 years ago

TI__Guru 52115 points

We will take a look and get back to you.

0 bhargav kinnal over 4 years ago in reply to Andy Liu (BMS)

Prodigy 70 points

I can reproduce the issue with more probability when I reset the device with my debugger. After such a reset, the Checksum read fails more often.

0 Dominik Hartl11 over 4 years ago in reply to bhargav kinnal

TI__Guru 51346 points

Please make sure that both the subclass (0x3E) and block (0x3F) information are written right before you read the check-sum. After a reset (e.g. reset between writing 0x3E/3F), this may not be initialized to valid subclass/block if you read the check-sum.

0 bhargav kinnal over 4 years ago in reply to Dominik Hartl11

Prodigy 70 points

This is made sure by checks in the application code. The checksum read always follows these write (any reset would still trigger the writes before checksum read).

In Subclass (0x3E) data 0x52 is written and for Block (0x3F) data 0x0 is written. Is this correct?

0 Dominik Hartl11 over 4 years ago in reply to bhargav kinnal

TI__Guru 51346 points

This is correct. I don't have a good answer why this would fail then. I checked the gauge FW and the gauge simply calculates the check-sum for the subclass/block that was written to 0x3E/0x3F and returns this. It's straight-forward code without any paths that would explain what you observe. If you can read other data (like device ID) then I don't see a reason why the check-sum read command wouldn't work.

I would analyze the actual waveforms on SCL/SDA and make sure that all timing requirements are truly met. Maybe something is marginal.

0 bhargav kinnal over 4 years ago in reply to bhargav kinnal

Prodigy 70 points

UPDATE:

When the issue occurs, it persists till I physically plug the battery out (Thats when the Fuel gauge actually resets)

Also when the issue occurs the device fails to go into config update mode ( So the issue occurs well before checksum read which I was overlooking).

This is checked by looking for bit 4 in flags. Its is never set, even after waiting for a time of 1 second. Why could this occur?

0 Kang Kang over 4 years ago in reply to bhargav kinnal

TI__Mastermind 24870 points

Hello Bhargav,

It probably means you are sending the wrong commands. Please use bqStudio first and then monitor the waveforms as an example on the EVM.

Then you can implement the same sequence in your host side.

0 bhargav kinnal over 4 years ago in reply to Kang Kang

Prodigy 70 points

Could you let me know why the device would reject to be Sealed?

When i check the SS bit of Control_status its not set even after I seal the device. This in turn causes all other issues.

0 Andy Liu (BMS) over 4 years ago in reply to bhargav kinnal

TI__Guru 52115 points

Have you used bqStudio to seal the device? Did it also fail?

Andy

0 bhargav kinnal over 4 years ago in reply to Andy Liu (BMS)

Prodigy 70 points

We do not have an Evaluation module to try the BQ studio. Is there no other way to validate this? The issue is it works sometimes and does not work other.

I am unsure how to debug this random behavior. Could you point to something that you think could be the issue?

0 Andy Liu (BMS) over 4 years ago in reply to bhargav kinnal

TI__Guru 52115 points

I would suggest you try to get an EV2400 and check if the same issue can be reproduced with the bqStudio. If the same issue doesn't occur, you can follow the same sequence as the bqStudio does .

Andy

0 bhargav kinnal over 4 years ago in reply to Andy Liu (BMS)

Prodigy 70 points

I have the EVM now. I want to know how to look at the command sequence of BQstudio for changing the Design Capacity. How to look at the steps BQ studio takes to change the parameters.

0 Andy Liu (BMS) over 4 years ago in reply to bhargav kinnal

TI__Guru 52115 points

The easiest way to connect a logic analyzer to monitor the i2c commutation when you change a parameter (e.g. Design Capacity) in the bqStudio.

Andy

Power management

Power management forum

BQ27621-G1: Read Checksum fails randomly