• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 1589 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.

INA233: Sample Count changing sporadically despite constant read time

Gabriel Maria54
Prodigy 60 points
Part Number: INA233


Hello,

I have been working with the INA233 and trying to track down the source of a bug. I am using the INA233EVM but connected an external MCU.

When I do a block read from the EIN_READ register every second I should be getting 30 or 31 samples in the accumulation register.

However I get randomly one of the following amounts without any consistent pattern:

30, 30, 30, 31, 30, 0, 30, 30, 0, 30, 90, 60, 61, 30, 30, 31, 30, 30, 120, 30, 30. 

The energy register also returns in multiples, for example, if the count is 30 I get 4530 in the accumulator, and if I get 60 counts the accumulator will be double, 9060. 

The full debug output is at the bottom of this post, I2C commands are in the format: [R/W/Command,  PMBusCommand,  Data].

As far as I can tell, Reading READ_VIN corrupts the accumulation sample process somehow, but this may be a red herring.

I also tried Single Shot ADC mode, requesting exactly 10 ADC reads and then reading READ_EIN.

I tried this single shot mode without ever reading READ_VIN and I STILL got 0, 10 and 20 counts.

Let me know if you can think of anything I can try.

Thanks,

Gabriel Maria

[R,0xE0,0x5449]		// read TI_MFR_ID, to check for communication
[R,0xE1,0x3333]		// read TI_MFR_MODEL, to check for communication
[C,0x12,0x0]		        // command RESTORE_DEFAULT_ALL 
[C,0x3,0x0]		        // command CLEAR_FAULTS
[R,0xD5,0x2]		        // modify MFR_DEVICE_CONFIG, READ_EIN Autoclear = 1
[W,0xD5,0x6]
[R,0xD0,0x4127]		// modify MFR_ADC_CONFIG, Averaging mode = 2 
[W,0xD0,0x4527]
[W,0xD4,0x800]		// write MFR_CALIBRATION, CAL value of 2048


[R,0x86,0xB2]		        // block-read READ_EIN,  Power accumulator low byte
[R,0x0,0x11]		        // Power accumulator high byte
[R,0x0,0x0]		        // Power accumulator rollover count 
[R,0x0,0x1E]		        // Sample count low byte	
[R,0x0,0x0]		        // Sample count mid byte
[R,0x0,0x0]		        // Sample count high byte 
SampleWindow:4402250		SampleCount:30		EnergyReg:4530		EnergyPerSample:151		EnergyPerTime:1029.02
[R,0x88,0x113A]		// read READ_VIN

[R,0x86,0xB2]		        // block-read READ_EIN,  Power accumulator low byte
[R,0x0,0x11]		        // Power accumulator high byte
[R,0x0,0x0]		        // Power accumulator rollover count 
[R,0x0,0x1E]		        // Sample count low byte 
[R,0x0,0x0]		        // Sample count mid byte
[R,0x0,0x0]		        // Sample count high byte
SampleWindow:1000580		SampleCount:30		EnergyReg:4530		EnergyPerSample:151		EnergyPerTime:4527.37
[R,0x88,0x113A]		// read READ_VIN

[R,0x86,0x49]
[R,0x0,0x12]
[R,0x0,0x0]
[R,0x0,0x1F]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000590		SampleCount:31		EnergyReg:4681		EnergyPerSample:151		EnergyPerTime:4678.24
[R,0x88,0x113A]

[R,0x86,0x0]
[R,0x0,0x0]
[R,0x0,0x0]
[R,0x0,0x0]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000580		SampleCount:0		EnergyReg:0		EnergyPerSample:0		EnergyPerTime:0.00
[R,0x88,0x113A]

[R,0x86,0xB2]
[R,0x0,0x11]
[R,0x0,0x0]
[R,0x0,0x1E]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000570		SampleCount:30		EnergyReg:4530		EnergyPerSample:151		EnergyPerTime:4527.42
[R,0x88,0x113A]

[R,0x86,0xB2]
[R,0x0,0x11]
[R,0x0,0x0]
[R,0x0,0x1E]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000590		SampleCount:30		EnergyReg:4530		EnergyPerSample:151		EnergyPerTime:4527.33
[R,0x88,0x113A]

[R,0x86,0xAD]
[R,0x0,0x35]
[R,0x0,0x0]
[R,0x0,0x5B]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000580		SampleCount:91		EnergyReg:13741		EnergyPerSample:151		EnergyPerTime:13733.04
[R,0x88,0x113A]

[R,0x86,0xB2]
[R,0x0,0x11]
[R,0x0,0x0]
[R,0x0,0x1E]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000580		SampleCount:30		EnergyReg:4530		EnergyPerSample:151		EnergyPerTime:4527.37
[R,0x88,0x113A]

