• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 64 subscribers
  • Views 229 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

BQ27421EVM-G1A: Nacked CheckSum

BQ27421EVM-G1A: Unreliable ability to configure via I2C

Zachary Thatcher
Prodigy 140 points
Part Number: BQ27421EVM-G1A

Hello,

I am using this gas gauge and configuring it on startup of a board via i2c. My issue is that sometimes the chip configures and other times it does not. It is seemingly random, and occasionally has to do with me plugging/unplugging things on the board at other locations. I have been modifying when I configure the chip over time and this seems to have a temporary effect. Now I wait 15 seconds before attempting to configure. That worked the first time, and no longer works.

I perform several checks in order to determine that I am ready to configure the chip, such as checking that the battery is detected, the chip is initialized, checking that I have entered configuration mode when I attempt to, etc. If I do not pass any given check I do not continue forward with initialization. Rather, I go back and attempt to pass the check (sometimes this means just checking again, other times it means attempting to enter config mode again, and other times it means writing blocks again). I want to provide a few of my checks to the reader and get some feedback on whether or not they are accurate. 

Bat detected: Register 0x06, first byte read, bit 3 means that the battery is detected

Initialization complete: Register 0x00, first byte read, 7th bit means initialization is complete

Entered config mode: Register 0x06, first byte read, fourth byte set means in config mode

Please let me know if I should be checking all of these registers to confirm that my actions are being completed as anticipated. As I said, this is something that works occasionally but doesn't work occasionally as well. If anyone has had an experience that they needed to monopolize the I2C line for the extend of configuration, that would be useful to know as well. I currently allow the user to use that I2C line for other purposes while configuration is completing. I have an I2c queue and I don't think that I am dropping messages. 

I am fully capable of communicating with the chip and have observed that I enter all of these modes consistently and occasionally even get the configuration to work correctly. I do this at 100KHz I2c.

Please let me know any thoughts.

Thanks!

  • 0
    TI__Mastermind 24870 points
    We have the gauge communications app note. There's reference code. If you follow it, there should be no issues.
  • 0 in reply to Kang Kang
    Prodigy 140 points

    Kang Kang,

    Thank you for the suggestion.

    What did you mean by "there's reference code"? If you mean that there is a manual that provides references for all of the register address numbers, I am familiar. I have read several different TI publications on how to configure these chips. As I said, configuration randomly works and randomly does not (even though the chip controlling it goes through a deterministic sequence of commands). I really need some user experience at this point.

    Are there any time dependencies I  the configuration sequence that are not explained in the user manuals? I am just trying to think of something that could be causing my configuration sequence to sometimes work and sometimes not. My controlling chip's logic is deterministic and performs the same sequence every time (eg. checking to see that I am in the configuration mode and calculating the block checksum). But there is a possibility that it gets delayed. Maybe this would affect something in an undefined way?

    Thanks again,

    Zach

  • 0 in reply to Zachary Thatcher
    TI__Guru* 76230 points
    Hi Zach,
    I would recommend you reduce the frequency to less than 100kHz.
    Secondly, the quick start guide ffor the guage goes through the process of of communicating with the gauge and accessing data flash etc.
    www.ti.com/.../sluuah7

    The gauge communication document has code on accessing the gauge.
    www.ti.com/.../slua801

    I would recommend ensuring that the gauge is not in sealed mode when trying to read commands not accessible in sealed mode.

    Also ensure you have delays between commands.

    hope this helps some.
    thanks
    Onyx