Electronic – Why do some of the signals ‘shiver’ (have jitter)

signal integrityspi

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.

enter image description here

enter image description here

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.

enter image description here

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.

Best Answer

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).