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.

INA226 sensor cannot write to configuration register

Other Parts Discussed in Thread: INA226

I am having trouble reading and writing to the registers of the INA226 current/power monitor in linux.
http://www.ti.com/product/ina226

I'm running with CentOS 6.5

[root@PCIE7207 ~]# i2cdetect -l
i2c-0    i2c           i915 gmbus ssc                      I2C adapter
i2c-1    i2c           i915 gmbus vga                      I2C adapter
i2c-2    i2c           i915 gmbus panel                    I2C adapter
i2c-3    i2c           i915 gmbus dpc                      I2C adapter
i2c-4    i2c           i915 gmbus dpb                      I2C adapter
i2c-5    i2c           i915 gmbus dpd                      I2C adapter
i2c-6    i2c           DPDDC-B                             I2C adapter
i2c-7    smbus         SMBus I801 adapter at 3040          SMBus adapter

[root@PCIE7207 ~]# i2cdetect 7
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-7.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- 1a -- -- 1d -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 -- 32 -- -- 35 -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: 50 -- 52 -- -- 55 -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --                         
[root@PCIE7207 ~]#

The ina266 device is 0x44

Cannot write to 2nd byte
[root@PCIE7207 ~]# i2cset -y 7 0x44 0x00 0x4127 w
[root@PCIE7207 ~]# i2cdump -y 7 0x44 w             
     0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
00: 4100 b700 1800 0000 0000 0000 0800 0000

Cannot write 55 to the 2nd byte
[root@PCIE7207 ~]# i2cset -y 7 0x44 0x00 0x5555 w
[root@PCIE7207 ~]# i2cdump -y 7 0x44 w             
     0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
00: 5500 b400 1800 0000 0000 0000 0800 0000

Writing to the calibration register 0x5 has the same result
[root@PCIE7207 ~]# i2cset -y 7 0x44 0x05 0x2323 w
[root@PCIE7207 ~]# i2cdump -y7 0x44 w             
     0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
00: 5500 b700 1800 8700 1200 2300 0800 0000

Not only can I not write to 2nd byte, the 2nd byte is also not displayed in the example above of power register, current register, etc.

Dumping with byte mode doesn't look correct

[root@PCIE7207 ~]# i2cdump -y 7 0x44 b             
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 38 00 00 06 04 00 00    .........8..??..



