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.

INA238: the device seems to be corrupted, or is it a fake device?

Part Number: INA238
Other Parts Discussed in Thread: INA228, TI-SCB, SYSCONFIG

Hello,

The INA238 is out of stock everywhere but I really need it and find someone on Aliexpress selling it. I bought it and tested 2 units, and the result below is the same.

I wrote a driver from scratch so it's possible I made a mistake. I recorded the I2C transaction with a logic analyzer, please find the log file below:

write to 0x45 ack data: 0x00 0x80 0x00
write to 0x45 ack data: 0x3E
read to 0x45 ack data: 0x54 0x49
write to 0x45 ack data: 0x3F
read to 0x45 ack data: 0x22 0x81
write to 0x45 ack data: 0x00 0x00 0x10
write to 0x45 ack data: 0x00
read to 0x45 ack data: 0x00 0x00
write to 0x45 ack data: 0x02 0x27 0xC0
write to 0x45 ack data: 0x02
read to 0x45 ack data: 0x27 0xC0
write to 0x45 ack data: 0x01 0xF4 0x92
write to 0x45 ack data: 0x01
read to 0x45 ack data: 0xF4 0x92
write to 0x45 ack data: 0x06
read to 0x45 ack data: 0x00 0x00
write to 0x45 ack data: 0x05
read to 0x45 ack data: 0x00 0x00
write to 0x45 ack data: 0x0B
read to 0x45 ack data: 0x00 0x00

As you can see, I first reboot the device by writing 0x8000 in the config register. Then I can successfully read "TI" in the company id register, but the first weird reply is the next one, I should read 0x2381 or 0x2380 but I'm reading 0x2281 (which is another TI reference though).

Then I'm writing 0x10 into the config register to set the scale range to 40mV. Then I'm reading the same register and got 0x00.

Then I'm writing 0x27c0 into the shunt calib register and I read back 0x27c0, so everything is ok here.

Then I'm writing 0xF492 into the ADC config register and I read back 0xF492, same, ok here.

But then, I'm reading the bus voltage register (I plugged a 3V supply on it) and the temperature register but I get 0x0000 for both.

Lastly I'm reading the DIAG_ALRT register and get 0x0 when I should read 0x1. 0x0 means "a checksum error is detected in the device trim memory space."

I confirm that I have the exact same result with 2 different units soldered on 2 different custom boards. If it was fake, I shouldn't read any register right? Do you have an idea on this issue?

Thanks for your help,

