Why do some of my signals 'shiver' (have jitter)?

Question

I have a 2 MHz SPI bus but one thing I've noticed that is that some of my signals often 'shiver'. Yes my trigger is setup properly so I don't think the issue lies there.

You can see what I mean here: (this is with persistence mode on). This is the clock of my SPI bus.

The SPI does work fine. I've transferred hundreds of megabytes on multiple boards and haven't seen an issue so far. But I'm still interested in knowing what could be the issue here. Also, should I bother fixing it even it works?

The measurements were taken right at the source with a VERY small ground clip.

This is a simplified schematic of my circuit. Of course the board has more SPI devices but for the purposes of this question this is accurate because the board has nothing soldered onto it yet except the uC and the SD Card.

The master (AVR Mega 128) is running off it's internal RC oscillator - I don't know if this would be relevant but since the signals shift in time it's possible that the RC oscillator's jitter is also ending up in the SPI bus. Just thought I'd mention it. It also occured to me that during these measurements I ran the controller in an infinite loop. Here's the code:

while(1)
{
    setFirstBitOnDriver(driver); // this sends a 8-bit command on the SPI bus.
    GLCD_SetCursorAddress(40); // Change cursor position on the display.
    GLCD_WriteText("LED: "); 
    for(wire=0;wire<72;wire++)
    {
        itoa(wire+1,str,10);
        GLCD_WriteText(str);
        GLCD_SetCursorAddress(44);
        _delay_ms(10);
        shiftVectorOnDriver(driver); // another command on SPI. 8-bit wide.
    }
}

The jitter/shiver could happen when the internal runs for 72 times and then exits. Since it takes an additional time to execute the first three lines it could be that every 73rd waveform arrives at a slightly different time due to the additional processing time. If I had to bet, I'm guessing this is the cause of my issue (if I could, I'd confirm it this instant but my boards at work and the next week is off!) But I'd still like opinions/answers of SE on this matter.

But considering the uC is running at 8 Mhz I don't jitter due to software would be because in nanoseconds but rather microseconds. But in the 2nd figure a flat line is visible. This occures for a very brief second where the entire waveforms shifts in time and is invisible on the screen. I'm guessing that this is due to the loop and the jitter in the first picture is due to the RC oscillator.

Answer 1

What your scope shows is a classic example of jitter, which means an error in the timing of an event (rising or falling edge), independent of whether there's any voltage noise on the signal.

But what can cause the jitter in your system?

• As you speculate, if the uC main clock is jittery that jitter will most likely transfer directly to the clock output from the SPI peripheral.

  Inadequate bypassing (you should have additional bulk bypassing on your board in addition to the two 100 nF capacitors you've drawn) could lead to jitter in the uC clock circuit.

  Power supply noise introduced by other circuits on your board could also have this effect (but would be reduced by more bypassing).

• The jitter could be inherent in the performance of the uC's SPI peripheral. It has to generate the SPI clock with reference to the system clock. If it uses a simple divider (4-to-1 in the case of 8 MHz system clock and 2 MHz SPI clock) you wouldn't expect to see much added jitter at all (though system clock jitter would pass right through). But if it uses a more complex scheme, like a PLL, that circuit could be varying the SPI clock pulse widths to keep in sync with the system clock, and you would see that as jitter. A PLL circuit could also be particularly sensitive to power supply noise.

If the jitter amplitude is limited to a small fraction of the clock period, as it seems to be here, there's no reason this jitter will cause errors on the SPI bus (in agreement with your observation that the SPI bus appears to work as expected).

Answer 2

This looks like signal jitter to me. The clock period is minutely varying, enough that the persistence of the scope is making the edge look 'smeared'.

I don't know if your Rigol scope has the capability of calculating statistics when it measures. If it does, you can adjust your trigger point so that your trigger edge appears on the left edge of the screen, adjust the timebase to show a complete period and measure the frequency variation over time to get a feel for the variation. (Jitter can look worse than it is when the trigger edge is offscreen.)

If you want to narrow down the sources of jitter, I'd start with the RC oscillator. See if you have an option to use a different clock method (like a crystal), implement it and remeasure the jitter.

Answer 3

Scope images can be misleading, and you have to look at all the parameters to interpret the data correctly. The first image shows a 10 ns jitter, and that would not be so nice if the trigger was just at the left off screen. But bottom right it says trigger + 1.78 µs, so that 10 ns is actually only 0.5 % of the time interval. That level of jitter may well be due to the RC oscillator. Expect the jitter to be reduced by at least one order of magnitude with a crystal oscillator.

You say you haven't met any problems yet in the SPI data transfer. That's thanks to the relativity of the 0.5 %. If you would MOSI 1 µs before the CLK pulse the 0.5 % jitter will cause a 5 ns jitter, this is not going to violate setup and hold times.

If you need reassurance just set the timebase such that you can see a complete bit time, both the MOSI and CLK channel. You'll notice that the jitter will be hardly visible, and that the successive edges remain well separated.

Answer 4

Jitter is a form of noise. If you consider the inter-arrival times between the edges of pulses to be a kind of signal, then if those edges do not jitter whatsoever, it means that your system exhibits a noise-free signal!

Square waves are often generated by thresholding on a more continuous wave, with some Schmidt-trigger type circuit that has hysteresis behavior. Crystal or RC oscillators do not "natively" put out square waves.

So, if that input wave has some voltage noise on it, that noise will translate to slight shifts in the triggering, as the voltage reaches sometimes reaches either threshold sooner and sometimes later.

And thus, noise of one kind (voltage noise) turns into noise of another kind (timing noise).