• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 64 subscribers
  • Views 490 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-G2 I2C NACKs everything

David Littell
Intellectual 260 points

Hi,


The device responds to neither its ROM-mode (I2C address 0xb) nor its not-ROM-mode (I2C address 0x55) address - both get NACKed.

Are there any chip-external hardware issues that might cause this?

Is there any way to recover short of the blowtorch-and-chisel method?

Thanks,

Dave

  • 0
    Intellectual 260 points

    Haloooooooo?  Is there anybody out there?

  • 0 in reply to David Littell
    Genius 3970 points

    Before replacing the fuel gauge, try these steps:

    • Measure the voltage between Vcc/REG25 and Vss. You should see 2.5 volts. If not, the fuel gauge is not receiving power and power supply issues should be investigated first. If there is voltage, try momentarily shorting REG25 and VSS together to attempt a reset of the fuel gauge.
    • Measure voltage on the SDA and SCL pins with pull-up resistors connected to Vbat or some other source to rule out something that may be pulling the line(s) down to ground.

    If at this point you still don't get any response, you'll probably need to replace the fuel gauge.

    Additionally, is this fuel gauge on a TI evaluation board, a prototype, or the end-application board? Also, have you recently tried to update the firmware of the fuel gauge?

  • 0 in reply to Jason Gin
    Intellectual 260 points

    Thanks for replying, Jason.  These are production boards that have been marked bad because the fuel gauge doesnt' want to play.  I recently "inherited" a pile of bad boards along with the question: "why so many bad?"  I can only assume that part of the manufacturing process does involve reprogramming the device and I have no insight as to what actually happened.

    I forced a reprogramming of a "good" board to check if the steps in the code I was given were correct.  The "good" board still seems to be "good" but I did notice that there was a difference in expected results between the good and bad boards at the point the reprogramming code checks/verifies some values.  I can't find any documentation for those steps and the implementation is fairly baroque but one of the sequences looks like this:

    {DF_WRITE, 0x00, 0x05};   /* What is this?  No explanation found in SLUA449E or SLUS948. */
    {DF_WRITE, 0x64, 0x05, 0x00};
    {DF_DELAY, 170};
    {DF_CHECK, 0x04, 0xEB, 0xB3, 0xB0, 0xDB };   /* ("good" board wants: 0xEB, 0xB3, 0xB0, 0xDB)
                                                                            * ("bad" board wanted:  0xf7, 0xae, 0x73, 0xd8)
                                                                            *
                                                                            ***/

    Does any of that make any sense?


    Thanks,

    Dave

  • 0 in reply to David Littell
    Intellectual 450 points

    Hello

    This is the "checksum" sequence of your fuel gauge.

    {DF_WRITE, 0x00, 0x05}; // This is the command "calculate the firmware's checksum"

    {DF_WRITE, 0x64, 0x05, 0x00}; // This is a kind of "key" to confirm my intention to execute the previous command

    {DF_DELAY, 170}; // Ok, a little wait until it calculates

    {DF_CHECK, 0x04, 0xEB, 0xB3, 0xB0, 0xDB }; // The firmware's checksum should be 0xDBB0B3EB

     

    I don't know exactly why TI hides this kind of information. Your problem must be an error on reprogramming process. Try increasing the delays between the steps (there must be a lot of "{DF_DELAY, 2}", change them to "{DF_DELAY, 5}") or try using a slower I2C speed, if possible. Check these "bad" boards for parasitic capacitances that could deteriorate the I2C communication.