[R,0x86,0xB2]
[R,0x0,0x11]
[R,0x0,0x0]
[R,0x0,0x1E]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000590		SampleCount:30		EnergyReg:4530		EnergyPerSample:151		EnergyPerTime:4527.33
[R,0x88,0x113A]
[R,0x86,0xFB]
[R,0x0,0x23]
[R,0x0,0x0]
[R,0x0,0x3D]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000590		SampleCount:61		EnergyReg:9211		EnergyPerSample:151		EnergyPerTime:9205.57
[R,0x88,0x113A]
[R,0x86,0xFB]
[R,0x0,0x23]
[R,0x0,0x0]
[R,0x0,0x3D]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000590		SampleCount:61		EnergyReg:9211		EnergyPerSample:151		EnergyPerTime:9205.57
[R,0x88,0x113A]
[R,0x86,0xB2]
[R,0x0,0x11]
[R,0x0,0x0]
[R,0x0,0x1E]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000580		SampleCount:30		EnergyReg:4530		EnergyPerSample:151		EnergyPerTime:4527.37
[R,0x88,0x113A]

[R,0x86,0xB2]
[R,0x0,0x11]
[R,0x0,0x0]
[R,0x0,0x1E]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000590		SampleCount:30		EnergyReg:4530		EnergyPerSample:151		EnergyPerTime:4527.33
[R,0x88,0x113A]
[R,0x86,0xB2]
[R,0x0,0x11]
[R,0x0,0x0]
[R,0x0,0x1E]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000590		SampleCount:30		EnergyReg:4530		EnergyPerSample:151		EnergyPerTime:4527.33
[R,0x88,0x113A]

[R,0x86,0x0]
[R,0x0,0x0]
[R,0x0,0x0]
[R,0x0,0x0]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000590		SampleCount:0		EnergyReg:0		EnergyPerSample:0		EnergyPerTime:0.00
[R,0x88,0x113A]

[R,0x86,0x0]
[R,0x0,0x0]
[R,0x0,0x0]
[R,0x0,0x0]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000560		SampleCount:0		EnergyReg:0		EnergyPerSample:0		EnergyPerTime:0.00
[R,0x88,0x113A]

[R,0x86,0x16]
[R,0x0,0x35]
[R,0x0,0x0]
[R,0x0,0x5A]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000570		SampleCount:90		EnergyReg:13590		EnergyPerSample:151		EnergyPerTime:13582.26
[R,0x88,0x113A]

