Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 64 subscribers
  • Views 236 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.

BQ25896: BQ25896 REG0C and multi-read/write

Niclas Arndt
Intellectual 425 points
Part Number: BQ25896

Hello,

In the datasheet, under 9.2.16.7 Multi-Read and Multi-Write, it says "REG0C does not support multi-read and multi-write".

Could you please be more specific about its behaviour?

REG0C is a read-only register, so supposedly a single write to it doesn't have any effect. Does a multi-write to e.g. REG0A -> REG0B -> REG0C -> REG0D in some way halt or cause any other problem?

I have done multi-reads of all registers from REG00 though to REG14 that seem to work. The only potential issue would be that the read from REG0C provides a nonsense 0x00 byte (which is difficult to know when you don't have an error), but the subsequent registers (REG0D -> REG14) in this REG00 -> REG14 multi-read seem to provide valid content.

Perhaps the most relevant use case is when reacting to an INT pulse. First you do a single read from REG0C to get and clear the error flag/s.

Then it is more practical to do a multi-read from REG00 through to REG14 and if necessary do a single read from REG0C, compared to doing a multi-read REG00 -> REG0B, a single-read REG0C, and finally a multi-read REG0D -> REG14.

Could you please shed some light on this?

Best regards

Niclas

  • 0
    TI__Guru 52371 points

    Niclas,

    Please refer to 9.2.16.7 for the details.

    9.2.16.7 Multi-Read and Multi-Write

    The charger device supports multi-read and multi-write on REG00 through REG14 except REG0C.

    REG0C is a fault register. It keeps all the fault information from last read until the host issues a new read. For example, if Charge Safety Timer Expiration fault occurs but recovers later, the fault register REG0C reports the fault when it is read the first time, but returns to normal when it is read the second time. In order to get the fault information at present, the host has to read REG0C for the second time. The only exception is NTC_FAULT which always reports the actual condition on the TS pin.

    Thanks,

    Ning.

  • 0 in reply to Ning T
    Intellectual 425 points

    Hi Ning and thank you,

    Yes, but 9.2.16.7 is ambiguous

    Is the only limitation regarding REG0C and multi-read / multi-write the fact that you have to read it a second time to get first the up-to-this-point triggered faults and then the current status? If so, should you do the single-read of REG0C before or after the multi-read or is it of no importance?

    Or, does multi-reading or multi-writing across REG0C cause any kind of malfunction, going into an unspecified state or something similar?

    Best regards

    Niclas

  • 0 in reply to Niclas Arndt
    TI__Guru 52371 points

    Niclas,

    Please follow the d/s descriptions. Please single read REG0C twice to get the present fault information.

    Thanks,

    Ning.

  • 0 in reply to Ning T
    Intellectual 425 points

    This is annoying and a waste of time.

    If you are working for TI and don't know the answer, please escalate to somebody who knows.

  • 0 in reply to Niclas Arndt
    Intellectual 425 points

    I'll try to rephrase the question again. Please read it carefully before you respond:

    Let's initially assume that you are correct about the necessity to _single_ read REG0C twice to get both accumulated and current error information.

    If the programmer also wants to read the content of all the registers REG00 -> REG14 but doesn't care about the correctness of REG0C this time (because you have already single read it twice), is there a risk that a multi read REG00 -> REG14 would cause any kind of malfunction, going into an unspecified state or something similar? As I wrote in my original question, this seems to work just fine.

    It is clear that the following sequence is safe:

    #A: single REG0C, single REG0C, multi REG00 to REG0B, multi REG0D to REG14

    This is probably also safe:

    #B: single REG0C, multi REG00 to REG0B, single REG0C, multi REG0D to REG14

    A more practical sequence would be:

    #C: single REG0C, single REG0C, multi REG00 to REG14

    An even more practical sequence would be:

    #D: single REG0C, multi REG00 to REG14, single REG0C

    The most practical sequence would be:

    #E: single REG0C, multi REG00 to REG14

    Sequence #E is by far the easiest to implement, especially if you do the I2C communication interrupt-based and the I2C bus is shared by several slave devices so you have to decide which slave you will be talking to every time an I2C bus transaction is completed.

    I wrote 'initially' at the beginning of this message, because I suspect that sequence #E will both work without malfunction _and_ give you the correct content of REG0C in the multi read. My assumption is that the person who wrote the datasheet didn't understand the programming implications and didn't bother to learn (and explain) the details about REG0C and multi reading / writing. I suspect that the correct description is that you need to read REG0C twice in whichever way you choose. (The keyword is probably 'twice' and not 'single'.)

    You cannot answer my question by referring to the datasheet. You need to escalate the question to 2nd or 3rd level support with access to HW design information, people who might even have been part of the design team.