INA237: Prblem

Dan Kessler

Part Number: INA237
Other Parts Discussed in Thread: DAC6578

We have a board in which we use 15 INA237 devices on a single I2C bus addresses 0x40-0x47, 0x49-0x4F

In addition, we have DAC6578 at address 0x48 on the same bus

Device at address 0x47 does not work properly as other do - it is physically the 2nd device from the master CPU (STM32) on the I2C bus .

We have manufactured 5 prototype boards and all 5 have the same problem - not a singular problem.

DAC6578 work (reads and writes) as expected.

All INA37 devices (0x40-0x46, 0x49-0x4F) work OK - reading DEVICE_ID 0x5449 at internal address 0x3E. below examples of reading DEVICE_ID

Temperature from register 0x6 reads 0x10a0 (33.25C degrees) seems OK.

Now for the problem

INA237 Device 0x47 returns 0x0000 for DEVICE_ID and temperature from register 0x6 reads 0x340 (6.5C degrees) as temperature (working at room temperature)

Interestingly the device does operate as expected when configuring the ALERT and threshold registers - In activates the ALERT when current exceeds threshold.

We tried 6 different threshold values and they worked as expected (using digital load) and 15 [mOHM] SHUNT resistor:

0.1A: SOVL 0x0C = 0.0015mV/5uV = 300d = 12Ch
0.2A: SOVL 0x0C = 0.0015mV/5uV = 600d = 258h
1A: SOVL 0x0C = 0.015mV/5uV = 3000d = 0BBBh 
2A: SOVL 0x0C = 0.03mV/5uV = 6000d = 1770h 
4A: SOVL 0x0C = 0.06mV/5uV = 12000d = 2EE0h 
6A: SOVL 0x0C = 0.09mV/5uV = 18000d = 4650h

So writing to the device seems to work.

Reading back the SOVL values returns 0x0000.

All devices share the same design

Any help would be appreciated.

7 months ago

0 Clemens Ladisch 7 months ago

Guru 279750 points

Apparently, some other device reacts to address 0x47.

Are the any devices other than these INA237 and the DAC?

0 Dan Kessler 7 months ago in reply to Clemens Ladisch

Prodigy 30 points

No, total 16 devices (15 INA237 and 1 DAC) all work (read and write) except 0x47 INA237.

Additionally as I wrote the problematic INA237 does receive the write commands but replies with bad data.

0 Mohamed Hamida 7 months ago in reply to Dan Kessler

TI__Expert 6602 points

Were you able to verify if a different device works on that physical I2C address?

0 Dan Kessler 7 months ago in reply to Mohamed Hamida

Prodigy 30 points

Can you elaborate on that? You mean replace the ina237 with a new ina237

0 Mohamed Hamida 7 months ago in reply to Dan Kessler

TI__Expert 6602 points

Yes, or use a different type of device.

0 Dan Kessler 7 months ago in reply to Mohamed Hamida

Prodigy 30 points

Do you suspect it is the device? If yes then I don't think so because we have 5 boards with the same problem.

0 Guang Zhou 7 months ago in reply to Dan Kessler

TI__Mastermind 30600 points

Hi,

What about reading back all other registers. For example, after configuring ALERT and thresholds, can you immediately read them back?

If yes, ID register should work too, unless the pointer was not set properly prior to the READ command.

Regards, Guang

0 Dan Kessler 7 months ago in reply to Guang Zhou

Prodigy 30 points

All readback from registers for this particular INA237 (@ address 0x47) are not OK

0 Guang Zhou 6 months ago in reply to Dan Kessler

TI__Mastermind 30600 points

Hi,

Does the controller have the ability to adjust timing of the I2C bus? It appears there is zero data hold time while a minimum of 10nS is needed on all data bits for this device.

If adjusting timing is not possible, you could try adding an RC filter close to the SDA pin which hopefully helps extend the hold time a little.

Regards, Guang

0 Dan Kessler 6 months ago in reply to Guang Zhou

Prodigy 30 points

I don't think that this is the problem - as you can see (on a working address) the 100KHz SCL clock (Yellow) rises when data is already stable.

+1 Guang Zhou 6 months ago in reply to Dan Kessler

TI__Mastermind 30600 points

Hi,

My comment has to do with how SDA looks at the SCL falling edge. The two edges appear to be happening at the same time.

Regards, Guang

0 Dan Kessler 6 months ago in reply to Guang Zhou

Prodigy 30 points

From closer inspection there is 150ns Hold time (data is valid for 150ns after clock falls).

Regardless, As you can see from OP the device does answer but with all '0's in data so it is not a CPU timing issue.

And why does this device at address 0x47 always show this problem (on all 5 boards) and not the other 14 INA237 devices on each of the 5 boards?

0 Guang Zhou 6 months ago in reply to Dan Kessler

TI__Mastermind 30600 points

Hi Dan,

That’s the mystery.

Is it possible to perform some experiments? For example –

Swap the INA237 at 0x47 with another working one at a different address and observe the two’s behavior. Is the problem following the DUT, or is it staying at the address?
Remove all I2C devices from the bus, except for the INA237 at 0x47 and the controller. Observe if the DUT works.

Regards, Guang

0 Dan Kessler 6 months ago in reply to Guang Zhou

Prodigy 30 points

We thought about it and will try it once we complete other power up tests that remain on the board.

I will update this post once we get to it...

0 Guang Zhou 6 months ago in reply to Dan Kessler

TI__Mastermind 30600 points

Hi Dan,

Sounds good, please post back when you have time. I’m curious to learn about the findings.

Regards, Guang

Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

Amplifiers

Amplifiers forum

INA237: Prblem