martinling
commented
1 year ago Hi Gerhard, long time no see. I've not been involved in sigrok for a while, but am working at GSG now and was happy to see your recent work getting GreatFET support into libsigrok.
I expect that the glitches you are seeing happen when the SGPIO interrupt is delayed by the USB0 interrupt, which will need to be serviced after every 16KB of data (as set by USB_STREAMING_BUFFER_SIZE).
This used to be a problem on HackRF as well, and was investigated in https://github.com/greatscottgadgets/hackrf/issues/688. The fix there was to move the SGPIO handling over to the M0 core, which was first done in https://github.com/greatscottgadgets/hackrf/pull/692. This approach was never brought over to GreatFET, but probably should be.
I did a lot of work last year on optimising and documenting that M0 code, as well as adding features for tracking and handling buffer overruns/underruns; I think much of that work could be reused here too.
It seems though that even the current M0-managed SPGIO streaming on HackRF is not completely immune to glitches, as spotted recently in https://github.com/greatscottgadgets/hackrf/issues/1363 which still remains to be explained.
Have observed this when working on sigrok.org support for GreatFET. It's not systematic, does not always happen, but is seen with higher probability at higher sample rates. Never noticed at 20MHz, but certainly did at 34MHz and above.
How I noticed: Got a Graycode generator that steps its sequence at 8MHz change rate. Am sampling 8 lines of this Graycode pattern. Take a capture, then zoom in and out of the periodic waveform until you spot "visual glitches". These are not one-sample glitches from jumper wires. Instead several dozen samples appear to "not belong into this spot", as if another section of the waveform would be placed there instead. When there are hiccups, they are 16K samples apart which happens to be the firmware's USB transfer submission length. That'd be 480us at a 34MHz rate. As mentioned above this is not a systematic issue but is observed more often at higher rates (actually: USB bandwidth use, the product of samplerate and channel count).
It's not an exact length of 32 samples, which would correspond to the SGPIO FIFO depth. Could be something different, cannot tell whether it's device firmware or host application or host's USB stack in the OS. Have yet to get a good illustration of the issue. Took the screenshots below when I dumped incoming USB transfer content to disk as raw bytes. First image is zoomed out to show the hiccups' distance. Second image zooms in, shows how the 50% duty cycle of the Graycode waveform isn't seen. It's yet uncertain what is seen instead.
Have noticed that HackRF was reported to glitch around USB transfer boundaries, and that this was also observed with GreatFET. These projects share the NXP LPC4330 chip, but their firmware implementations differ in how SGPIO results are forwarded to USB. HackRF runs M0 code in parallel to M4 which exclusively gets the data, should be less affected given fewer constraints. GreatFET executes ISRs in the M4 context which leaves fewer CPU cycles and might run into timing issues easier or more often then parallel M0 code would. Am guessing here from the little that I learned looking at the projects so far in the past weeks.
Host side USB transfer configuration is: Linux, pool of 8 USB transfers of 256KiB length each, submitted early and ready to receive. Matches Qyriad's implementation of sigrok support for GreatFET logic analyzer support.
Will see if I can "instrument" the device firmware, and toggle a pin in the code path. Changes execution timing though, may have to get "only part of" the FIFO content to complete the ISR in time.