• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 2 answers
  • Subscribers 48 subscribers
  • Views 1134 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.

Original question:

INA220 Intermittent Errors when measuring 0mA

INA220: Shunt voltage random values (spikes) when measuring 0mA

Horv.joe
Prodigy 85 points
Part Number: INA220
Other Parts Discussed in Thread: INA3221, INA231, INA230, INA233, INA226, INA260

Hi, 

I have a product, that uses 5 x INA220B devices, separated on two I2C buses. (3 device on bus No1, and 2 devices on bus No2)

The buses are controlled by an Atmel ATXMEGA128A3-AU controller, and run on 400kHz. 

The INA measures only the voltage across a 0,004 Ohm shunt resistor (via IN+, IN- pins, the Vbus pin is connected to the ground). 

The configuration register's value is 0x219D (40mV fulls scale, 12 bit resolution, Shunt voltage continous conversation, conversation time: max 586us) 

The controller periodically reads the INAs, in every 600us. 

The SCL,SDA rise and fall times < 300ns so the meet the specifications. 

When AC, or DC current flows throught the shunt, everything works fine. 

If no current applied on the shunt, most of the time they read 0 (or 1-2 LSB noise which is normal) BUT sometimes they read random values (3002, -2453, 3524 ect...) during 1 read cycle then again 0. 

The errors are totally random, they are not periodically (2-20 mins between values ).

We have more than 60 product with 5 INAs on them, and all of them (60 x 5) has the same error... So I think the ESD, or random device failures from production can be excluded. 

I searched in this forum, LINK   and found that, Tony Jay had a very-very similar problem with the INA220. 