Arthur

  • Hi Arthur,

    I know this doesn't solve your problem right now, but only buy from a TI's authorized distributor.

    Kai

  • Hey Arthur,

    That is odd that it is reading as an INA228 instead of INA238, I wonder if they gave you INA228's instead? Either way the biggest issue I see is the MEMSTAT bit really should be reading as a 1. Since yours is a 0, something is definitely wrong. Because of this, the part should be returned to TI for failure analysis. This process will be done through the source you got the part from, but here are a couple recourses that should help:

    Failure Analysis page: https://www.ti.com/support-quality/additional-information/failure-analysis.html

    Customer Returns page: https://www.ti.com/support-quality/additional-information/customer-returns.html

  • Hello Mitch,

    The device marking is INA238, that's why it's weird to see INA228.

    Ok, I'll check I can return these parts.

    In the meantime, I agree with Kai but unfortunately I cannot find this part (or the INA228) anywhere. Did I miss something there? Do you know any distributor with a stock?

    Thanks for your help,

    Arthur

  • Hey Arthur,

    Currently I do not know of anyone who has them in stock. I recommend going to the device product page and clicking "Notify me when available" from the ordering section.  

  • Hello Mitch,

    Thanks for the tips, that's what I did.

    The unsoldered device is not in-stock on TI's store but there are still some INA228 evaluation boards (INA228EVM). I ordered 2 of them and I'm currently testing them.

    First, the device ID seems now correct and match the device marking (INA228). But what I read in registers don't match the reality.

    Let me explain my setup:

    I have a shunt capacitor of 100Ohms plugged on the high side of my load which is a resistor of 2kOhms. I'm applying a supply voltage (let's call it PS1) of 3V which is measuring the current sent to the system (which is 14.5µA here).

    IN+ and IN- are plugged on the shunt resistor, VBUS on the supply voltage (same as IN+). The VS pin is plugged to my 3V supply coming from my µController board (let's call it PS2). One GND pin is plugged to PS1's GND and another GND pin is plugged to PS2's GND. SDA & SCL are plugged to my µController I2C bus.

    Then, when I boot my sample code, I'm doing the following sequence:

    writing 0x8000 into the config register 0x00 => to reset the INA228

    writing 0x10 into the config register 0x00 => set 40.96mV range, no ADC delay and no shunt temp compensation

    writing 0x1000 into the shunt calibration register 0x02 => 13107200000*current_lsb*rshunt*4 with current_lsb = (0.04096/rshunt) / 524288

    writing 0xF000 into the ADC configuration register 0x01 => lowest conversion time, no averaging, continuous measurements on temperature, bus, shunt voltages

    reading from temp register 0x06 gives 0xccc => with LSB of 7.8125mDeg it's 25.5°C => this is OK

    reading from bus voltage register 0x05 gives 0x3c6 => I right shift this value by 4 bits, then multiply by a LSB of 195.3125µV and I have 11718µV which is wrong because I should have 3000000.

    reading from current register 0x04 gives 0x3d7 => I right shift this value by 4 bits, then multiply by a LSB of 7.8125e-10 and I get 47e-9 which is wrong too. I expect 14e-6

    I tried with both EVM and I have the same result.

    Do you see any issue?

    Thank you,

    Arthur

  • Hey Arthur, 

    It looks to me like there may be a problem with your code.  The last 4 bits of both the bus and current register are reserved and should always read 0.  In your case, you got a non 0 value.  Maybe you are not reading enough bytes for those registers? I have two suggestions to help test this.

    1. You could get the TI-SCB (https://www.ti.com/tool/TI-SCB) and test the EVM with our code/GUI to make sure it all works fine in your system.

    2. You can use SysConfig to help update your code (or make a test code project) to see if you can get the correct values. SysConfig can be found here: https://dev.ti.com/sysconfig/index.html?product=ascstudio, or you can use this link to start a project with the INA228 already added: https://dev.ti.com/sysconfig/index.html?product=ascstudio&module=/ti/sensors/currentsensor/INA228.

    You may as well try option 2 before option 1, in case you can get it working without ordering more hardware.

  • Hello Mitch,

    Thanks for your tips about the number of bytes, I was reading only 16bits. Now it's working as expected.

    Last question, I made a test setup to check the measurements which is a simple 3V power supply (showing the current consumed) plugged on a 240kOhms load resistor. The INA228 is using a shunt resistor of 100Ohms.

    When the power supply shows a current consumption of 15µA, the INA228 is measuring 12.5µA. If I unplug the Vbus pin, the power supply show 12.5µA. Therefore, the Vbus pin seems to draw 2.5µA from the line. I checked the datasheet, I cannot find anything about this leakage, they are only talking about the leakage when it's shutdown.

    Can you confirm that the Vbus pin is drawing current during the measurement?

  • Hello Arthur,

    Yes, the VBUS pin does draw current during the measurement. The datasheet doesn't define the current, as that changes based on the bus voltage. Instead, the datasheet defines the input impedance (Zvbus), and then you can calculate the expected current drain.  From the datasheet we have this:

    So, with a typical value of 1MΩ, the expected current at 3V would be I=V/R = 3/1M = 3µA.  Since you are seeing 2.5µA, you have an input impedance of R = V/I = 3/2.5µ = 1.2MΩ, which is the maximum specified value for the Zvbus.

  • Thanks for your detailed answer, it's clear.

  • Hello Mitch,

    I'm getting back on this subject because I'm encountering a linked issue.

    As I'm trying to measure very low currents, this Vbus current is an issue. In order to reduce its impact, I was planning to enable continuous shunt voltage measurements only and sometimes measuring vbus voltage with a single shot measurement. Then, I realized that this Vbus pin input impedance is there in active mode, meaning as long as I making any measurement (shunt or temperature only), the current will be drawn.

    Do you confirm that the integrated mux cannot completely "disconnect" vbus when measuring shunt voltage?

    If so, to resolve my issue, I plan to add a MOSFET transistor (or a 1 to 2 mux) in series with the Vbus pin in order to connect or disconnect it manually. Do you think of any other simpler way to resolve this issue?

    Best,

    Arthur

  • Hello Arthur,

    I believe you are correct that it cannot be disconnected while taking other measurements, but I have reached out to the design team to confirm and will let you know if they say something different. 

    If you want to disconnect it manually, then the MOSFET idea seems good, as long as that circuitry does not use more current than you are trying to save.

  • Hello Mitch,

    I tried several solutions. A MOSFET was not a good idea because I don't have the necessary voltages on VGS to control it correctly. Both P-fet and N-fet cannot work. So I decided to use a mux. On the control side everything is ok. But, it seems the INA228 doesn't like the idea to have its VBUS pin connected and unconnected all the time.

    When I do omy VBUS voltage measurement in single shot mode, I often get a voltage which is quite low compared to the real value. For example I get 2V for a 3V voltage. Sometimes it returns correctly 3V. I tried to put a delay (up to 2s) between the mux connection and the measurement but it just reduce the error frequency without completely deleting it.

    Moreover, I sometimes get the "Bus Voltage Over-Limit" raised in the alert register. I didn't change the limits register, so it means when I reconnect, it detects a huge voltage.

    Do you have an idea of what is happening here?

    Thank you

  • Hello Mitch,

    I have a better understanding. It's not the bus voltage over-limit, because diag_alrt is equal to 0b10000. The MEMSTAT bit is equal to 0. When I reset the device, the bit change back to 1 and everything works. To reproduce the issue, I simply read the current, power and energy registers in a loop and after 2-3 seconds, the MEMSTAT bit become 0 and all register values hang to the last value.

    I tried an I2C clock frequency of 100kHz and 400kHz, result is still the same.

    What exactly can cause "a checksum error in the device trim
    memory space"?

    Best,

    Arthur

  • I just tried replacing the multiplexer with a op amp acting as a buffer (noninverting configuration) between vbus and the vbus pin. This resolve my leakage current to the vbus pin. It's simpler than the multiplexer because I don't have to control the connection/disconnection.

    I still have the MEMSTAT issue though. I also tried with an official INA228EVM board, I can reproduce the issue by reading registers in loop. 

  • Hey Arthur,

    I'm glad you were able to get your setup to work with the op amp.

    I'm trying to repeat the MEMSTAT issue you have on my end, and haven't been able to yet.  Do you still get the error when you try your read test with the default settings and no load? Or only with your use case specific settings and a load?

  • Hello Mitch,

    Thanks for trying to reproduce. I used a logic analyzer and noticed that the INA228 was sending the correct data and diag_alrt register was ok too. I started to look into my code and my I2C "read" implementation was using a malloc which was never freed...

    Sorry, the mistake is on my side. Now everything is working well. Thanks again for your help

  • Ok, thanks for letting us know, glad you figured it out!