[R,0x86,0xB2]
[R,0x0,0x11]
[R,0x0,0x0]
[R,0x0,0x1E]
[R,0x0,0x0]
[R,0x0,0x0]
SampleWindow:1000590		SampleCount:30		EnergyReg:4530		EnergyPerSample:151		EnergyPerTime:4527.33
[R,0x88,0x113A]

  • 0
    TI__Mastermind 35120 points

    Hi Gabriel,

    After programming [W,0xD5,0x6], can you add a read-back to see if the value sticks?

    If the value sticks yet the problem persists, you may have to inspect the communication on a scope, where you should be able to tell if it is hardware problem (INA233 returning wrong values consistent with the log) or a firmware problem (firmware spits out wrong values).

    Regards, Guang

  • 0 in reply to Guang Zhou
    Prodigy 60 points

    Hello Guang,

    I added read backs to all of my writes and they are sticking.

    [R,0xE0,0x5449]
    [R,0xE1,0x3333]
    [C,0x12,0x0]
    [C,0x3,0x0]
    [R,0xD5,0x2]
    [W,0xD5,0x6]
    [R,0xD5,0x6]
    [R,0xD0,0x4127]
    [W,0xD0,0x4527]
    [R,0xD0,0x4527]
    [W,0xD4,0x800]
    [R,0xD4,0x800]

    I have worked with almost every function in the INA233 and every thing has been working flawlessly besides the accumulator.

    I also took some scope images of the returned sample count low-byte equaling 0 and 30. I also have an image of the the lowbyte equaling 60 that I can post if you like.

    Regards,

    Gabriel

  • 0 in reply to Gabriel Maria54
    TI__Mastermind 35120 points

    Hi Gabriel,

    Thank you for the confirmation. I wonder if the phenomenon can be reproduced with the EVM GUI? Although the GUI may not be fast enough to support one read every second. If you can, please try it. If not, don’t worry I can set it up in our lab and play with it. I think with enough clicking we should be able to catch the problem.

    Regards, Guang

  • 0 in reply to Guang Zhou
    Prodigy 60 points

    Hi Guang,

    I have continued to experiment with different settings.

    And it appears that reducing the speed to 100kHz has avoided the problem! 

    However, the problem persists at 200kHz and 400kHz, despite great signal integrity and all other communication working fine.

    I get the impression that the INA233 is having trouble handling 400kHz packets and it is disturbing the sample counting mechanism.

    The INA233EVM dongle unfortunately operates at ~16kHz so I don't think I can use it to reproduce the error.

    So far it appears the following conditions cause the sample counting problems:

    1. 400kHz I2C speed

    2. Calling a voltage read during power accumulation (other commands may also cause it)

    Here is other info about my exact setup, although I don't think it has an effect on the issue:

    VCC: 3.318V,   I2C Addr: 0x40(GND,GND),   Shunt: 0.0025ohm.   Shunt conversion time: mode 4,    ADCVoltageConversionTime: mode 4 ,   ADCAveraging: mode 2.   CAL = 2048

    Reading once every second should return about 30 more samples with Autoclear on or off.

    If you think it would help I could give you some of my code.

     

    Regards,

    Gabriel

  • 0 in reply to Gabriel Maria54
    TI__Mastermind 35120 points

    Hi Gabriel,

    Thank you for the additional investigation. The fact that you can make the chip behave/misbehave with all settings being equal except the clock speed does point to some potential problems. We definitely need to investigate. What is the MCU that you’re using? It will be very helpful if I can recreate your setup together with your code.

    Regards, Guang

  • 0 in reply to Guang Zhou
    Prodigy 60 points
    Hi Guang,

    For my test setup I am using a Teensy 3.2 and Teensyduino, a extension of the Arduino ecosystem.
    www.pjrc.com/.../teensy31.html
    The Teensy 3.2 uses the NXP MK20DX256VLH7

    I am cleaning up my library and test code and will post it soon.
  • 0 in reply to Gabriel Maria54
    TI__Mastermind 35120 points

    Hi Gabriel,

    Thank you for the link. We don’t have this board, but can certainly purchase one to emulate your setup.

    Is there a possibility that the read occurs randomly on multiples of 1 second, instead of every second? What makes me think along this line is the fact that the power calculated is correct based on the accumulated value and the number of samples regardless of the sample count (30, 31, 60, 90, 120), except when it is 0. At which point the power is 0 as well. It is probably an outlandish proposition, because there is no explanation why slowing down SCL would fix the MCU timer. But it feels I have to ask.

    I imagine if we set the scope time scale to 1 sec/div, we should expect to see 1 transaction every second, regardless of the SCL speed. If this is true, it should put away the doubt that something is wrong with the timer.  

    Regards, Guang

  • 0 in reply to Guang Zhou
    Prodigy 60 points
    Hi Guang,

    It's not a outlandish idea. I thought about that being a possibility this morning but I remembered I had put a "SampleWindow" debug message that reads ~1000580us every time, then calculates power/time. I was trying to implement a precise power/time calculation when I ran into this bug in the first place. I actually don't care about number of samples reported for my application, the problem is the accumulation register is multiplied by the same amount. For example, 0, 30, 60, 90, 120 gives 0, 4620, 9240,13860,18480 respectively.

    Since I had everything set up anyway I checked with the oscilloscope and yes, I am reading the register one time, every second.

    I don't think you will need to buy an Teensy just yet. I would really like to see what you get after you send "400khz voltage read requests" during the INA233's accumulation. It can be done with a simple program that reads and writes the few I2C commands I have going in my original post.

    -Gabriel
  • 0 in reply to Gabriel Maria54
    TI__Mastermind 35120 points

    Hi Gabriel,

    Thank you for checking the timer.

    I don’t have a setup that is readily available to use. But I do have controllers that I can adapt to accomplish what we need to check out INA233. It will take some time to get the code written. But we’ll do the investigation to get to the bottom of this.  

    Regards, Guang

  • 0 in reply to Guang Zhou
    Prodigy 60 points

    Hello Guang,

    I have more or less finished up my code, and i slimmed it down just to demonstrate the bug.

    I hope this Zip attachment works. It just has the Arduino Sketch and the INA233 Library I made.

    It should be able to work with any Arduino compatible with a few tweeks, for example using the "wire.h" Arduino library instead of the "i2c_t3.h" library for the Teensy 3.2.

    Regards,

    Gabriel Maria

    INA233_Bug_Demo.zip

  • 0 in reply to Gabriel Maria54
    TI__Mastermind 35120 points

    Hi Gabriel,

    Thank you for the code.

    It will be sometime before I can get the setup going therefore I’ll close this thread for the time being. Can you shoot me an email (g-zhou@ti.com) so that I have your contact for communication going forward?

    Regards, Guang