Unfortunatelly the forum thread closed, without any solution or workaround for this problem... :( 

 Is this a known issue and are there any fixes? 

Thanks

  • 0
    Guru 55913 points

    Horv.joe said:
    The buses are controlled by an Atmel ATXMEGA128A3-AU controller, and run on 400kHz. 

    Perhaps SIO transport is to blame if GPIO ports are configured synchronous versus asynchronous? Does the serial I/O have data polled into MCU when values change from 0? Scope capture may help to diagnose the FIFO noise source is internal or external born.  

  • 0 in reply to Genatco
    Prodigy 85 points

    I have tried it with 100kHz, and 1,5ms reading period. The problem still exists. 

    I don't think that MCU's GPIO, or FIFO noise is the source of the problem, because in the 99,99% of cases, it currectly measures 0mA, with no input current. 

    Moreover, if I apply any current ( even only 1 LSB  = 2,5mA) to the input, the problem desapears...

    As Tony wrote in his post: (https://e2e.ti.com/support/amplifiers/f/14/t/497217?INA220-Intermittent-Errors-when-measuring-0mA)

    "...I would not be surprised if the ADC result is not properly buffered and held whilst doing the maths and/or supplying the 2 byte result to I2C.
    eg. If an I2C request comes in just before a new conversion result is ready, and if the previous conversion was positive and the new one is negative then maybe there is some mixing-up of old/new data..."

  • 0 in reply to Genatco
    Prodigy 85 points

    I have also did some measures with logic analyser (with built in I2C decoder), and it decode the same values on the bus, as the MCU.   

  • 0 in reply to Horv.joe
    Guru 55913 points

    Horv.joe said:
    Moreover, if I apply any current ( even only 1 LSB  = 2,5mA) to the input, the problem desapears...

    Would you expect anything less?

    Horv.joe said:
    "...I would not be surprised if the ADC result is not properly buffered and held whilst doing the maths and

    So make it stop doing any math calculation when sample[n] input = 0. Curious why is the ADC sample sequencer is not configured interrupt driven? 

  • 0 in reply to Horv.joe
    Guru 55913 points

    Horv.joe said:
    I don't think that MCU's GPIO, or FIFO noise is the source of the problem, because in the 99,99% of cases, it currectly measures 0mA, with no input current. 

    Perhaps one way to diagnose issue is to only poll SIO for data when what ever measured starts to run, draw current. Table 5 may give clue, how have you configured the mode?

    Although the INA220 can be read at any time, and the data from the last conversion remain available, the Conversion Ready bit (Status register, CNVR bit) is provided to help coordinate one-shot or triggered conversions. The Conversion Ready bit is set after all conversions, averaging, and multiplication operations are complete.

  • 0
    TI__Mastermind 32395 points

    Hey Horv.joe,

    I believe this is part of a known issue that was fixed for newer power monitor devices. The issue has been speculated now a couple times and I can confirm that there can be an issue in the data register if the host is reading it before the conversion and register update times are completed. The reason why this seems to only happen when measuring zero current is not clear to me, but could be due to how the register is actually updated every conversion. I will check on this with the responsible team.

    So if you are polling the INA220 every 600 µs and the conversion time is also set, then, unless the polling and conversion times are perfect multiples of each other, then over time the polling will occur during the register update.

    This problem was fixed by adding an extra register buffer for all other power monitors made after the INA220. So if you would like to simply replace the device, the following are the power monitors with the fix: INA226, INA230, INA231, INA233, INA260, and INA3221.

    Another solution is still keep the INA220, but use the triggered shunt voltage mode (explained in section 8.3.1). This way you can trigger a single conversion event and then read the data after using a set time or until after the conversion ready bit (CNVR) has been set.

    I hope this helps and please post back for any more questions.

    Best,

    Peter

  • 0 in reply to Genatco
    Prodigy 85 points

    Gl said:
    Table 5 may give clue, how have you configured the mode?

    As I wrote before, the configuration register's value is 0x219D  = ‭0010 0001 1001 1101 so the last 3 bits 101 = ‬MODE: "Shunt voltage, continuous". 

    Gl said:
    Although the INA220 can be read at any time, and the data from the last conversion remain available, the Conversion Ready bit (Status register, CNVR bit) is provided to help coordinate one-shot or triggered conversions.

    As I know the INA220 can't request interrupt from the MCU when conversation is ready, so the MCU has to poll it periodically. (read the CNVR bit, from bus voltage register, or read directly the shunt voltage register. )

  • 0 in reply to Peter Iliya
    Guru 55913 points

    Peter Iliya said:
    So if you are polling the INA220 every 600 µs and the conversion time is also set, then, unless the polling and conversion times are perfect multiples of each other, then over time the polling will occur during the register update.

    Seemingly why I2c, SSI and other serial asynchronous peripherals the GPIO ports need to be configured for async on MCU such as C2000. Otherwise the GPIO input remains default sync to SYSCLK rather than the polling application being in sync with the async peripheral clocking.

  • 0 in reply to Horv.joe
    Guru 55913 points

    Horv.joe said:
    so the last 3 bits 101 = ‬MODE: "Shunt voltage, continuous"

    I would have never guessed and has been awhile since reviewing 220 datasheet. Seemingly as Peter also re-comments you need to reconfigure 220 for triggered or one shot conversion when polling the CNVR bit. 

    Please let us know if any of this helps you! 

  • 0 in reply to Peter Iliya
    Prodigy 85 points

    Thank you for your answer! 

    If this is a known issue (at least for 3 years), why is this not mentioned in Errata, or in the datasheet??? 

    Peter Iliya said:
    So if you would like to simply replace the device, the following are the power monitors with the fix: INA226, INA230, INA231, INA233, INA260, and INA3221.

    I can't modify the hardware because we sold 50 devices, and they are all in field, in customers, and also manufactured +100 devices which under shipping to customers... 

    Peter Iliya said:
    Another solution is still keep the INA220, but use the triggered shunt voltage mode (explained in section 8.3.1). This way you can trigger a single conversion event and then read the data after using a set time or until after the conversion ready bit (CNVR) has been set.

    I have modified the firmware to triggered conversation, than read the values periodically, and after read, trigger new conversation... I seems to work. 

    BUT with 3 devices on the bus it takes at least 885us a whole period to read and trigger 3 devices (with 400kHz clock) 

    It is a problem, because it is a current transmitter device for industrial PLC DAQ application... And with this solution the sampling time increases so the input bandwidth decreases...  :/ Resulting that the device doesn't meet the specifications.... :( :( 

    I can't increase the I2C clock either because with larger clock I have to decrease the pull-up resistor values.. which is hardware modification... :/

  • 0 in reply to Horv.joe
    TI__Mastermind 32395 points

    Hey Horv.joe,

    Is the 885us time using the shortest conversion time of 84us? Maybe you could reduce the overall time by setting conversion time to 84us, triggering all 3 devices sequentially, and the read all 3 devices sequentially so you don't have to set any hard delays in the firmware? Or maybe you have already thought of this?

    Best, 

    Peter

  • 0 in reply to Peter Iliya
    Prodigy 85 points

    The 885us, is the time takes to communicate with the 3 devices on the bus. 

    I have attached a screenshot from logic analyzer. 

    Peter Iliya said:
    Maybe you could reduce the overall time by setting conversion time to 84us,

     

    We need 12bit ADC resolution,  the 84us is only enought for 9 bit! 

    Anyway the problem is that it takes more time to re-trigger the ADCs in every period over I2C. 

  • 0 in reply to Horv.joe
    TI__Mastermind 32395 points

    Hey Horv.joe,

    Of course. I'm looking into any other possible way to speed up the operation or ensure no incorrect reading occur. I will reply later today.

    Best,

    Peter

  • 0 in reply to Horv.joe
    TI__Mastermind 32395 points

    Hey Horv.joe,

    What is the required BW for measurements? 12-bit conversion time is max 586µs, so this is theoretically the best sampling time possible. 

    What about another approach? Can you program in time delays into your code? I ask this because you could go back to the continuous mode, 12-bit and then program your host to poll for the data 600µs after writing to the configuration register and repeat a polling every 600us so you are reading the register after the 586µs conversion time.

    In addition to this you could read each shunt register twice or thrice consecutively and implement some digital logic to ignore any readings that are obviously incorrect?

    If none of this is possible, then I recommend replacing the INA220 with the INA226. It is pin-to-pin compatible, in the same package, and has the same register mapping. The only difference is that the INA226 has more features and better accuracy.

    Hope this helps.

    Sincerely,

    Peter

  • 0 in reply to Peter Iliya
    Prodigy 85 points

    Hi Peter, 

    Peter Iliya said:

    What is the required BW for measurements? 12-bit conversion time is max 586µs, so this is theoretically the best sampling time possible. 

    What about another approach? Can you program in time delays into your code? I ask this because you could go back to the continuous mode, 12-bit and then program your host to poll for the data 600µs after writing to the configuration register and repeat a polling every 600us so you are reading the register after the 586µs conversion time.

    The required BW is 800Hz. So according to the shannon nyquist sampling theorem  the maximum sampling time is 624us. so the 600us reading interval with continous conversation mode would be the best. This was my original solution.  but It doen't work because of the INA internal buffer bug. 

    Because in continous conversation mode the INA starts conversation and when it finished write the result to the output register, and after automatically starts the next conversation write the output register etc... (regardless of whether I read the output register or not... ) So If the conversation time exactly 586us and  I read the output register in every 600us, after 42 reading there will be a moment when the INA writing the register during I'm reading... this is the bug... 

    If I restart the conversation after reading (by writing the configuration register), this operation (read, restart, read restart etc) takes 885us because I have 3 devices on the same bus, so I have to do it tree times.. 

    Peter Iliya said:
    implement some digital logic to ignore any readings that are obviously incorrect?

    This could be a possible solution but, what happens, when a short voltage spike really appear on my input?? The logic would belive it measurement error, and drop the reading... 

    The final solution has become that we have reduced the required BW specifications to 500Hz and paid our customers compensation for the shipped products.... :/