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

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.