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

BQ27510-G3: My "bqStudio" + "EV2400" polls the wrong I2C Bus address for my battery gauge

Atlant Schmidt
Expert 1715 points
Part Number: BQ27510-G3
Other Parts Discussed in Thread: BQSTUDIO, EV2400,

Please forgive me if the answer to this question is obvious; I really have looked around a bit but had no luck.

We have "Battery Management Studio (bqStudio) version 1.3.86 (which I believe is the latest; it's from 01-Jan-2020).

We also have an EV2400 Pod.

We use these with our BQ27510-G3 Battery Gauges (which respond to I2C Addresses 0xAA and 0xAB in normal operational mode and 0x16 and 0x17 in ROM mode).

Occasionally, our "In-System Programming" environment botches the programming of a gauge. (We don't know why that happens but that's not the issue here.) When the programming has been botched, the gauge wakes up in ROM mode rather then normal operational mode. We understand that.

What we DON'T understand is why bqStudio with the EV2400 Pod tries to poll for gauges at I2C Bus addresses 0xAA and 0x10 and NOT 0xAA and 0x16. That is, once a gauge has been botched, our bqStudio won't ever see it again until we coerce our In-System Programming environment to recover the gauge (which we can eventually do with a lot of effort).

This was a clean installation of bqStudio and I told it the correct Battery Gauge type.

Why is it polling the wrong address?

  • Is this configurable so it uses 0xAA and 0x16 instead of 0xAA and 0x10?

  • Or is it a bug in bqStudio or the EV2400 pod?

Below, I've attached Logic Analyzer traces showing the polling at 0xAA and 0x10.

Atlant

  • 0
    TI__Guru** 105760 points

    Hello Atlant,

    Are the waveforms you posted with your gauge attached to the EV2400 and bqStudio open with the gauges BQZ file open?

    This could be an error in bqStudio, I know the monitors have an address of 0x10. I will have to check with the team. In the mean time have you tried the test version of bqStudio? some bugs are fixed in the test version.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Expert 1715 points

    Wyatt:

    > Are the waveforms you posted with your gauge attached to the EV2400 and bqStudio open with the gauges BQZ file open?

    Yes, although the results are identical if the EV2400 isn't connected to a gauge at all or is connected to a powered-down gauge. In all three of those cases, the tool alternates* polling I2C Bus address 0xAA with polling 0x10.

    > I will have to check with the team.

    Thanks!

    > In the mean time have you tried the test version of bqStudio? some bugs are fixed in the test version.

    Please give me a link and I'll be happy to try that.

    BTW, one of my coworkers here found it interesting that the intended address is 0x16 and the address in use is 0x10. They wondered if maybe there was some decimal/hexadecimal confusion when this was coded up seeing as how 0x10 = decimal 16.

    Atlant

    * My current "toy" logic analyzer doesn't have enough trace depth (memory) to really say with certainty that the two addresses are truly "alternating" but both addresses are definitely being polled every five seconds and 0x16 ISN'T being polled at all.

  • 0 in reply to Atlant Schmidt
    Expert 1715 points

    > > In the mean time have you tried the test version of bqStudio? some bugs are fixed in the test version.

    > Please give me a link and I'll be happy to try that.

    Ahh, I see it!

    https://www.ti.com/tool/download/BQSTUDIO-TEST

    If I discover anything interesting, I'll report my findings.

    Atlant

  • 0 in reply to Wyatt Keller
    Expert 1715 points

    Wyatt:

    The failure I reported seems to be fixed by the time we reach bqStudio V1.3.102 (the current "Evaluation") version; I can see that version polling I2C Bus addresses 0xAA, 0x10, AND 0x16 (not necessarily in that order). I've included below a Logic Analyzer trace of the 0x16 access. (In this case, all of the accesses are getting NACKed because no gauge is attached.)

    The Release Notes hint at this fix for another gauge type:

    Please let me know if your team confirms this.

    And thanks for your help!

    Atlant

  • 0 in reply to Atlant Schmidt
    TI__Guru** 105760 points

    Hello Atlant,

    I believe this support was added because of the new gauge but is also used to fix this issue because testing is being done in both modes.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Expert 1715 points

    Wyatt:

    Just FYI, I had another "botched" (mis-programmed) Battery Gauge turn up so I tried it out against that latest "Evaluation Version" of bqStudio. As you can see from the attached screenshot, it worked fine! (Previously, with the released version of bqStudio, it would have looked like there was no gauge connected at all.)

    I think we can safely say that this issue is resolved.

    Thanks again for your help!

    Atlant

  • 0 in reply to Atlant Schmidt
    Expert 1715 points

    Wyatt:

    You might want to point out that temperature of -3102.65°C to your developers, though. That's pretty far below Absolute Zero (-273.15°C) so probably wrong. ;-)

    (They should mask the temperature reading when real data isn't available. And although you can't see it in my screenshot, lots of other data also look suspect. [Remember, my Battery Gauge isn't currently working correctly.])

    Atlant