Picoscope 6424E Road Test - SPI Testing with MSO Pods

The 6424E can accept one or two TA369 Digital Pods to extend its capabilities by up to an additional 16 digital channels. This is a nice simple conversion from 4 channel analogue to 4 + 16 MSO functionality for which you need only to buy the Digital PODs (no additional software or licenses required.)

The TA369 Pods are very nicely made and I think rather better designed than the similar pods that can be added to the Keysight 3000 series or the Rhode and Schwarz RTA4000 series scopes.

The TA369 Pod

The Pods come with all the usual grippy and pluggy things

The arrangement with a length of cable between the scope and the Pod and only short leads between Pod and probes makes for a much more tangle free system than Keysight's where the Pod plugs directly into the scope and has long probe leads. R & S use the same system as Pico for the RTA4000.

There are active parts in the Pico Pods and they become quite warm in use.

Debugging 16 channel lock in amplifier (kind permission of  University of St Andrews)

The probe sockets on the Pod accept little earth socket adapters and can then plug onto a 0.1" header with signal and earth. The eight probes on a Pod can clip together or be separated. This arrangement makes for the neatest connection to an 8 x 2 row 0.1" header that I've seen. The system being tested here has 1.25mm debug connectors so I've made up some little adapter leads.

To put the digital capabilities of the 6424E to the test I'm looking at the 16 channel lock in amplifier which made a cameo appearance in the blog about the Probe Positioning System. To make any sense of what the scope tells us you'll need a rough idea of what the system we are testing is doing.

It was originally designed as an 8 channel system with all the parts except the power supply on the lower board. A requirement for an additional 8 channesl came up and the simplest way to do this was to replicate the analogue processing, ADC and FPGA on a second board. This is the blue board that you can see in the picture -  it's a near exact clone of the input , ADC and FPGA section of the first board.

In the original design the FPGA controls the ADC and processes the data which is then passed to a micro for further processing and output via USB. The FPGA communicates with the micro via an SPI-like interface. The FPGA has many spare pins taken out to debug connectors but the micro has very few spare pins, and no spare SPI interface. This means that processor SPI interface msut be multiplexed by the first FPGA which accepts data from the second FPGA via the debug connectors. These are linked by the black wires you can see in the picture.

To further confuse the picture, the FPGA is the SPI bus master but the micro is the protocol controller - there are good reasons for this but I won't go into them here.

The interface signals are:

In 16 channel systems there are two FPGAs which share all the uP interface pins except ucr. Two channel systems have a chip select for each FPGA, ucr0 and ucr1.

When the uP wishes to send a command to the FPGA it will check that fsb is false and assert ucr.

The FPGA will assert fsb and clock the command out of the uP and execute it, when it has a reply ready it will wait for the uP to clear ucr , then clock the reply into the uP and finally clear fsb.

If fsb is low the FPGA will respond to assertion of ucr in a maximum time of 250ns, the uP may clear ucr as soon as fsb is asserted.

The uP will need to set a DMA system up to transfer data from the uP to the FPGA and also for data from the FPGA to the uP.

Optionally the falling edge of fsb may be used to interrupt the uP to indicate when a transaction is complete but generally it is expected that the uP will initiate interactions at regular intervals. The FPGA has control of the data transfer rate so there is no protocol determined limit on how long a transfer might take. The uP should always test that fsb is low to determine if the FPGA is finished.

The Picoscope has built in decoders for SPI and they are used here.

Picoscope with clock signals on A and C and SPI signals on the digital channels

In some of these early screenshots there is a problem with the fsb signal - I think there was a bad connection in my adapter lead.

Zoomed in so that the decoder screen display can be read

The processor sends a command and the FPGA replies, fsb isn't working correctly (on the scope) - it is working in real life, otherwise system wouldn't work at all.

Rulers showing the long delay between sck rising and miso changing state.

The reason that I wasn't paying attention to fsb is that I was looking at this very long delay between the rising (active) edge of sck and miso. This is the price that is paid for routing the the SPI signals through a second FPGA to get them to the micro. I had to slow the interface down quite a bit compared with the 8 channel system.

Undocked Serial Decoding table

You can undock the serial decoding table and put it where you like. This is handy but still doesn't solve the problem of inspecting a large amount of SPI data. It would be really good to have a way of getting large data blocks to form into a table with some kind of position indication (so you can find, for example, the 723rd byte in a 2048 byte packet.) Maybe in Picoscope 7 .........

Showing the large amount of data captured but not sensibly displayable.

To be fair, I think other scopes struggle with this too.

fsb connection still broken

zoomed in view showing fsb signal on B channel as well as digital, fsb connection good now

start of transfer - fsb working