Spying on SPI with the Analog Discovery 3

I had the honor of getting early access to the brand new Analog Discovery 3 from Digilent to test it out and see how it would integrate into my lab bench. And it just so happened to arrive at the perfect time to help me debug a project that I had working, but then suddenly stopped working.

The Analog Discovery 3 is a handy all-in-one USB-based piece of test equipment that's only slighting bigger than a Raspberry Pi, and it's logic analyzer and protocol checker/sniffer functionalities legitimately saved my ZynqberryZero and eInk display from being thrown out of my office window (for all intents and purposes, that is a joke... no FPGAs were actually harmed in this particular incident).

A couple of months ago, I posted a project tutorial showcasing how I installed Adafruit's CircuitPython on my ZynqberryZero to be able to drive a UC8151D eInk display via SPIdev. I disassembled the project to pack it up and take it back to my NYC desk, but after setting it back up I found that the code driving the eInk display no longer worked...

AD3 Setup

The Analog Discovery 3 hardware is a breeze to set up: connect the USB C cable to a host computer and the 2x15 Flywire cable assembly to the target testing circuit. Since that target circuit is most likely on a breadboard or has jumper connections to a breadboard, Digilent also included some spare male header pins to connect the Flywire probes to.

I decided to start with the probes of the AD3 connected closer to the eInk display since I had ILAs in the bitstream of the FPGA to see the signals at the Zynq FPGA package pin. But the AD3 has enough digital I/O (DIO) probes that I could have connected all of the pins to a second channel closer to the FPGA pins as well (the Vivado ILAs were leftover in the bitstream from when I was debugging the design to getting it working initially).

With the hardware all setup, it was time to turn to the user interface for the AD3 to "see" what was really going on here. The user interface for the AD3 is Digilent's WaveForms application, which is a virtual test instrument suite for use with their USB oscilloscopes such as the AD3. The downloads and installation guides for Mac, Linux, and Windows can all be found here.

Note: if you already have WaveForms installed, you will need to update to the latest version of it and Adept Runtime before your AD3 will appear in the device list.

Logic Analyzer in WaveForms

If you're not already familiar, a logic analyzer is a test instrument that reads digital signals specifically. One can think of it as a special purpose oscilloscope with preset settings for the digital signals such as SPI, UART, I2C, CAN general buses, and so on.

Selecting a test function in the Welcome pane of WaveForms opens it in a new tab in the current WaveForms workspace.

Click the green plus button labeled "Click to Add channels". Select the digital signal/protocol type (SPI in my case), then match the DIO probe numbers to the signal values as connected to the test circuit.

A trigger condition can be set to start a capture when that condition is met. I personally like to use the "Start" option for a trigger, which for a SPI interface is when the master on the SPI bus set the chip select line to start the transfer:

With the trigger set in the Logic Analyzer, I ran the script on the ZynqberryZero to draw an image on the eInk display:

I immediately noticed the clock signal on the SPI bus (SCLK) looked odd, so I switched back to the Welcome pane to open a new tab with the Protocol Check in the WaveForms workspace.

Protocol Checker in WaveForms

The Logic Analyzer shows the physical signal levels on the digital bus, while the Protocol Checker acts as the application layer and actually decodes the data being sent to display it.

Select the desired protocol from the tabs along the top of the Protocol Checker window and again match the DIO probe numbers to the signal values as connected to the test circuit. Also set the Frequency value to the clock rate of the protocol (SCLK frequency set by the master device in the case of SPI).

Then hit run:

The data read in by the Protocol Checker didn't match what the FPGA was sending out. This is what confirmed my suspicions after seeing that the SCLK signal in the Logic Analyzer didn't look right.

The SPI Problem

There was one key difference in my circuit setup on my NYC desk compared to what it was before when the eInk display was working. I had added my Pi Cobbler adapter to make the jumper connections easier.

What I noticed in the Logic Analyzer was that the SPI clock pulses were not evenly spaced, not the right duty cycle, etc. The Protocol Checker showed the data on the MOSI bus wasn't being clocked as the correct values either.

This meant something between the pins of the FPGA and the pins of the eInk display was adding too much impedance to the physical SPI signals such that they were no longer the same values going into the eInk display as they were coming out of the FPGA. Which was really frustrating to debug initially before hooking up the AD3 since the ILAs instantiated in the programmable logic of the FPGA showed nothing was amiss.

Removing the Cobbler adapter solved the issue and the eInk display was able to read in the data from the Zynq SoC FPGA again.

And everything looked right again in the Logic Analyzer and Protocol Checker (please ignore the broken rows on my eInk display, this was due to an unrelated incident where my new Roomba sucked it up after I dropped it at a very inopportune moment).

Conclusions

While the passthrough connector I was using was a Raspberry Pi accessory intended to pass through similar SPI and I2C buses, something about that extra distance the physical signals had to propagate was just enough to distort them to the point of the SPI receiving device not being able to correctly read them in. Maybe I need to reflow the solder joints on it, but for now its just going back in the drawer, not to interfere with my circuits again...