My Blog‎ > ‎

Ghost capacitance on data bus can haunt your project

posted Dec 11, 2012, 12:10 PM by Pratik Panchal   [ updated Apr 1, 2013, 7:47 PM ]
11th December, 2012, @desk.

So, lately, I've been working on developing the I2C message protocol to create a feeling of 'brotherhood' among the sailors on the ship - Uhh, I mean, chips on the board. And to plunge myself directly onto it, I got a ready-made board with a 32 bit PIC and an EEPROM from Atmel. I did not waste time on going over the hardware schematics (no reason, right), and initiated the development process straight away.

As a habit, I developed a minimal amount of framework - a skeleton, perfectly in line with the message protocol and the hardware datasheet - just to verify, that I was seeing, what I was imagining. But to the disappointment, I saw something weird going on the bus:


This was just terrible. There weren't sufficient clock pulses (9, to be precise) on SCL, the data wasn't authentic on SDA, the frequency had an error of 17%, and the duty cycle was not 50%. And the worst part - this wasn't consistent. The pictures were changing with each run.

Now, before plunging into my own development, I had tried the firmware from Microchip - and that was working perfectly okay at 8Mhz frequency. Although, I was trying to develop with PLL on, at 80 MHz, it didn't seem to be a problem - since the datasheet mentioned the usage of frequencies above 40Mhz, which was not possible, without using PLL.

So, the problem seemed like the PLL - with it being ON, things were messed up; and without it; at raw crystal speed of 8Mhz, things were good - life was pretty.

With this I spent full 2 weeks, trying to figure out the workaround - contacted Microchip guys, asked for simple sequencing code, did lot of signal analyzing stuff - and the presence of random spikes, on SCL lines, every now and then was just annoying and painful.

Nonetheless, at the end of the week, I realized, I had spent way too much of time on this - I decided to pull myself out, and look at the picture from the distance. I thought of isolating the big guy PIC from the bus and see what's going on, on the pins - just to eliminate the possible causes of interference from other devices on the bus - pull-ups and the EEPROM. Since the board was multi-layered, and traces hidden below a laminate layer, the only option I was left was to was to physically force-out and lift the pins off the board. SMD components could strains your eyes, especially when the pins you want to force out are in middle of the array of 25 other pins. But, fortunately, a microscope came in handy and this point and the operation was successful. I then re-soldered two thin wires at the pulled-up pins, and fetched them to a safer distance. I connected two external pull-ups on these lines and hooked them to the logic analyzer.

The result was astonishing. The protocol was perfect!! The devil was hiding somewhere on that bus on the board! The first thing that came to my mind was to see the capacitance between the lines, and it was of a fatal value of more than 100 microFarads!! I didn't knew what was causing that high capacitance (poor board layout? foreign particle somewhere in between the tracks? who knows?), but I immediately isolated the whole bus from the board. The protocol seemed to be flowing perfectly now.

But, the thing that bothered me was, that, how the heck did the protocol able to maintain sanity with 8Mhz clock and PLL on?; you see, the output on the I2C bus clock line remains 100kHz irrespective of its source input. Somehow, in this situation, it seemed apparent that, the switching on PLL caused some kind of signal degeneration, which in-turn reacted adversely with the bus capacitance to produce those bus lags and waveform deterioration. I tried to see the difference between the waveforms under both scenarios; but couldn't catch anything big. 

I hope it doesn't remain a mystery unsolved.
Comments