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

Original question:

BQ27411-G1: BlockData access issue

BQ27411-G1: Issue in accessing RAM data

Tony Man
Prodigy 150 points
Part Number: BQ27411-G1
Other Parts Discussed in Thread: BQSTUDIO, EV2400

Follow up on the previous thread, the manual SLUA801 is examined and the recommended workflows for the extended commands are implemented.

Situations mentioned in the previous thread persist with additional observations.

1. Offset from full block read

Instead of reading two bytes from specific block offset, a new implementation has been tried to read full block. 

The write command is 0x40 and 32 bytes were read.

Abnormal format of return data is received. Read data is coherent with the manual but the read byte offset is incorrect. For example, when subclass STATE with id of 0x52 was read, the Q Invalid Max V was read in offset 5 instead of 6. All data are shifted one byte forward. And hence i am not sure which byte is omitted.

In addition, the last byte(byte 31) of the transaction is the checksum value. I am not sure whether it is mentioned in the manual.

2. Unresponsive BlockData() access command

Similar as the setup in above, the the write command is changed into 0x46 to access block value with offset 6 to access the Q invalid Max V value directly. However the return read data is identical to the previous command. BlockData() of 0x40 and 0x46 return the same data, which is unexpected.

3. Requirement of checksum write in prior of BlockData()

I am not sure if my understanding is correct, but the checksum value of the pending write block data had to be transfer before setting new blockData value to avoid a NACK situation. 

The manual SLUA801 seems to perform checksum write after the write block data, which might not be coherent to the suggestion in manual SLUUAS7B.

I might be wrong in this observation. Despite the NACK situation is resolved, I do not think the write procedure is accepted as the register values after BlockData() write did not change. I am still working on that.

Thanks again for your attention.

  • 0
    TI__Guru 54196 points

    I recommend trying your data access with bqStudio and Advanced Comm.

    For example: Read 32 bytes, block 0 from class STATE:

    Which matches these parameters:

    Note that Q Invalid Max V is not in class STATE but in class Chemistry Info:

    So if you want to read Q Invalid Max V, you'd have to read a 16-bit integer (big endian) from offset 2, block 0, subclass ID 0x6D:

    0x0EE3 = 3811mV

    #3: You must write the check-sum and length after you updated the data in the gauge's parameter buffer (which is accessed from command 0x40++).

    #2: please try replicating the correct read sequence for class Chemistry Info as shows in #1

  • 0 in reply to Dominik Hartl11
    Prodigy 150 points

    Thanks for the reply

    #1 #2

    It seems that the bqStudio requires EV2300 to work properly. Is there any alternate ways in accessing register data?

    I think the data provided in the bqStudio is not coherent to the user manual. Is there any manual with correct address and register values for reference?

    #3

    Writing the checksum after update led to NACK response in my case so far. I will validate the issue if I found some way to in accessing the correct value in reading the register values.

    Thank you again for the kind help.

  • 0 in reply to Tony Man
    TI__Guru 54196 points

    You need either EV2400 or EV2300 with bqStudio. The addresses in bqStudio are the correct addresses and are more current than what's in the TRM.