Hi! I’m a software developer that sometimes plays with IoT and radio bits in my spare time. I’m also a licensed ham looking to do a little more with my license, and I got a LimeSDR Mini v2 to try.
Since I wanted to try my LimeSDR on my ARM64 Windows device (Lenovo X13s), I reached out to FTDI for a driver and they were kind enough to give me a beta driver. Under the hood, the new driver is actually WinUSB and requires a re-link if not a recompile of LimeSuite. Since it turns out it’s different for x64 too, I’m sticking to x64 to get things working before making the architecture jump.
I now have a working x64 build of LimeSuite on an x64 machine. When I swap in the new driver lib and INF, it still enumerates but fails all reads and writes to the device. Even temperature reads, which appear to be fairly simple, fail.
FTDI assures me that many other customers are happy with the new driver, so I figured I’d come ask here:
- Has anyone else tried the beta WinUSB-based FTDI 3XX driver with LimeSuite?
- I’m happy to troubleshoot on my own, but would love help. Any thoughts on what I should be looking at first? There are a few layers of abstraction
Example failures:
C:\Temp\lime> limesuite-x64-newdriver\bin\LimeUtil.exe --find
* [LimeSDR Mini, media=USB 3, module=FT601, serial=1D90F61B43CFC7, index=0]
C:\Temp\lime> limesuite-x64-newdriver\bin\LimeUtil.exe --update
Connected to [LimeSDR Mini [USB 3] 1D90F61B43CFC7]
TransferPacket: Write failed (ret=-1)
Update not supported: UNKNOWN[HW=0]
Programming update failed!
C:\Temp\lime> limesuite-x64-newdriver\bin\LimeQuickTest.exe
[ TESTING STARTED ]
->Start time: Thu Jul 4 22:13:52 2024
->LimeSuite version: 23.11.0-g9dce3b6a
TransferPacket: Write failed (ret=-1)
TransferPacket: Write failed (ret=-1)
TransferPacket: Write failed (ret=-1)
TransferPacket: Write failed (ret=-1)
TransferPacket: Write failed (ret=-1)
TransferPacket: Write failed (ret=-1)
Board not supported
Failed to connect
Huh, failing overlapped I/O writes. I can pull a better error message out of that, and I can debug through it with both drivers. Heck, I might drag TTD out since some of the tasks are short. Thanks!
The error in ConnectionFT601::Write (and ::Read) appears to be STATUS_INVALID_DEVICE_REQUEST (0xc0000010 in OVERLAPPED.Internal) from GetOverlappedResult. Thinking maybe the device wasn’t initialized right, I started instrumenting earlier parts of the process.
ConnectionFT601::Open gets FT_INVALID_PARAMETER from FT_SetPipeTimeout only on the new driver. Their docs are a bit sparse here, but the only parameter that seems suspect to me is the pipe handle if something earlier in initialization went wrong or behaved unexpectedly–which seems either nonsensical or really bad.
Does gateware persist on the device, or do I need to re-sync-and-flash it every time I plug it in? It could have just been me screwing something up, but I thought the errors changed when I unplugged it/plugged it in after changing drivers. (The word ‘flash’ suggests it persists, but I wanted to be sure.)
What are some of the simplest LimeUtil or Lime Suite GUI commands available? I’m hoping for ‘sends one small message on one pipe, reads one small reply, needs no setup or initialization’ to keep the debugging simple. Lime Suite GUI runs a whole lot of operations after calling ConnectionFT601::Open, so I can’t really use a temperature read (which I hope is very simple) for testing.
Here’s a very crude test of a single command, run “LimeUtil --FTDI” Test function for FTDI comms · rjonaitis/LimeSuite@2cbe4c2 · GitHub
I assume you’re talking about FTDI chip firmware, If you flashed a new firmware it should persist, unless you’re somehow programming RAM and not the EEPROM/FLASH memory. I haven’t worked with FTDI chip, so I don’t know anything.
1 Like
That test is quite helpful, thanks!
From what I know about the LimeSDR, there are two devices that need programming: the FPGA and the USB interface. (Without diving into docs again, I presume the RF interface itself is not running code itself.) I was thinking of both, actually. I also think I found a good-enough answer: when I unplug and re-plug-in the device, LimeUtil --update succeeds trivially saying the installed code is the same version as it has available for it. This tells me that I’m not worried about needing to run LimeUtil-side init before the device can be expected to work correctly. (The docs say somewhere to always start with LimeUtil --update to ensure the FPGA gateware matches the LimeSuite version, so I wondered if the update failure with the new driver meant I was missing an init step. I am not.)
Tonight’s experiments confirm what I’ve partially seen already: the device correctly enumerates by serial number. The handle opens without error. Abort and the config call succeed. FT_SetPipeTimeout errors out with FT_INVALID_PARAMETER. I can’t figure out why, but I wonder if disassembling both sides of the function call would help. The write succeeds, but the read fails with STATUS_INVALID_DEVICE_REQUEST.
Fun fact: if I switch drivers without unplug/replug, the write fails too.
The new test function removes a lot of variables, but I’m still looking for the next thing to try. FTDI may be able to help, but I got the impression they prefer to talk to the OEM directly–I definitely need to absorb a bit more before being able to ask them good questions.
Perhaps FT_SetPipeTimeout might not be needed, as on Linux platform, where libusb driver is used to interact with the FTDI device, it’s not used.
