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.

ina219: Clearing of the CNVR (converson ready) flag in the bus voltage register - documentation error?

Part Number: INA219

According to the INA219 datasheet: 

Bus voltage register:

CNVR Conversion Ready
Bit 1 Although the data from the last conversion can be read at any time, the INA219 Conversion Ready bit (CNVR) indicates when data from a conversion is available in the data output registers. The CNVR bit is set after all conversions, averaging, and multiplications are complete. CNVR will clear under the following conditions:

 1.) Writing a new mode into the Operating Mode bits in the Configuration Register (except for Power-Down or Disable)

2.) Reading the Power Register

But observed behaviour differs:

When polling the bus voltage register (address 02h), a first poll has the flag bit set, any immediate subsequent polls show a low flag bit. After one conversion cycle time, the flag bit is set again.

I.e.:

- the flag bit is unaffected by any reads of the power register (03h)

- the flag bit is cleared by reads of the bus voltage register (02h)

Can anybody confirm or clarify this observation?

Kind regards, Stefan

  • Stefan,
    We'll check the documentation and the EVM Monday morning and confirm.
  • Stefan,
    We did a test where we triggered a single-shot reading and then read the bus register, and then the bus register again. The CNVR bit cleared. We then did another conversion with the power register and then the bus register, and it was cleared. Same for the shunt voltage and current registers. So, in our basic testing, we found reading any data register effectively clears the CNVR bit. I want to do due diligence here and confirm this with the design team that this behavior is the expected behavior, but it seems as though your first observation is correct. More to come...
  • Stefan,
    I worked with the design team to review the device digital operation and this is how the part should work:

    If the CNVR bit = 1 and you write anything but 100 or 000 to the CONVERSION MODE bits in the configuration register, it will clear to 0.
    if the CNVR bit = 0 and you have a conversion running, then when all the samples are collected and the math is 100% completed and the internal data registers are updated, then CNVR sets to 1.
    If the CNVR bit = 1 and the bus voltage register (which has the CNVR bit in it) is read out, then the CNVR bit clears to 0.

    Those are the only behaviors you should ever see regarding the CNVR bit.

    I do suspect that the EVM may be reading out all the registers on each reading, and then only updating the field I requested updated. So in actuality, if i said to read only the power register, I would be reading the bus V and power register (and all the other registers) which clears the CNVR flag but only updates the power register. Then when I went back to read the bus V register, I would find that it had been cleared, and it would look like reading the power register cleared it, but it didn't, it was just hidden. Perhaps that is the behavior you are seeing?
  • FYI

    I notice some other strang behavior that may be related to this. It seems that 'bit 1' of all read registers is stuck to '0'. I have 3 INA219 devices in my prototype.

    One shows this issue, the other 2 works fine when using the same code/hardware (they just have another I2C address). I only change the adress defines in my code and then I get normal operation from devices with another address.

    For some reason in the 'faulty device' the bus voltage register is no longer updated after any write to the configuration register. When reading the configuration register is responds with 0x399d instead of 0x399f..

    More to check, device @ I2c addr 0x41 has this problem. addr 0x44 and 0x45 work fine.
  • Mark,
    That is certainly weird and I've not seen it myself. Just to confirm, when you write 399F to the config reg and immediately read it back, you get 399D? If you write 399B do you get back 399A?
  • Hello Jason,

    I did some more testing. Writing 0x399B returned 0x3999. After replacing the device, communication works as expected (returning 0x399B after writing 0x399B). The device was damaged (as it is a prototype this could have happened...) but it did not cease operation, it just 'lost' functionality which first showed itself as the CNVR bit sticking low.

    Orginal (defect) device:

    Replaced device:

  • Mark,
    So if I read this correctly, replacing the damaged device with a new one solved the issue. If there's anything else you need, or if I misread your response, just let us know. We're happy to help.