1
\$\begingroup\$

Part number: INA228 from Texas Instruments
MCU: msp430fr2433

I initially brought a current sensor from Adafruit that used an INA228 chip. After some challenges, I managed to get the I2C communication going and was able to read data from the registers. I cleaned up my code and made a custom board that has 16 of these sensors.

I only soldered one of the INA 228 sensors on my custom board and am trying to see if I can read the registers using the same code.

For some reason, my code works on the Adafruit sensor but not on my custom board. Not sure why. I scoped the I2C lines using a logic analyzer. I have attached the captures to this message and also listed the data being transmitted below. Can anybody please explain what I missed on my custom board here?

Working data stream: Start -> 0x40 Write (slave address) -> ACK -> 0x06 (temp register) -> Stop || Start -> 0x40 Read -> ACK -> 0x0B -> ACK -> 0xC8 -> NAK -> Stop

Here clearly the data from the register is 0x0b, 0xC8. This translates roughly to 23.56°C. This works. No issues (I think).

Not-working data stream: Start -> 0x40 Write -> ACK -> Stop || Start -> 0x40 Read -> ACK -> 0x00 -> ACK -> 0x00 -> NACK -> Stop

|| represents a small pause.

Why is the master not writing 0x06 (register to read) in the custom board case when I am using the same code? Why is the SDA line always low? Is this a hardware or firmware issue?

Not-working logic analyzer capture: enter image description here

Working logic analyzer capture: enter image description here

Circuit: enter image description here

Adafruit sensor: Adafruit sensor

Working scope captures: enter image description here enter image description here

Not working scope captures: enter image description here enter image description here enter image description here

Note: The working board had 4.7 kΩ pull-up resistors. I tried 4.7 kΩ, 24 kΩ, and 2.4 kΩ pull-up resistors, but none of them worked so far. I'm not sure if it's even a pull-up resistor thing.

\$\endgroup\$
14
  • \$\begingroup\$ There is nothing to work on. No code, no hardware schematics, no even mention of the used MCU. Can you provide all details, such as schematics, PCB layout, code, etc, maybe cabling if the chips are not on same PCB, and so on. It might be an issue you can't see with a logic analyzer, but an oscilloscope would reveal it immediately. \$\endgroup\$
    – Justme
    Mar 14 at 19:41
  • \$\begingroup\$ The code works on the adafruit sensor so I figured its not the code. I am looking for an explanation based on the scope captures. Adafruit and custom board have the same circuit and the MCU had the same code. Works for one bit doesn't for other .. Added circuit and MCU details \$\endgroup\$
    – varun
    Mar 14 at 19:43
  • 3
    \$\begingroup\$ @varun - Hi, Those images are labeled "scope capture", but they're not - they're logic analyser captures, so they are hiding all the analog detail in the signals. :( From experience, that is the level which needs investigating, in situations like this. Can you capture & provide real scope traces of the working & not working I2C buses, or do you only have a logic analyser and not a scope? \$\endgroup\$
    – SamGibson
    Mar 14 at 19:49
  • 1
    \$\begingroup\$ @varun : the "scope" mentioned is an oscilloscope, not a microscope. An oscilloscope will show you (analog) voltage as function of time, while the logic analyser will show you only "high or low" as function of time. So the oscilloscope gives far more information (while the logic analyser is simpler to interpret once you are sure the signal is correct at analog level) \$\endgroup\$
    – Sandro
    Mar 14 at 19:57
  • 1
    \$\begingroup\$ @evildemonic But same code works with Adafruit sensor. My guess is, there is a hardware error, maybe in design, and the provided very small piece of schematic does not show that, or it's a PCB design or manufacturing issue, or a soldering issue, or a broken/missing component somewhere else. \$\endgroup\$
    – Justme
    Mar 14 at 20:36

1 Answer 1

6
\$\begingroup\$

It's particularly visible in the last osciloscope trace - you can see that the rising edges are very rounded, and don't actually reach their full height. This is generally because either the bus capacitance is too high, or more likely the pull-up resistor values are too weak. Bus capacitance will increase with each device you add.

You mentioned a few pull-up values, and the schematic shows 10kΩ... Try a lower value, the lower the better... 1.8kΩ should still be safe.

The open-drain nature of I2C means that the falling edges are good and sharp / fast, but the rising edges are entirely under the control of the pull-up resistor.

The following annotated version of your photo shows the "high" level (looks like ~3.3v, drawn in red)... none of the clock or data signals reach this level, and likely only briefly reach above the input threshold value for a "high" signal.

Additionally, you can see the significant delay in the signal (drawn in green).

annotated version of OP's photo

The MSP430FR2433 datasheet outlines the characteristics of the part - see Section 5.11.4. This lists the positive going threshold for VCC=3v at somewhere in the range VCC×0.45 to VCC×0.75 (you're probably using 3.3v, but this should extrapolate apprixmately enough).

The SDA signal probably is crossing this threshold, but it's doing so far too late. Note how the working trace is much more "square".

excerpt of the datasheet, showing the positive input threshold voltage at between VCC0.45 to VCC0.75

To further emphasise the point - as pointed out by @Jens in the comments, the "working" trace has a clock speed of ~350 kHz, but the "not working" has a clock speed of only ~225 kHz... if the code is indeed identical as you claim, then this is quite likely due to the controller percieving "clock stretching" due to these slow rising edges.


Edit: You've mentioned that you have 16x devices on this bus, which may be accounting for the extra capacitance... It could be worth looking into a "rise time accelerator", which will help to bring the lines back up more quickly, without making the pull-up resistors too stiff.

screenshot showing an accelerated rise time, vs an unaccelerated rise

\$\endgroup\$
6
  • \$\begingroup\$ The pull-up resistor was the issue. 1.8k was also too high. The clock rise time was 420 nsec for 1.8K pul up. The rise time should not exceed 300 nsec according to the INA228 sensor. So I tried 1K pull up and it worked. The rise time now is 235 nsec which is under the limit. Thank you all for your help. \$\endgroup\$
    – varun
    Mar 18 at 21:42
  • \$\begingroup\$ I'm glad it's working, but I'm intrigued - that sounds quite low... have you identified anything that could be increasing the capacitance of your bus? (lots of devices, large/long traces, etc...?) \$\endgroup\$
    – Attie
    Mar 18 at 21:48
  • \$\begingroup\$ Not yet. We currently have 16 slaves connected to this custom board because this sensor supports 16 unique addresses. The increase in the number of slaves likely led to an increase in bus capacitance. When we had just one slave, a 4.7k pull-up resistor worked effectively. In my next revision of the board, I plan to reduce the bus length to mitigate capacitance issues and experiment with higher pull-up resistor values to optimize performance. \$\endgroup\$
    – varun
    Mar 18 at 22:01
  • 1
    \$\begingroup\$ It might also be worth looking at using a "rise time accelerator", which will help improve the rising edges, without making the pull-up values too stiff. \$\endgroup\$
    – Attie
    Mar 19 at 0:04
  • \$\begingroup\$ Thank you so much, Attie. I'll look into it. \$\endgroup\$
    – varun
    Mar 19 at 19:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.