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

[ESpra.1]

Yeah, that seems so. the pullups for the I2C bus are both 10k ohm, and the speed settings are 100kHz and standard mode for speed. Other options for speed more are Fast Mode and Fast Mode Plus

[MM..1]

Image 2 show you have some issue short circuit between close pins wires or....

Primary change all R to 2k7

and show code.

[ESpra.1]

Just to make sure, both of these units are attached to PCBs and work on their own. I'm not removing the DRV from the circuit entirely when I'm getting the working data from the BNO055, I'm just forcing it to stop transmitting a signal to its attached motor, and the motor connections aren't being broken either. The DRV works whether or not the BNO is running, but the BNO stops working when I allow the DRV to send a signal of any kind to its attached motor, so I don't think this is a case of a short circuit. That said, they are both going into a cable that has eight lines on it (so, 1 for scl, 1 for sda, 1 for LRA +, 1 for LRA -, 1 for powering the BNO, 1 for ground, etc), so the signal for the motor and the signal for the BNO are both in very close proximity.

[MM..1]

DRV and BNO is BGA / SIP package short circuit under package, sometimes dont block start working one IC, but ... Your scoped signals say it

[ESpra.1]

Okay, but I'm literally not changing the hardware in between these two images. I'm not disconnecting anything. All I'm doing different between those two images is writing an I2C command to the DRV that puts it into standby mode, so it isn't transmitting anything.

while it's in standby mode, I can configure the BNO055 and have it transmit all the data I want. I'm getting acceleration, gyro, euler and quaternion data that I'm passing into a string and printing over serial to Tera Term, and I can confirm that the data is all correct. I know it's working and I'm not changing the hardware to make it do so. It's only when the DRV is active mode and outputting a signal to the motor that I start seeing that fuzzy analog signal and the BNO055 commands start getting their address corrupted, according to the logic analyzer.

Furthermore, I can confirm that if there is a short, it isn't on BNO's side of things. As mentioned to Tesla, there's an older design that uses RPI and is using not just the same design, but the same units that I'm working with now, and it worked fine.

[Tesla DeLorean]

Don't reply to bots, sub-posts will get deleted if the post you're replying too gets deleted.