Created attachment 101 [details] sigrok-cli and PulseView runs Using the Saleae Logic16, or at least some versions of some of the clones (example: http://sigrok.org/wiki/Noname_XL-LOGIC16-100M) it will happen relatively often that you see this: sr: session: Running. sr: saleae-logic16: receive_transfer(): status LIBUSB_TRANSFER_TIMED_OUT received 0 bytes. sr: saleae-logic16: receive_transfer(): status LIBUSB_TRANSFER_TIMED_OUT received 0 bytes. sr: saleae-logic16: receive_transfer(): status LIBUSB_TRANSFER_TIMED_OUT received 0 bytes. sr: saleae-logic16: receive_transfer(): status LIBUSB_TRANSFER_TIMED_OUT received 0 bytes. sr: saleae-logic16: receive_transfer(): status LIBUSB_TRANSFER_TIMED_OUT received 0 bytes. sr: saleae-logic16: receive_transfer(): status LIBUSB_TRANSFER_TIMED_OUT received 0 bytes. [...] sr: session: bus: Received SR_DF_END packet. In this case, no samples will ever be transferred, and in PulseView it will look as if the acquisition didn't work and/or yielded no samples. It's not entirely clear why or when this happens. Five consecutive runs on sigrok-cli work every single time (without USB re-attaching). Multiple consecutive runs in PulseView don't always work. Subjectively it *seems* that the first run after a firmware/bitstream upload *usually* works, and then the next few runs will no longer work. And/or no runs will work after a certain *time* after the bitstream upload (?) However, I think I've also seen cases where the first (and maybe second) run did not work, but then the third one *did* work, so... I attached a log of 5 sigrok-cli runs and 5 or more PulseView runs for comparison.
Hi, I get the same output with a "waveshare cy7c68013 mini board" running fx2lafw while connected to my motherboard's EHCI. On a PCIe XHCI card I get LIBUSB_TRANSFER_ERROR instead (wireshark says -EPROTO). By some random monkeying, I discovered that reducing packet size (EP2AUTOINLEN[H:L] = 0x0080) makes it work at least on EHCI if sample rate doesn't exceed 1M. Could somebody check if the same happens on XL-LOGIC clones with fx2lafw? As for possible reasons, I'm wondering what is the exact tolerance of these no-name Chinese crystals... Unfortunately, I have no way to measure mine and I don't want to replace it because I still have an option to return this board if it doesn't show signs of modding :)
Created attachment 465 [details] sigrok-cli timeout at 12 MHz I'm noticing a similar issue on a saleae logic8 clone (24 MHz). My test case is waiting for a trigger condition that occurs once a second. sigrok-cli --driver fx2lafw -l 5 --samples 50 --triggers D1=e --channels D0,D1 --config samplerate=12m Attached a log of a success and timeout. Also, not sure why it's reporting "firmware 1.3", since I have the 1.6 version of fx2lafw-saleae-logic.fw available in ~/.local/share/sigrok-firmware
Created attachment 466 [details] sigrok-cli success at 12 MHz
Created attachment 467 [details] Script for showing distribution of timeouts Wrote a script to keep re-running sigrok-cli and note whether the triggering event was captured before timing out. Here are the results at 12 MHz. A dot '.' represents a timeout, and a 'C' represents captured data. ..........C.................C......C................................................C..........C..........C...C...............................C......C..........C......C.................C.....................C.................C...C...C...C......................................CC...............................C...C...C.............C...............................C...................C...C...C.....C...C..........C..........C..........C.......C...C..........C......C..C.............C.............C..........C.................C..........C.............................................................C...C...C..........C...C..........C.....C..........C..........C..........C...C...C...C.................C...C..........C...C..........C.............C..C.C.C.........C...C................C...C...C...C........ The successful captures appear randomly distributed. Success is likely just due to the random chance that the triggering events occur in the window of time before the LIBUSB_TRANSFER_TIMED_OUT errors shutdown the connection. The distribution changes depending on the sampling rate. Slower rates are more likely to succeed, although a more ideal consistency test would be to reduce the triggering event frequency along with the sampling rate to determine if the timeout errors are due to sample collection rate or sample volume. Also found a good discussion on debugging this sort of USB issue in this thread: https://github.com/libusb/libusb/issues/337