My ancient IKALogic Logic Analyser died last week so I bought a Sparkfun version.
I’m using Sigrok PulseView on Debian 10.
The current project is debugging an application with the Adafruit Airlift module. I have a C++ program running on a Pro Micro 3.3V.
The program works correctly - I can query the status, firmware version and scan for networks and all works as expected. Protocol is SPI.
Just to keep things simple, the loop just queries the Airlift status or firmware version every 10 seconds. These are short transactions.
The data on the MOSI line is always reported correctly by the LA. The returned data on MISO is only occasionally correct. Most times quite a few of the bytes are incorrectly reportedy - sometimes just one bit has been misread, sometimes more.
I’m not familiar with Sigrok (but it seems easier to drive than Scanalogic). I’ve tried different number of samples and frequencies. I’ve slowed down the clock rate on the SPI bus from 8MHz, to 4MHZ, 1MHZ and 500kHz. Same behaviour each time.
If it makes any difference, the Airlift doesn’t transfer data the same as, say, a BME280 for example. You need to assert CS and then wait for the BUSY pin to assert, send the command, drop CS and then wait for the BUSY pin again before you start receiving data on MISO.
I haven’t yet tried a different pin for MISO on the LA. I can also try a different SPI client device.
I’ve always started with a sample rate of 4 times the signal which seems to produce better results especially when the waveforms aren’t so clean, but I don’t believe the sampling rate is the issue here.
I did some more testing at various configurations. Here is a good capture at 16MHz.
I dropped the sample rate down to 1MHz (ie twice the signal frequency and still obtained a reliable reading on the MOSI command being sent to the Airlift. (ie E0 20 00 EE on MOSI)
I then kept increasing the sample rate until the returned data on the MISO line from the Airlift was reliable. It almost works at 12MHz but only becomes reliable at 16MHz. (Expected data is E0 A0 01 01 00 EE)
Given that the data in the initial transaction is always reliable , I suspect that either sigrok or the LA is being tripped up on the interval between the two transactions and is not retriggering as expected. My initial thought that there was something untoward happening on the MISO circuit was incorrect.
Anyway, it’s doing what I need so all good.
BTW the image above is from a Pico talking to the Airlift.
And I’ve just noticed a bug in my code. It’s generally safest to send dummy 0xFF bytes back on MOSI when reading data from a device rather than the 0x00 as it is now. Obviously the Airlift doesn’t care but some devices are a but fussy.
2 Likes
And you can get our latest projects and tips straight away by following us on:
