• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 2985 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.

BQ27545 HDQ and I2C Communication

Matthew Beardsworth
Genius 9175 points

Hi Team,

 I am working on an application that requires communication to the BQ27545 via the HDQ and I2C interface. The HDQ interface connects to an external device and the I2C to a local processor for reading the registers. 

Is there any reconfiguration that needs to take place when switching between which interface is used?

In the event that the HDQ and I2C bus is used simultaneously, how does the BQ27545 handle this? Is this even an issue?

 

Thank you for the support,

Matt

  • 0
    Genius 3970 points

    Hi Matt,

    Unfortunately, the bq27545 (or any of TI's single-cell gauges) does not support simultaneous use of both the I2C and HDQ interfaces.

    Additionally, the gauge uses I2C by default, but can be sent into HDQ mode with TI's evaluation/development software. However, this is a one-way trip; even reflashing the firmware will not restore I2C access.

    One potential solution could be to expose an interface on your host microcontroller to allow external access to the gauge, but I'm not aware of any existing solutions that implement this.

    Jason

  • 0 in reply to Jason Gin
    TI__Genius 9175 points
    Hi Jason,
    Thank you for the prompt response.

    Looking at the HDQ communication basics app note: www.ti.com/.../slua408a.pdf
    It appears that multiple devices can be tied to a single HDQ data bus similar to I2C.

    I suppose then that the other way to do this is to tie a MCU onto the HDQ bus as well as the external host device and have the MCU decode the HDQ for register data.

    Have you heard of anyone doing a design this way before?
    Can you outline any downside to using the HDQ over the I2C bus?

    Best Regards,
    Matt
  • 0 in reply to Matthew Beardsworth
    Genius 3970 points

    Hi Matt,

    HDQ, although it is an open-drain bus much like I2C, cannot be used as a multi-device bus as the fuel gauge occupies much of the HDQ bus' address range, and HDQ has no device addressing scheme either. Having more than one fuel gauge on the same HDQ bus would result in collisions and prevent proper device communication.

    The HDQ bus is primarily aimed for replaceable/removable battery packs where the cost savings of omitting a pin on the connector outweighs the performance penalties of using HDQ as opposed to I2C:

    • HDQ is dramatically slower than I2C (7 kbps for HDQ, versus 100 kbps for I2C). Most applications that use HDQ only poll the fuel gauge occasionally (although the gauge does have an HDQ interrupt feature, it has to be explicitly enabled by the host). Because of HDQ's limited speed, updating a gauge's firmware over HDQ can take up to 20 minutes, as opposed to about 30 seconds over I2C.
    • HDQ has no message-acknowledgment feature like I2C; the host cannot determine if a gauge has received a command apart from using a timeout period (and that only applies for commands that require the gauge to respond)

    I haven't personally heard of any application that exposes the HDQ bus to both the host and an external MCU, but it could be done if the host regularly polls the HDQ bus, with the external MCU acting as a data 'sniffer'.

    Jason