I2C Noise Question?

[Craig]

Hi All

Compiler Version 3.7.3.6
I have a project using a Pic18F47K40 Device running on the Internal Oscillator @ 64Mhz with a I2C Device Running @ 400Khz. The I2C Device works correctly but, I am having noise on the I2C Bus which is causing Issues. The Problem is that I have a DRV8871 Motor Driver Chip Which Runs a 12Vdc Brush less Motor.
There is a 1_Meter Cable Connecting the I2C Device to the Main PCB Where the 18F47K40 is.
I have used 4K7 Pullups on the SDA & SCL Lines and have tried removing them and switching them off in software "Declare i2c_bus_scl On". This stops the
Interference on the I2C Bus but also causes the I2C Device to stop Working.

Everything works correctly but when the Motor runs then it is causing issues on the I2C Bus, There is only one device on the I2C Bus.

The DRV8871 Motor Driver Chip Uses PWM to Drive the Motor and I think This is causing Noise on the I2C Bus.
I have tried numerous Ideas to stop the interference, Declaring Slow Bus on the I2C (100Khz) , Twisting the motor wires together etc.

NB: I have this same project running on a Previous Version Using a PIC 18F47J53 @ 96Mhz With PLL Enabled and it works perfectly but, now that I have migrated it to the PIC 18F47K40 I am having this issue!
 
Any Help is much appreciated,Has anyone Got any ideas of how to Reduce and Filter the Noise on the I2C Line?

SSP2CON2.7 = 0                 ' Switch General Call OFF in the I2C
SSP2STAT.7 = 0                 ' Slew Rate set to Fast 400Khz for I2C   
CLKRCLK = %00000011            ' MFINTOSC Set @ 500Khz

WPUD    = %00000000            ' Switch OFF Weak Pullups on PORTD
ANSELD  = %00000000
LATD    = 0x00   
INLVLD  = 0x00                             
ODCOND  = 0x00   
 
$define I2C_SCL_Pin    PORTD.2                         
$define I2C_SDA_Pin    PORTD.1                       
Declare i2c_slow_bus OFF
Include "Software_I2C.inc"
Include "PPS_18FxxK40.inc"
Include "HPWM_modified.inc"

Regards

Craig

[flosigud]

Screening the motor wires might help. Better filtering on power supplies might also help.

[top204]

You seem to be twisting code in the snippet you provided.

There is no need to alter SSP2CON or SSP2STAT or any of the MSSP SFRs for software I2C, and they can actually cause problems if the MSSP is mistakenly enabled and the pins are set to use for it and not as general purpose I/O pins that software I2C needs.

The Declare I2C_Slow_Bus is for the compiler's, built in I2C commands and the procedures in the library code will not use it at all. To slow down the I2C in the library code, look for the delay that is implemeted in the read and write procedures, and increase the DelayUs value to slow down the I2C, and decrease the value to speed up the I2C.

With software implementations of I2C or SPI, the device type does not matter because all the code is doing is toggling standard I/O lines in correct sequences, and do not use any peripherals.

[Craig]

Thanks Flosi for your help. Thank you Les I will Adjust the times and add a bit more filtering to the Motor Driver and see how it goes.
Regards
Craig

[dnaci]

@Craig. You can lower the check up resistances. For example, it could be 2.2K. Is 1 meter cable shielded? I also suggest you to review the Glitch Filtering method;

https://www.ti.com/lit/an/slea053/slea053.pdf?ts=1619120782252&ref_url=https%253A%252F%252Fwww.google.com%252F

[top204]

The ferrite beads are a good idea, and I use them with I2C devices whenever possible on the device's VDD and on the SCL/SDA lines.

[okmn]

i usualy use common choke even for uart and vdd/vss

[LeonJ]

Thanks Flosi for your help. Thank you Les I will Adjust the times and add a bit more filtering to the Motor Driver and see how it goes.
Regards
Craig

Craig,

Try to "snub" the noise at the source before trying to keep it out of other circuits.
For that, it makes sense to determine the "mode" of noise i.e. radiated, conducted or induced or combinations thereof.
Remedy accordingly by either screening/decoupling/separating the culprit.

If the motor and PIC share the same power source, temporarily power them from separate sources and observe the effect.

Depending on how the motor driver works, it may be possible to add "freewheel" fast diodes across the motor. (similar to a back-EMF diode across a relay coil)

It is always good practice to decouple different devices on a single power source.

Leon

[Craig]

Thanks for all the feedback and help Guys!
I have taken the DRV8871 Motor Driver Chip Off the Board and It works perfectly. I will try putting it back again and adding in a few Ferrite beads to see if this filters out the Glitch on the I2C Line. I have not used chokes so this will be interesting to look into.

Regards
Craig