• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 557 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

BQ27426EVM-738: BQ27426 NAKs I2C checksum write request for prior Data-Memory write.

Robin Callender
Prodigy 60 points
Part Number: BQ27426EVM-738
Other Parts Discussed in Thread: BQ27426, EV2400, BQSTUDIO

I have copied the code from Appendix A of  the SLUA801 "Gauge Communication" document. The host mCU is an ARM Cortex-M4 (nRF52832). In general the code appears to be working as expected up to the point of failure described next.

The actual point of failure is when the host attempts to set the checksum and receives a NAK. The transaction prior to this is the writing of the DC_STATE data via the gauge_write_data_class() function, which according to the included I2C trace shows as being successfully ACK-ed.  There is a 10ms delay between these two I2C transactions, which I believe is sufficient for the BQ27426.  I have increased the delay a bit, but to no effect: still getting a NAK on the writing of the checksum.

Also of noteworthy is the rather long clock-stretching for longer I2C transactions.  While this is not wrong, it is an indication the BQ27426 is struggling to keep up with larger I2C writes.

I have attached a Logic Analyzer trace and a screenshot of the sequence in question.

Can someone help me understand what are the possible causes for this NAK?

TI_BQ27426_Programming_0426_2_02-bq27426G1gmfs_4Sep2019-3.logicdata.zip

  • 0
    TI__Guru* 76230 points

    Hi Robin

    We will look into this and get back to you tomorrow.

    thanks

    Onyx

  • 0 in reply to Onyx Ahiakwo
    Prodigy 60 points

    Any word on what the problem could be?

    Robin

  • 0 in reply to Robin Callender
    TI__Guru 51346 points

    I checked your Saleae log but hat doesn't seem to show this problem for DC_STATE. However, it shows one NAK on write (in line 481) but that's in a sequence where you insert a few read commands between writing block 2 of IT_CFG (0x50) and writing the check-sum.

    In general, except for this excerpt around line 481, the data classes get programmed without errors. See attached csv file that I created from your Saleae log file.

    bq27426_I2C.csv

  • 0 in reply to Dominik Hartl11
    Prodigy 60 points

    Sorry, but I posted the wrong Logic trace.  :-/

    Attached is the one with the errors-in-questions.

    BTW, the first trace is with BQStudio + EV2400 + BQ27426EVM, and was generated to compare with our errant trace.

    Again, sorry for the confusion.

    Robin

    BQ27426_write_data_class.logicdata.zip

  • 0 in reply to Robin Callender
    Prodigy 60 points

    Has anyone had a chance to look at the new trace I posted?

    I am still at a lose as to what is causing this error.

    Robin

  • 0 in reply to Robin Callender
    TI__Guru* 76230 points

    Hi Robin,

    ps ensure you are posting correct files to avoid delays getting a resolution to your problem. I have pinged my colleague to check this

    thanks

    Onyx

  • 0 in reply to Robin Callender
    TI__Guru 51346 points

    Hello,

    You write the following 32 data bytes to 0x3E, block 0:

    0x40 
    0x00 
    0x00 
    0x00 
    0x00 
    0x81 
    0x05 
    0x3C 
    0x13 
    0x60 
    0x0C 
    0x8A 
    0x2E 
    0x65 
    0x00 
    0x32 
    0x0B 
    0xB8 
    0x00 
    0x00 
    0x00 
    0x00 
    0x00 
    0x00 
    0x00 
    0x00 
    0x00 
    0x01 
    0x17 
    0x00 
    0x00 
    0x00 

    When I add them up, I get 0x03AB. So the lower 8-bits are 0xAB and the check-sum is 0xFF - 0xAB = 0x54

    You write a check-sum of 0x00 to 0x60 which is why the gauge NACKs this transaction. Please write 0x54 instead.

    Setup Write to [0x55] + ACK
    0x60 + ACK
    0x00 + NAK //this must be 0x54
  • 0 in reply to Dominik Hartl11
    Prodigy 60 points

    I have found the problem

    In the code examples in SLUA801, there is a conflict between the DC_STATE_LENGTH (64) when using it with CMD_BLOCK_DATA (0x40).

    The datasheet states that the BlockData command (0x40) command only access the first 32 bytes of data.

    The function gauge_write_data_class(void *pHandle, unsigned char nDataClass, unsigned char *pData, unsigned char nLength)

    contains the following line.

    if (gauge_write(pHandle, CMD_BLOCK_DATA, pData, nLength) != nLength) return -1;

    which in itself is not wrong.

    But when the following code (in A.3 of SLUA801) calls the above function, nLength of 64 is passed.

    n = gauge_write_data_class(pHandle, DC_STATE, pData, DC_STATE_LENGTH);

    resulting in the NAK on the attempt to write the second 32 byte segment from pData.