Is i2cget i2cset and i2cdump not working correctly?

  • Dan,


    I'm not terribly familiar with the linux i2cget and i2cset commands, but I wonder if this might be the issue:

    instead of:

    i2cset -y 7 0x44 0x00 0x5555 w

     

    try

    i2cset -y 7 0x44 0x00 0x55 0x55 w

     

    It may be that the bytes need to be split up.  If that doesn't work, please let me know and I'll go into more depth with our more proficient linux users.


    Best regards,

    Jason Bridgmon

  • using the word (w) mode, it doesn't allow that many arguments to the command.  But I can write byte mode, shown below with the same results:

    [root@PCIE7207 ~]# i2cset -y 7 0x44 0x00 0x55    
    [root@PCIE7207 ~]# i2cset -y 7 0x44 0x01 0x55
    [root@PCIE7207 ~]# i2cdump -y 7 0x44 w       
         0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
    00: 5500 a700 0e00 0000 0000 0000 0800 0000

    Thanks for helping looking into it Jason!

  • Dan,


    sending

    Just looking at the man page for i2cset (http://linux.die.net/man/8/i2cset), I see that w should have worked for 0x5555, however I wonder if using the batch command might do it?

    would something like this work?

    i2cset -y 7 0x44 0x00 0x55 0x55 i

     

    Let me know,

    Jason

  • Hi Jason,

    Looks like the same results:

    [root@PCIE7207 ~]# i2cset -y 7 0x44 0x00 0x55 0x55 i
    [root@PCIE7207 ~]# i2cdump -y 7 0x44 w              
         0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
    00: 5500 ae00 1300 0000 0000 0000 0800 0000

    Thanks,

    Dan

  • Hi Dan,

    I see you're using bus 7 which is (at least according to your logs) an SMBus master. So can you try an smbus block write instead ?

    # i2cset -fyr 7 0x44 0x00 0x55 0x55 s

    -f -> force

    -r -> readback (saves you the trouble of using i2cget :-)

    also, which kernel version are you using (uname -a) and does the same SMBus master work with other i2c/smbus devices ?

    regards

    ps: you might want to use the ready-made ina2xx.ko driver which already ships with mainline Linux kernel. Let me know if you need instructions on how to enable that driver (you might need to recompile your kernel).

  • Hi Felipe,

    The smbus block write failed, should this work?

    [root@PCIE7207 ~]#  i2cset -f -y -r 7 0x44 0x00 0x55 0x55 s
    Error: Write failed
    [root@PCIE7207 ~]# i2cdump -y 7 0x44 w                 
         0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
    00: 5500 ee00 1300 0000 0000 0000 0800 0000

    Here's the kernel info, running 64bit CentOS 6.5

    [root@PCIE7207 ~]# uname -a
    Linux PCIE7207 2.6.32-431.23.3.el6.media_sdk.x86_64 #1 SMP Wed Aug 20 08:24:09 MST 2014 x86_64 x86_64x86_64 GNU/Linux

    There are other things on the bus, but I don't have the data sheet for them.  I am able to read from the temperature sensor 1a and the even bytes don't all seem to be 00 like the voltage monitor

    [root@PCIE7207 ~]# i2cdump -y 7 0x1a w                     
         0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
    00: ef00 0000 0000 0000 0000 d4c1 5400 0121
    08: 0101 0160 01a2 9627 0100 0100 XXXX XXXX

  • Dear TI,
    We put a I2C analyzer on the bus and I can see that the INA226 is only sending a lower byte value. the upper byte value is always 0x00, the lower byte value is the actual value.
    for example
    we wrote 0x4527 to pointer 0 and we saw 0x4527 on the bus using the i2c analyzer.
    but when we read the config register we only got 0x0027.
    we observed that the upper byte sent back was 0x00.

    is there some configuration inside the ina226 that will prevent it from sending out the upper byte?
  • Hello Matt,
    What is the clock speed you are running at. Can you try to slow down the communication and check to see if it works. Also can you try to write to another register (Example: Calibration register) so that both MSByte and LSByte are changed and then check to see if you can read both bytes back from that register.
  • looks like its running about 50uS period which is 20kHz.
    I've got a screen shot, but I'm trying to figure out how to add it to this discussion.
  • Matt,
    When you click reply you see a link on the bottom right for "Use rich formatting". You can click that to bring up the tool bar where it will let you atttach files. If you can save your screenshot as a picture and try to attach and see if that works.
  • have you seen anything like this before with this or any other TI part?
  • Matt,

    We have not seen this before on this or other parts.

    After looking over your plot, I would take these steps to debug -
    1. Try resetting the INA226 with a power-cycle and just reading back register 00h without writing to it. The defaults are 4127h. It is possible that there is a problem with the write command being accepted in the device.

    2. You show registers 1 - 4 in the screen shot, all of which are 00h and then some number. These are bus voltage, shunt voltage, power, and current. With no inputs, these are likely to be showing near 0 readings, so having 00xxh values makes sense, unless they are biased. The reset condition for register 00h and possibly register FFh are the only registers that have an MSB programmed by default. I suggest focusing on those two registers, or apply a (near) full scale signal to the INA226 inputs and/or bus voltage to take some readings where the MSBytes are expected different.

    3. Try writing something like 4521h to register 00h and then reading it back to make sure it's 4521h (or in your current case, 0021h). Then write 8000h to register 00h to reset the device and read our register 00h again and see if it's 4127h (or 0027h) to make sure the MSByte is being written correctly.

    4. Another thing to check is the power consumption. By default, 4127h means the device is converting continuously. Writing 4120h to register 00h should put the part into power-down mode, where the current drops from 300uA to under 2uA. It's an external way to check that the write routine is working as expected that doesn't rely on register readback.

    Based on the results of these tests, we'll be able to tell if the MSByte and LSByte are being written correctly or not, and if the problem is in write or read.

    If it is in read, then possibly putting a 100-200ohm series resistor between the pullup on SDA and the INA226 and using an oscilloscope in parallel with the logic/i2c exerciser can help debug and point to which device is pulling SDA low during that MSByte of the read, if there is any thought that the master could be pulling it low accidentally at that time.

    Let us know your results and we'll go from there, as well as your thoughts on the matter here.
  • Since there is no reset input on the device, I'm assuming it resets with the power transistion.

    We tried this, but we keep reading the upper 8 bits as 0.

    see this screen capture.

    you can see the first  commadn is a write to 00, then a read from 00 produces 00 27

    then a write to 05 of 5a5a returns a read of 05 of 00 5A.

    then its repeated.

  • Hello,

    I see you are still experiencing the issue.

    Have you tried steps 2-4 in my debug suggestion list yet? Also, have you tried using an oscilloscope on the SCL and SDA lines instead of the logic analyzer, to make absolutely sure the issue is in hardware and not the logic analyzer software?

    Thank you,
    Jason Bridgmon
  • yes, we tried steps 2-4, also we were about to go down the oscilloscope route, when we decided to just change the address of the INA226 to see if the problem moved.

    moving to address  0x45 showed a hidden device at address 0x44.

    then we learned that there is an Intel SMBUS bridge controller at address 0x44 inside the PCH.

    that always returns 0x00FF.

    so we configured bios to move the default address of the smbus controller to 0x4F and now we can see the full INA226 device on our SMBUS.

    Thanks for your help.