PIC I2C slew rate

[Ciupi]

Hello to everyone !

I am currently working on a portable radio project using TEF6686 and PIC18F26K22 and a serial LCD module EADOGM 132.

My issue is as follows:

If I try to read data from the TEF6686 on I2C bus, I can hear the data transaction in the speaker on some certain signal level conditions.
On really weak stations there is no I2C bus noise, on strong stations there is no noise. Only on some intermediate signal level, the bus activity can be heard and is annoying.
On AM band is really a disaster. If there is no bus activity, all gets quiet, but the problem is that I want to read signal quality and RDS data (on FM band) to print on display.

If I disable slew rate control then is really a mess. With slew rate limit on, there is some  improvement, but not too much.
Could this be a slew rate problem ?

I have seen some videos on youtube with people using Arduinos and they didn't seem to have this issue., even using breadboards with long wires going everywhere.
My circuit is made on a small PCB and layed out pretty well, I think.

Should I consider trying out some other micro ? I was looking at the 18F26K42 and that seemed interesting, it has some registers for configuring the I2C slew rate,
but I have no idea if that would do much.

What is your opinion, am I missing something ?

[TomS_]

Im no RF greybeard, but heres a couple of things I would try:

* Lower the speed of the I2C bus if possible, and if high speed is not required
* Run a ground wire along side the I2C bus between the PIC and the device(s) you are communicating with
* Perhaps try encapsulating the board inside a shielded (grounded) box
* How is the decoupling in your circuit? Each power pin of the PIC has a small capacitor on it? Also on the display itself
* Where does your board take power from? Perhaps the wrong point in a star ground? Can you take power from elsewhere in your system, somewhere much closer to the power supply itself?

As I understand it, slew rate, when enabled/disabled appropriately, can be used to slow down the edges of the I2C signal. I suppose fast edges could cause some noise (as you observe), maybe as emission from the wires themselves, or maybe disruption to the power supply?

What ever the problem, and no matter how far off I am, I'll be interested to hear what the solution is in the end. 

[AndyC_772]

It would be helpful to see a photograph of your project, specifically the way the I2C components are positioned, connected, powered and decoupled.

The strength of RF emissions depends on the edge speed (ie. slew rate), not the number of clocks/sec, so slowing down the data rate won't solve the problem. It might make the noise subjectively less bad, but each edge is still producing the same amount of interference. There just aren't as many of them per second.

The interference might be from the I2C bus itself, or it might be from the power supply. Bearing in mind that current always flows in closed loops, it might be worth taking a while to work out where the current loops are when the bus changes state. It'll be different for falling edges, which are actively driven by the PIC, vs rising edges that are passively pulled high. Falling edges are always much faster - and, therefore, noisier - than rising edges on I2C.

I2C isn't usually the source of problem RF noise, so there's probably something quite simple that can be done to silence it.

[Ciupi]

I already replied 2 times, but for some reason it didn't do anything... 

[Ciupi]

Ok, I'll try again... I think my files were too big, I'll post a zip file... 

As andy said, lowering the clock didn't help, only did things worse on AM bands.

The tuner and the PIC are powered from separate supplies and there are caps everywhere, so I don't think that's the issue, but who knows.

I have already posted a pic with the schematic, but it dissapeared.

Anyway I'll post again.

[AndyC_772]

Sorry, I'm not downloading a ZIP file from an unknown source. Basic IT security practice.

In any case, issues like this more often result from layout issues than from the schematic, so we really need clear photographs of your project in order to see where problems might lie.

[Ciupi]

Ok, I'll post pics.

[AndyC_772]

OK. Imagine a capacitor between the SCL pin of the display and its local GND, which represents the parasitic capacitance which must be discharged each time the pin is driven low.

The current path is from the SCL pin of the display, along the length of the SCL track, into the PIC, through the output driver to the GND pin, then back to the GND of the display via whatever route it can take through your GND pours.

Repeat the exercise for SDA, obviously. Also consider the current path which exists when those caps are charged up again when the bus goes high. Where does the current come from? Do you have a good quality, low ESL positive supply anywhere? What's the path from that supply to your display?

The radiated energy from a loop antenna - which is what you've constructed - depends on the frequency and the enclosed area. The frequency depends on the edge speed, so slowing down the edges can help. Maybe try putting 100R in series with SCL and SDA to form a low-pass filter. You should get away with this on I2C since it typically uses Schmitt trigger inputs, so a slow edge rate isn't really a problem.

The real problem, though, is that you've built a radio project without solid, unbroken power and GND planes. I cannot stress enough just how important these are.

With an unbroken GND plane, the current which flows in the SDL or SDA trace can (and does) return along the GND plane, following the path of the trace above it. The enclosed loop area falls, theoretically, to zero, and so does the amount of RF energy emitted.

In the practical (non-ideal) case there's still some noise, of course. The best GND plane you can make still has some inductance and isn't located right next to the traces on the surface, but it's still enormously better than any routed GND traces or chopped up copper pours.

You can improvise a GND plane with some copper tape on the back of your single sided PCB, but really the best solution is to use a commercially produced 4 layer board with solid power and GND planes.

[Ciupi]

The display is driven via software bit banging, but the problem isn't at the display.

The problem is at the I2C bus that drives the radio chip which uses the built in I2C module on pins 14 and 15. There are already some 220 ohm resistors in series with the tuner bus, also the tuner has internal 100 ohm resistors.

The display data lines are not a problem, even if I'm sending data continuously to the display, no noise is there, only if I send/receive data to the tuner module via built in I2C.
I also tried I2C bit banging, but with no considerable improvements. Playing around with various types of caps on the supplies didnt help either.
Also tried running a wire on different points on the ground planes, did not help.

So I don't know what it could be. As I said in the post, activating the slew rate control improves things a bit, and thats how it is right now, but I was wondering how do those guys using Arduinos with wires going everywhere do not have this issue, but in my case there are some problems. I was thinking maybe the slew rate control on this PIC isn't slowing things down enough and I should consider using another PIC or maybe something else like an atmega328 maybe...

Or, as you said, I should try building this on a double sided copper PCB and leave one side full of copper and see how it goes...

[AndyC_772]

It could be that every time the tuner receives an I2C command it'll generate an ACK, which causes ground bounce locally at the tuner's GND pin. In other words, it may not even be the PIC that's the noise source in this case.

Either way, it's nothing that a proper GND plane won't fix. Time spent looking elsewhere, when something that fundamental needs addressing, is not time well spent, IMHO.

[Ciupi]

It could be, I have taken that into account, but I was unsure, who knows...