• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 63 subscribers
  • Views 341 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.

BQ34110: Delay between command and response

Elder Costa17
Expert 2825 points
Part Number: BQ34110

I am writing software to access BQ34110 registers. I send the command to read device type (0x00 0x01 0x00) and read the response right away on 0x40. I was getting invalid responses (0xFF followed by some numbers) instead of 0x01 0x10 (on the protocol analyzer screen). Then I added a read on 0x40 and the expected result appeard on the second read: the analyzer shows the expected byte sequence. I left the office and on my way home I had an insight: there must be a delay between the command and the response.

So, what is the delay I must add between sending a command and reading the response?

  • 0
    Expert 2825 points

    Additional information: I added a 1ms delay after sending the get type command and succesfully read back the expected responses the very first time.

    I have looked at data sheet and TRM sections on communication and did not find any information on delays required by the fuel gauge to fulfill a command request.

  • 0 in reply to Elder Costa17
    TI__Guru 61006 points

    See the TRM http://www.ti.com/lit/ug/sluubf7a/sluubf7a.pdf, 3.2:

    "Reading the Control() registers will always report the CONTROL_STATUS() data field except after the DEVICE_TYPE() and FW_VERSION() subcommands. After these subcommands, CONTROL_STATUS() will report the value 0xFFA5 one time before reverting to the normal data response. This is a flag to indicate that the data response has been moved to MACData()."

    Please read CONTROL_STATUS() after issuing the DEVICE_TYPE() subcommand. You should read 0xFFA5 from CONTROL_STATUS(), indicating that the device status is now ready to be read from 0x40++

  • 0 in reply to Dominik Hartl11
    Expert 2825 points

    Hello, Dominik.

    I saw that paragraph on 3.2 but I failed to grasp the purpose of that 0xFFA5. In hindsight, it is pretty obvious.

    Thank you very much for your support.

    Regards.