• State Answer Suggested
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 474 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.

BQ34Z100: Bad read of current in HDQ mode

martin gibbs
Intellectual 520 points
Part Number: BQ34Z100

Hi,

I have a BQ34z100 set in HDQ mode, communicating with a MSP430. All seems OK most of the time. Occasionally, once every few hours, we get a bad read of the current (can be in DSG or in CHG) from the BQ34z100.

The number read is "24587" which in turn leads to an over current charge trip. Strangely the problem only occurs when the device is sealed. Un sealed no problems.

As recommended we have applied a fair degree of sanity checking to the HDQ comms, but there are limits to this.

Is there any relevance to the "24587" read back? IS TI aware of a solution to the problem?   

Thankyou.

Regards

Martin

  • 0
    Genius 3970 points

    Hi Martin,

    The readout of 24587 equates to a hexadecimal value of 0x600B, which happens to coincide with a common CONTROL_STATUS readout (FAS, SS, LDMD, VOK and QEN bits are set to 1).  It would make sense that this glitch manifests itself only when the gauge is sealed, as a the 13th and 14th most significant bits correspond to the gauge's security state (0x000B would be the equivalent if it was in the FULL ACCESS security state, and this would otherwise be interpreted as a charging current of 11 mA).

    As for how this data is ending up in your average current readout, I am not sure - in my experience, the HDQ interface just tends to be quirky at times. Perhaps you can try adding some code to check if the value of AverageCurrent() or some other register is the same as Control(CONTROL_STATUS). It may be enough to catch the glitch if/when it reappears; it could potentially be glitching more frequently than initially thought.

    I am not a TI employee so I cannot say whether there is any internal knowledge on something like this, but for now, sanity checks and/or re-reads are probably the simplest solution to the problem.

    Regards,
    Jason

  • 0 in reply to Jason Gin
    Intellectual 520 points

    Hi Jason,

    Thank you for your response. It has a shed a little more light on the situation for us. We are looking into more sanity checking but ideally, for charging, I would like to respond on a single OC event.

    I was obviously hoping for a response and a way forward from Ti, but thanks again for taking the time to help.

    Best Regards

    Martin