• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 62 subscribers
  • Views 745 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.

BQ78350-R1: Reading registers - especially cycle count

Todd Anderson
Prodigy 20 points
Part Number: BQ78350-R1
Other Parts Discussed in Thread: BQSTUDIO

All:

Just about everything is going well. Using this for battery management, however - cannot seem to get valid read of cycle count (0x17). Battery Management Studio shows value of 1 for battery, but when using I2C (SMbus) to read count, several batteries show a value of 64596, which is very puzzling.

Several other registers are being read, and appear to be good readings. When discharging, I get a valid read of AverageTimeToEmpty (0x12), and that goes to 65535 when not being discharged.

AverageTimeToFull (0x13) always reads 65535, even when discharging.

Regards, 

Todd Anderson

  • 0
    TI__Guru 57697 points

    Hello Todd,

    65535 is the maximum value for time. Time to empty and full will go to this value when not being discharged because battery will stay in same state. This is correct.

    Cycle count can be written into data flash.

  • 0
    TI__Guru 57697 points

    Hello Todd,

    If there is a difference between bqStudio and other I2C/SMB readings, i suggest that you check your I2C/SMB communication. It is safe to assume that the gauge is operating correctly if bqStudio reads the correct values.

  • 0
    Prodigy 20 points

    Average TimeToFull(0x13) is only valid when charging. (Submitted a datasheet bug)

    I can read Status (0x16) and get valid contents (when compared to Battery Management Studio), but I am still having problems with Cycle Count (0x17). I also tried to read Design Capacity (0x18) and that too returned a value of 64596. Also very confusing. 

    Is there something related to SMB configuration that I may not be doing with the microprocessor that I using? (vs. Battery Management Studio)

    Regards,

    Todd Anderson

  • 0 in reply to Todd Anderson
    TI__Guru 57697 points

    Hello Todd,

    Make sure that the microprocessor can support clock stretching

  • 0 in reply to Shirish
    Prodigy 20 points

    Yes, clock stretching is supported. (That was an earlier issue - resolved by allowing a longer timeout on I2C transaction.) I will continue to debug with hardware engineer (Zoll) - hopefully, we can resolve this. Thank you for all of your feedback.

    Regards,

    Todd Anderson

  • 0 in reply to Todd Anderson
    Prodigy 20 points

    As I understand it, there is a difference between reading an EEPROM location and reading a register on BQ part. Is this correct? (hopefully, I will not lose format..)

    EEPROM read

    Controller    S  AD+W          RA           S  AD+R                      NACK  P

    Peripheral                   ACK         ACK                 ACK  DATA

    BQ read - additional ACK needed by Controller, then PEC is sent.

    Controller    S  AD+W          RA           S  AD+R                      ACK           NACK  P

    Peripheral                   ACK         ACK                 ACK  DATA           PEC

  • 0 in reply to Todd Anderson
    TI__Guru 57697 points

    Hello Todd,

    That is correct when using PEC. Note that PEC is optional, this allows it to look like EEPROM read for systems that may not support PEC. We recommend using PEC when possible.

  • 0 in reply to Shirish
    Prodigy 20 points

    Is there a way to make PEC the 3rd byte to be read, so that on register read of 2 bytes, a 3rd byte is read, that being PEC? In other words, is the ACK needed by the controller?

  • +1 in reply to Todd Anderson
    TI__Guru 57697 points

    Yes, that should work. PEC is automatic. If the controller sends an ACK then the gauge will send PEC.