# Is it normal to have SPI Clock with varying duty cycle?

I am working to get an SPI interfacing radio module on embedded Linux system. This particular module (RFM12B) is already ported onto Raspberry Pi. Now I am working on OMAP4 based systems.

I noticed that on Raspberry Pi, SPI Clock generates steady 50% duty cycle. On my OMAP4 boards, it varies between 2 or 3 values. The values in the screenshots are: 33.3%, 42.9%, 40.0%, and 42.9%. My logic analyzer is measuring at 16MHz, while the SPI clock run a little over 2MHz.

I am simply sending random text like below:

echo "HELLO!!" > /dev/spidev1.0


I am very puzzled because I think this might be causing buffer overflow and underruns - eventually getting CRC16 failure on the receiving end.

-
If the OMAP4 has no hardware SPI exposed, then it is probably generated in software by the SPI driver and this will cause jitter. The duty cycle really is not important as long as the maximum frequency supported by the slave is never exceeded. –  Hanno Binder Jun 17 '14 at 15:59
OMAP4 seems to have a hardware implementation of SPI. They call it the Multi Channel SPI (McSPI). I guess either RPi has a better implementation or it's enough to have less than 50/50 clock for reliable SPI communication. –  b1gtuna Jun 17 '14 at 17:06
There is likely no varying duty cycle, you are misinterpreting your Saleae Logic. –  shuckc Jun 17 '14 at 18:55

You see aliasing in your capture, not clock jitter - a case of the wrong tool for the job.

A 2Mhz clock has a 500ns period, so is high for 250ns. With a 16Mhz logic analyser you are taking samples every 62.5ns, so ideally you'd see 4 high samples, 4 low samples repeating.

Now consider the effect of a minuscule 0.5% difference in frequency on the CPU oscillator, so the divider network down to the SPI bus now runs with a 251.25ns period. Note: the frequency doesn't drift over time, it's still an ideal crystal, but the waveform we're trying to capture is no longer an exact multiple of the capture clock 62.5ns. This gives you aliasing with patterns of 4/4, 3/5, 4/4, 5/3,... as the hi/low ratio in your capture as you observe the phase relationship between the two clocks drifting in and out.

Your analyser is still good for capturing the SPI signals (above Nyquist etc), but it is not suitable to judge clock stability. For that, use a scope triggered on one edge to see the stability of the other edge and a calibrated frequency counter to check the absolute frequency.

-
I did the same on RPi, and I get really good 50/50 split. It was the same 2MHz clock. So I don't think my analyser is aliasing the signals. –  b1gtuna Jun 17 '14 at 20:08
@b1gtuna - You're missing the point, which is very small variations in the clock frequency (0.5%) can cause this kind of aliasing. That kind of variation is very common in things like this. I expect if you sampled the rPi for long enough, you see the same behaviour. –  Connor Wolf Jun 18 '14 at 0:05
@b1gtuna - I think Connor is right, this looks like aliasing to me. A logic analyzer is not designed to sample a clock, it is designed to sample ON a clock edge. You should use a scope instead. –  Mark Lakata Jun 18 '14 at 7:18
The closer the frequencies are to an exact multiple the more output you need to view to see a non 4/4 sample - mismatches occur at the beat frequency between the two clocks. –  shuckc Jun 18 '14 at 15:20
Another vote for aliasing from me. I've seen the same thing happen and increasing the sample rate has cleaned it up. –  dext0rb Jun 18 '14 at 15:21

Since SPI is a synchronous protocol the exact frequency at any one point in time really doesn't matter. Everything is keyed to the edges of the clock, so the exact timing between edges really doesn't matter - within the limits of the device of course.

-
Is there a reason why we'd prefer varying clock to a constant 50/50 one? –  b1gtuna Jun 17 '14 at 15:41
It can be more difficult to create an accurate 50/50 clock (for instance when the SPI is bit-banged, or runs from a low-priority interrupt), and when speed is not a big issue it has no advantages, so why bother? –  Wouter van Ooijen Jun 17 '14 at 15:47
Agreed. You don't need one, so why waste the additional time, resources, and ultimately money, in generating one. –  Majenko Jun 17 '14 at 15:49

There are a number of ways in which SPI signals may be generated. In some cases, a device will hardware which can be instructed to send the contents of a certain range of memory out to the SPI port without processor intervention. In such cases, there will generally be a uniform sequence of clock pulses, though it's possible there may be a "pause" after every eighth. In some cases, a processor will need to load each byte into a shifter which is capable of accepting at least one byte "in advance" of the one being shifted. The output in those cases will often look like that from the pure-hardware case, except that there may occasionally be random gaps after multiples of eight clocks if software occasionally fails to load the next byte before the present byte gets shifted out, but depending upon the processor's timing that might never occur. In the above cases, use of delayed-trigger functions on a scope may be helpful when examining regularly-formatted data, because everything will always (or almost always) happen at a consistent time relative to the start of a frame.

Things aren't always that nice, though. It's pretty common for devices to have hardware that can send out 8 bits automatically, but require software to wait until one group of 8 is sent before enqueueing the next. This creates groups of 8 regularly spaced clock pulses, with random amounts of space between them. This often precludes use of delayed-sweep functions, but on the flip side often makes identification of the start and stop of each byte easier than it would be if all pulses were uniform. The final possibility is that software may be generating an SPI signal by using a sequence of "set port high" and "set port low" commands. That is what appears to be happening in the sample above.

In most cases, the master device on an SPI bus (the RasPi in this case) is free to use any mixture of long and short pulses it sees fit, subject only to limitations on certain minimum pulse timings and, occasionally, maximum pulse timings which are often orders of magnitude above the minimums (e.g. a device may have a minimum pulse width and pulse separation of 250ns each, but a maximum time between pulses of 1ms--more than three orders of magnitude difference). Provided that pulse times stay within the very broadly drawn limits (and in many cases there would be no maximum limit) communication should be reliable.

The only time data loss is likely with SPI is when the slave device is a processor. The SPI slave hardware built into many CPUs requires that when a byte arrives, the processor must act before the master starts to send the next byte to avoid data loss, but provides no means by which the slave can tell the master it's ready; consequently, slaves often need to either use five lines to communicate with the master (clock, MOSI, MISO, CS, and a manually-implemented "ready" line) or else require that the master add a delay after each byte sufficient to accommodate the worst-case response time of the slave.

-