What is going on with these SPI transmissions?

Question

I just got a Saleae logic analyzer and I'm using it to hack a Guitar Hero drum set. The main board within the drum set talks to another sub-board using SPI. When I tap into the conversation, I see this:

Black is MOSI, Brown is MISO, Red is CLOCK, and Orange is ENABLE/slave select.

I notice two strange things going on here:

1. The clock doesn't always "run". It certainly has a pattern to it: It runs when ENABLE is low (every 100 Hz).
2. Even when ENABLE is high (which I assume to mean the slave is not selected), conversation between the master and slave occurs.

Does anyone have a guess as to what is going on here? Did the board designers get lazy, or did I do something wrong when capturing the data?

Details:

• Captured at 4 MHz
• The clock runs at 2 MHz, when it is actually running

Here is another view, zoomed in:

Obviously, neither of these pictures provide much information as to what is actually being "said", since I didn't zoom in far enough. But I think that they are enough to get my point across. If you want a different image, just ask.

EDIT

Kris suggested that the enable line is used to poll the slave board into sampling. This makes sense. Check out this screenshot:

The small black bubbles with red outlines are instances where the software was able to decode a SPI transmission. These only occur when the enable line is low, which follows what Kris suggested.

Answer 1

I believe the bus you're looking at simply has multiple slaves. They share MISO, MOSI and CLK but have dedicated slave select lines for each of them. The ENABLE signal in your waveforms is one of those slave selects. You can look for other slave selects on the master chip pins if you want to test this hypothesis.

Note how signals seem to change polarity from one slave to another (most noticeable in the clock). Maybe different slaves use different SPI modes.

The waveforms appear to repeat with a certain period which would indicate that the master queries slaves one after another in a loop.

Answer 2

Thorn is quite right. What you are seeing is quite normal.

Firstly, multiple peripherals can be connected to an SPI bus. They all share the MOSI, MISO and CLK lines. But each one gets its own CS line. (Just for simplicity, here I have not shown the MISO line)

If the MCU wants to send a byte to ADC1, then first it lowers CS1. Then it sends 8 clock pulses on the CLK line while writing the data bits to the MOSI line. While this is happening, CS2 and CS3 remain high.

To send one byte to each ADC, one might see a waveform like the following:

Answer 3

You said it yourself:

Details:

Captured at 4 MHz The clock runs at 2 MHz, when it is actually running

There is also something called the Nyquist Frequency, or the Nyquist Limit. Basically it says that the highest frequency that you can see is less than half of the sample rate. So if your sample rate is 4 MHz, then you can only see frequencies of less than 2 MHz. There is something important here that most people get wrong. You can see frequencies up to, but not including, half the sample rate. So at 4 MHz, you cannot correctly see 2 MHz frequencies.

The side effect of this is also called "aliasing". What this means in practical terms is if you are looking at a signal that is close to, but not exactly 2 MHz, then it will appear as if the signal comes and goes. For a time that clock will be there, then it will go away. This is what I think is happening in your pictures, where the clock is sometimes not there when I think it should be. A similar thing can happen to your data as well.

To get reliable data for debugging this you need to be at least 4x, and sometimes 16x of your max frequency. So for a 2 MHz clock you should be capturing data at 8 to 32 MHz.