Can multiple I2C peripherals interfere with one another?

[ESpra.1]

I'm working on a device that uses two DRV2605L chips, connected to an STM32L552ZET6Q via I2C and configured for LRA PWM mode (PWM provided by STM32 to provide a constant, varying level of vibration in LRA motor), as well as two BNO055 chips configured for IMU+ mode and using an external crystal oscillator. The DRV and BNO both work as expected in isolation, but running the BNO at the same time as the DRV seems to disrupt the I2C signal on its way to the BNO.

The STM32 and the DRV are both on the same board, but the LRA motor and the BNO are on a separate one, connected to the main board via an 8-pin cable, so it's possible that the signals used to control the motor are corrupting the I2C commands heading to the BNO055?

I'm still working on gathering more information and testing different scenarios to narrow it down, but I figured I'd bring it up now in case anyone had encountered something similar

[Tesla DeLorean]

I2C slave device might have their own set of issues.

Speed of the bus should be dictated by the slowest rated.

Off-board, I'd watch for effective grounding, and that the bus termination is suitable. Consider topology and capacitance.

Check signal integrity with a scope. Noise in general, and then that the zero level isn't unduly high.

A logic analyzer can perhaps capture/decode interaction, and you can trigger based on observing issues on the host side.

[MM..1]

You write use two DRV you mean on one I2C bus? This isnt regular maybe same BNO

The DRV2605L slave address is 0x5A (7-bit), or 1011010 in binary

Second where you place pull up rezistors and how values on how speed?

[ESpra.1]

I'll give it a recheck. I also forgot to add that there was a previous version of this device that used Raspberry Pi and an I2C multiplexer to control all this. Also, the PWM output was provided by an Arduino Pro Mini. That version didn't have these issues.

I also just confirmed that if the DRV2605L is put into standby prior to setting up the BNO055 (and remains there) the BNO can communicate just fine. What's more, it seems that whenever the DRV starts transmitting, even if there's no vibration, it looks like the signal isn't reaching the BNO. Still, it's weird to me that this wasn't an issue on the RPI version.

 I'll see what I can find on the logic analyzer, though if the problem is happening in the cable, that might be harder to diagnose

[ESpra.1]

No, each I2C device has its own bus (4 in total in use when the board is running at full steam). The BNO055's bus travels between two boards via an 8-pin cable, which also houses grounding and the two leads used to control an LRA motor that's also on the same board as the BNO

[ESpra.1]

Okay, the logic analyzer definitely showed me something. It looks like I was right about something related to running both of them at once is causing the signal to get corrupted.

Here's what it looks like when run successfully:

And here's unsuccessfully:

Additionally, I can confirm that the addresses are being messed up. Once again, successful example with the DRV placed in standby mode:

and unsuccessful with the DRV enabled, but providing a signal for no vibration: 

[MM..1]

STM is master from functional graph seems as you implement sw I2C not hw.

9-th ACK CLK is extremely delayed and analog signals seems your pull ups is weak.

[Tesla DeLorean]

What's the pull-up?

Looks to need to be more aggressive. I'd probably start with 2K7 and move to 1K5

Slaves should generally not be interfering with SCL, selected/active or not

[ESpra.1]

Current pull-up is 10k (obviously way higher than your suggestions). For some reason, I remember using something smaller, but that must have been a different project.

Any other suggestions while I'm making the adjustment?

[ESpra.1]

This is all wired and on I2C. It doesn't look like the I2C signals going to the DRV2605L are getting in the way of the I2C signals going to the BNO; all the I2C commands that are used to initialize/configure the DR2605L for LRA PWM mode are sent before the ones used to initialize/configure the BNO055.

However, while the BNO055 is being configured, the DRV2605L will start running the LRA motor based on a PWM signal from the STM32L5 unit, and this is when the I2C signal heading to the BNO055 goes all wonky (see images 2 & 4).