• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 308 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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-Q1: I2C address selection does not work as expected

Harald Ilg
Genius 3060 points
Part Number: INA237-Q1
Other Parts Discussed in Thread: INA237

Hy,

we develop a 19" rack with 8 cards, each holding a INA237-Q1. We put the pins A0 and A1 to the card edge connector, on the backplane we connect A0 / A1 to Gnd, 3.3V, SDA or SCL differently for each slot. On each card, there is also an eeprom (address range 0x5x) and a port expander (adress range 0x2x).

We now have the first board and try to take it into operation. The assembled INA reacts on address 0x40 when A0=Gnd, A1=Gnd and to 0x41 when A0=3.3V and A1=Gnd.

But when we connect A0 to SDA, the device reacts on 0x43 rather than 0x42. We use raspberry pi i2cdetect to find out which simply scans each I2C address. I2C signals seem good, speaking of edges and timing, freq=100kHz. The INA does not only react to a i2cdetect, but also can be read out using address 0x43, so it's not an error due to scanning I2C addresses.

What could be the root cause for this? When exactly does the INA adjusts its adress? Must there be an idle time before accessing the device after a previous I2C communication?

Any help appreciated

Harald

P.S. Datasheet reads "secondary I2C address". What does that mean? Is that just the regular I2C slave address?

  • 0
    TI__Mastermind 30820 points

    Hi Harald,

    You’re correct - "secondary I2C address" simply means “I2C slave address”, they are the same thing.

    There is an additional requirement when using SDA as an addressing option, please see below statement:

    Regards, Guang  

  • 0 in reply to Guang Zhou
    Genius 3060 points

    Hy Guang, thanks for your quick response.

    We did see this section of the data sheet but did not pay attention to it. 100ns corresponds to 10Mhz, right? As we have only 100kHz SCL clock, every bit is 10us anyway, so we don't care about 100ns. Right? However, we use a RaspberryPi and do not have any influence on bit timing of I2C. Or do I need to prolong single bits in I2C?

    Regards

    Harald

  • +1 in reply to Harald Ilg
    TI__Mastermind 30820 points

    Hi Harald,

    The 100nS is referring to data setup time, it is independent of cycle time:

    Regards, Guang  

  • +1 in reply to Guang Zhou
    Genius 3060 points

    Hy,

    this seems kind of strange to us, but it works: As we use a standard SBC (Raspi) we cannot influence bit timing of I2C. Bit banging does not seem to be a reasonable alternative. So we add a RC to SDA line:

    Of course, signal appears ugly, but now address selection works.

    Is this how you recommend to handle this?

    Regards

    Harald

  • 0 in reply to Harald Ilg
    TI__Mastermind 30820 points

    Hi Harald,

    The ugliness is not seen by INA237, that’s all that mattersBlush

    Thank you for confirming.

    Regards, Guang  

  • 0 in reply to Guang Zhou
    Genius 3060 points

    The party was too early. Of course, when connecting more devices to the bus (that is why we do all this) I2C does not work any more as a result of a too high capacitive load. Unfortunately, as we use a raspberry pi as master we are not able to lower the I2C clock frequency. So at this moment we do not have a solution.

    We have tried some combinations of pull-up resistor and "delay" capacitor but do not find a working combination. We have an overall of 21 I2C devices, 7 of which are INAs. Any hints?

    Regards

  • 0 in reply to Harald Ilg
    TI__Mastermind 30820 points

    Hi Harald,

    There are still 9 addresses if SDA is not used. Can you choose 7 out of these 9? These options don’t have the same timing restriction.

    Regards, Guang