9
\$\begingroup\$

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.

\$\endgroup\$
  • 2
    \$\begingroup\$ what is your trigger? \$\endgroup\$ – markrages Aug 17 '12 at 18:55
  • \$\begingroup\$ @markrages the trigger is set at 1.48V on CH1 - rising edge. \$\endgroup\$ – Saad Aug 17 '12 at 18:59
  • 2
    \$\begingroup\$ One guess is that the uC (my assumption) that generates the SPI clock signal is using a PLL that works by shortening or lengthening some clock cycles to keep itself locked to the reference. When those short or long clock cycles come along it generates jitter on your scope trace because the edges you're looking at come earlier/later relative to the edge you triggered off of. \$\endgroup\$ – The Photon Aug 17 '12 at 19:03
  • 1
    \$\begingroup\$ Or the SPI is generated in your main loop, but sometimes there's an interrupt that delays executing the main loop, so again you see differences in the period of the loop. \$\endgroup\$ – The Photon Aug 17 '12 at 19:06
  • 2
    \$\begingroup\$ The word is "jitter", but you may say "shiver" ;-) \$\endgroup\$ – stevenvh Aug 17 '12 at 21:03
6
\$\begingroup\$

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

\$\endgroup\$
  • \$\begingroup\$ I have a 100nF bypass cap. on every vcc/gnd pair on every chip. Would you still suggest more? If so, additional 100nF or 1uF caps? \$\endgroup\$ – Saad Aug 17 '12 at 20:37
  • \$\begingroup\$ If this jitter is the worst performance "problem" on your board, no need to change anything. Depending how many other circuits are in your system and what they're doing, a few additional 1, 10, and/or 100 uF bypass caps spread around the board are a common design practice. These aren't localized to a specific chip, they provide "bulk" bypassing for the whole board. \$\endgroup\$ – The Photon Aug 17 '12 at 20:59
  • \$\begingroup\$ Yes, I have two 47u tantalums on the board for this purpose. So I should be ok on the bypassing part. \$\endgroup\$ – Saad Aug 17 '12 at 21:01
  • 2
    \$\begingroup\$ SPI is fully synchronous. No amount of jitter will cause SPI to fail. \$\endgroup\$ – markrages Aug 17 '12 at 22:03
  • \$\begingroup\$ @markrages, in OP's situation, that's true. In principle, though, a really extreme amount of period jitter could, for example, reduce the interval between the rising edge and falling edge enough to violate the set-up time of the slave part, and cause the interface to fail. The jitter would have to be equal to nearly half the clock period for this to happen, though. \$\endgroup\$ – The Photon Aug 18 '12 at 17:04
6
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Will try it with an external oscillator as soon as work opens! \$\endgroup\$ – Saad Aug 17 '12 at 19:46
6
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Steven, could you explain why the trigger's position matters? How did you get the 0.5% figure? \$\endgroup\$ – Saad Aug 18 '12 at 20:51
  • 2
    \$\begingroup\$ @Saad - The trigger point is time = 0. What's shown on the display happens 1.78 us = 1780 ns later. And the 10 ns jitter (more or less) is the variation of that 1780 ns, so 10 ns/1780 ns = 0.56 %. It looks so bad because it's zoomed in on that falling edge, but the reference edge (the trigger) will be tens of meters to the left. So if you would zoom out so that you get the full pulse in view the jitter will look a lot smaller. If the trigger point were just left of the display, say at -100 ns, then the 10 ns jitter would be 10 %. \$\endgroup\$ – stevenvh Aug 20 '12 at 5:37
1
\$\begingroup\$

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

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.