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: bq27510 Manufacturer Info Block A: Sending a checksum intermittently results in NON ACKNOWLEDGEMENT

Part Number: BQ27510-G2
Other Parts Discussed in Thread: BQ27510, BQSTUDIO

Please help.

My program runs on Windows CE.  The single board computer that is running my program provides the I2C APIs.  I write 32 bytes of data to Manufacturer Info Block A.  The method to send the data returns TRUE for sending the 32 bytes.  Then my program sends the checksum of the data and this intermittently fails with the error code that represents non-acknowledgement.  The failure rate is about 2%.  Subsequent reading block A shows that the data previously sent to the bq27510 were not written and the old data are returned.

I repeated READ data  --- WRITE data --- WRITE checksum --- READ data and failure always occurs when writing the checksum and nowhere else.

I put 2.5Sec before writing the checksum but it did not help.

I am using Bus Speed of 100KHz.

Would appreciate it very much if anybody can help.

Jun

  • Hi Jun,
    pls reference the app note below on guage communication. hopefully, this helps resolve the issue you are seeing.

    www.ti.com/.../slua801

    thanks
    Onyx
  • Hi Onyx,

    I had read SLUA801 and I believe my program is following what the document dictates.  The parameters for each command are hard coded in the source and each time when the program UNSEAL Manufacturer Info Block A --- WRITE data --- WRITE checksum --- SEAL the memory block, the only different thing that are sent to the fuel gauge chip is the data and checksum.  And if a failure occurs, it only occurs at WRITE checksum; the method that I use to send any command, called I2CTransfer method returns false and the error code is -7, which represents NO-ACKNOWLEDGEMENT.  

    After writing the data in the data, my program sends commands to read the data back and compare them with the data sent.  This READ command always succeeds and returns data even after the failure of the checksum command,  After the failure, the READ data returns the old data rather than the data sent just prior to the failed writing checksum.

    I changed the logic such that the writing data sequence above is repeated up to 4 times till writing is a success.  And this change did not work.  If writing checksum occurs, it never recovered.  But as I wrote above, after 4 failures, the READ data command was a success and the fuel gauge returned old data which were written in the last successful WRITE checksum.

    I confirmed that no other commands had been sent to the fuel gauge other than the commands included in the sequence above.

    What could be the reason for the fuel gauge not returning acknowledgement?

    Jun Inagaki

    Nova Biomedical Corp.

    Waltham MA

  • H i Jun,
    I believe the question here is why is your checksum failing? Are you calculating the checksum as described in the app note? Can you sniff the i2c lines when communicating with the device using bqstudio to see what you are doing differently from bqstudio?
    thanks
    Onyx
  • Hi Onyx,

    Thank you for your time.

    I am testing the final product level and it is a bit difficult to set a probe on SDA or  SCL. 

    When the checksum failed, I calculated the checksum myself and the value I calculated matched the number that was sent.

    Here is the source code for the calculation. I believe it is correct.

    BOOL writeMfgBlockData( BYTE* b, int size )

    {

    unsigned char bchksum = 0;

    unsigned int uitemp = 0;
    for( int i = 2; i < size + 2; i++)
    {
    wbuf[i] = b[i - 2]; //load the remaining bytes
    uitemp += wbuf[i]; //might as well add checksum while we are at it
    }
    uitemp = 0x00FF - uitemp;
    bchksum = uitemp; //perform compliment on the checksum, BQ27510-2G requirement

    }

    b[] holds the data and size is set to 32.  The value held by bchksum is the checksum.

    wbuf is sent first and right after it bchksum is sent.

    What are the conditions that the fuel gauge logic does not accept the checksum?  

    Jun

  • hi
    The conditions are If the checksum is wrong and if you do not have sufficient delays between commands. Can you increase your delay some.

    I understand you are testing at product level but you should be able to have a test unit that you can place probe and test points on to resolve your issue.

    thanks
    Onyx
  • Is this repeatable with the exact same data block?

    If the gauge NACKs the check sum then the block with the new data that it received prior to the check sum does not compute the same check sum as you wrote to 0x60.

  • Hi Dominik,
    Thank you for responding.
    I sent exactly the same 32 bytes of data that previously failed in writing its checksum to the fuel gauge. The debug info shows the program sent the same checksum as before and this time writing the checksum passed. Apparently, the checksum failure is not related to the value of the checksum itself.

    >> "If the gauge NACKs the check sum then the block with the new data that it received prior to the check sum does not compute the same check sum as you wrote to 0x60."
    As I said before, the checksum value that failed matched the checksum I hand calculated. And the checksum calculating logic I posted is following what the TI documents dictate: Take the sum of the value of 32 bytes. Take the least significant byte of the sum and subtract it from 0xFF. The result is the checksum.
  • Did you verify this all the way down to the I2C bus electrical level?

    The gauge will NACK the check sum if it is incorrect so something goes wrong somewhere in your level of abstractions from I2C electrical all the way up to your high level code. If you already verified that the data block and the check sum match in your code then you'll have to dig deeper in your communications layers.

    From a gauge point of view and based on the information that you provided you do everything right.

    I would set up an I2C data log with an external I2C sniffer and compare the actual traffic (data block and check sum) between a successful case and one where the gauge NACKs.