• State Suggested Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 73 subscribers
  • Views 3687 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 129886
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Crash on connecting second I2C module

Aurabindo

Hi,

I'm connecting two I2C modules : MAX30102 and MPU-9250

I can individually communicate with either of these modules and they work okay. But if I connect both of them together on the same bus, only the MAX30102 works. The other module fails to communicate. I see the following on the Logic Analyzer:

image description

I flashed again, and I get a different behaviour:

image description

There is a small pulse in the SCL line towards the end. If I reset the board, I get a mix of ACKs and NACKs for write to different registers, but no consistent communication:

image description

The MAX30102 module has an inbuilt level shifter, and it pulls the I2C bus to VIN, which is 2.8v coming from the NRF52-DK. But MPU9250 module did not come with a schematic, but I'm assuming it to be pulled up to 2.8V itself, since its VIN is the same 2.8V from NRF52-DK.

If I disconnect SDA/SCL of MAX30102, then MPU9250 start communicating consistently. Could anyone point out why the communication is inconsistent ?

  • 0

    There is a picture of a schematic for you MPU9250 module in your link. It shows that there is a 3.3V voltage regulator between Vin and the MPU. There is likely a voltage drop across that regulator that could make life difficult for the MPU. I suggest that you short the solder bridge next to the regulator to bypass the regulator and make sure that power the MPU directly from Vin.

    asd

    These two spikes are quite weird though. Do you know where they come from?

    Are you using your own code? Have you tried a simple example to test basic functionality?

  • 0

    @martinbl I got a clue whats going wrong. I shorted the solderbridge as you suggested, and looked into the bus. I am (EDIT: not to now) now consistently getting the spikes in CLK line: mpu9250_clk

  • 0

    So its on rising edge of data that I get this spike on clk, and the I2C interprets this transaction as an ACK for a write to 0xEC, as per the logic analyzer. What would the cause for this interference? I'm using a breadboard,so there are quite a lot of wires running around. I also notice that my flash chip connected to the system is giving wrong device ID values. Its definitely interference. But how to figure out what exactly is the problem ?

  • 0

    I suppose a lot of wires would rather introduce a lot of extra capacitance and slow down rise and fall times, not introduce weird spikes. Is it possible to increase the sample rate of your logic analyzer? I can see there are small bumps in the signal below the spikes, but I think it is weird that it registers as a logic 1. It is also really weird that the spikes jumped from the data to the clock signal when you shorted the solder bridge. What I2C addresses are you using? And what device ID does your flash chip return?

  • 0

    @martinbl I was using slower sampling rate earlier. So it is possible that shorting the traces did not contribute to observation. I just got success communication to both of them together, after splitting the jumper wire that was connecting SDA & SCL. I think I really need to get them all on to a custom board!

Related
Terms of service