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.

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.

INA237: Problem

Part Number: INA237
Other Parts Discussed in Thread: DAC6578,

Tool/software:

In continuation to the previous thread

https://e2e.ti.com/support/amplifiers-group/amplifiers/f/amplifiers-forum/1351334/ina237-prblem/

We have shorted the DAC6578 pin 3 (AVDD) to GND to deactivate it (removing L30 didn't help - showed 2.4V from internal circuitry).

After doing so INA237 at address 047 is operating OK (as expected) - device ID returns 0x5449 and temperature is "normal" 23.5C.

Below is the DAC6578 circuit.

From the datasheet the only possible addresses for the DAC6578 (TSSOP version) are 0x48, 0x4A, 0x4C (not 0x47).

In addition just for testing purposes we did a read from the DAC from internal register address 0x3E (which does not exist) and we get back 0x0000 which is also what we get when reading the INA237 0x47 register 0x3E.

So maybe the DAC is also answering to the same address as the INA237 and overwriting the INA237 answer.

So what could be the problem?

  • Hey Dan,

    From your experiments, it looks like it's the DAC that is responding incorrectly. Could you disable all other devices on the I2C bus to test just the DAC by itself to confirm that it responds to 0x47 with no other devices present?

    Regards,

    Mitch

  • We removed the INA237 which is at address 0x47 and the DAC6578 (which is set to address 0x48) indeed responds to communications on this address (can change DAC output voltage when writting to address 0x47).

  • Hey Dan,

    Ok, in that case it is definitely the DAC responding to the wrong address. I'm adding the DAC team to this thread for further support.

    Regards,

    Mitch

  • Hi Dan,

    The DAC6578 has a Broadcasting mode which is a generic address used to communicate with multiple DAC6578 at once. This address is, unfortunately, 0x47. It is not possible to change this address or to turn broadcast mode off. Thus, you will likely need to change the I2C address of your INA.

    Thanks,
    Erin

  • I assume this broadcast is for writing to the DACs but what we witnessed is that the DAC responded to a read request on this address. If there were multiple DACs on the bus then would they all respond at once. This is not reasonable. 

    Update: Indeed according to the datasheet this is relevant for write only - so problem still exists because we have a problem reading

  • Hey Dan,

    Since you have 15 INA237’s, you don’t have a spare address to move the INA on 0x47 to another address. Because of this, I have 3 suggestions for you:

    1. If the DAC is reading and writing just fine on 0x47, then you could put the DAC on 0x47 and move the INA to 0x48.
    2. Change the INA237s for INA4235s or INA4230s. These devices are 4 channel devices, so you would only need 4 of them total instead of 15. This would save you board space and money, but would be a little slower, since the 4 channels all use one ADC.
    3. Add another I2C BUS or get an I2C BUS extender. This will allow for multiple devices of the same address to exist.

    I’ll put these suggestions on the E2E as well for convenience.

    Regards,

    Mitch

  • Hi Mitch,

    Thank you for your response we will probably go with Option 3 - Add another I2C bus.

    Option 1 is not correct - The DAC will always also respond to address 0x48 because that is the address defined by A0 pin (or 0x4A or 0x4C which we have other INA237 on)

    Option 2 is not relevant (although it is good to know - I see they are new components 05/2024) because we need a seperate ALERT for each channel because we use it no implement electronic fuse (using MOSFETs)

    I think the Broadcast feature should be stated clearly on the datasheet's first page including the 0x47 address. or at least in or under the I2C address options table.

    Regards,

    Dan