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.
Part Number: BQ27426EVM-738
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?
We will look into this and get back to you tomorrow.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Onyx Ahiakwo:
Any word on what the problem could be?
In reply to Robin Callender:
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.
In reply to Dominik Hartl11:
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.
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.
ps ensure you are posting correct files to avoid delays getting a resolution to your problem. I have pinged my colleague to check this
You write the following 32 data bytes to 0x3E, block 0:
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.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.