LimeSDR Mini USB errors

hcb · 23 December 2020 17:45

I have a problem similar to the one described here: ERROR: TransferPacket: Write failed (ret=0) but mine isn’t solved by plugging directly into the computer.

This happened on a day when I was having strange USB port issues, possibly due to the cold temperature affecting the motherboard. My external hard drives were also randomly disconnecting at that time. When it happened, I was using the board to transmit nonstop QPSK at 903 MHz. Everything seems fine now and I’m able to use the mouse, keyboard, webcam, and 2 external hard drives but not the LimeSDR Mini anymore. Whatever happened is also preventing me from flashing the firmware so I’m wondering if I have to buy a USB blaster to fix it.

I made sure to install the latest FTDI driver, version 1.3.0.4. I also tried it on another computer with USB 2 and 3 just to make sure it wasn’t a problem with my USB ports. On this other computer I got a slightly different set of errors in LimeSuite that said, “ERROR: TransferPacket: Read failed (64 bytes)”.

Here are my LimeQuickTest results:

C:\Windows\system32>limequicktest
[ TESTING STARTED ]
->Start time: Wed Dec 23 11:31:03 2020

TransferPacket: Read failed (ret=-1)
TransferPacket: Read failed (ret=-1)
TransferPacket: Read failed (ret=-1)
TransferPacket: Read failed (ret=-1)
TransferPacket: Write failed (ret=-1)
TransferPacket: Write failed (ret=-1)
Board not supported
Failed to connect

As you can see, it shows up in LimeSuite’s device list.
limemini_device_list

However, this is what LimeSuite reports when I try to connect to it:

[11:39:04] INFO: Disconnected control port
[11:40:55] ERROR: TransferPacket: Read failed (ret=-1) x3
[11:40:55] ERROR: TransferPacket: Write failed (ret=-1) x35
[11:40:59] INFO: Connected Control port: UNKNOWN FW:0 HW:0 Protocol:0 GW:0.0 Ref Clk: -0.00 MHz

andrewback · 24 December 2020 09:06

It does look as though firmware may be corrupted. Is there another port or computer you can try though?

hcb · 24 December 2020 16:02

Yes, I tried it on another computer with USB 2 and 3 ports and made sure to try both types of ports and I got almost the same error in LimeSuite: “ERROR: TransferPacket: Read failed (64 bytes)”.

If the firmware is bad, how can I fix it?

andrewback · 29 December 2020 09:25

@Zack, if you could take a look and advise, please.

Zack · 29 December 2020 19:23

Hello @hcb,

Yes, it looks like FPGA gateware was corrupted. USB Blaster should help in this case I think.

hcb · 29 December 2020 19:46

Thank you, @Zack. Is this what I should buy or do you recommend something else? https://www.amazon.com/RioRand-Blaster-CPLD-FPGA-programmer/dp/B00IRODADK

Zack · 29 December 2020 19:58

Hi @hcb,

Not sure about this. Search this forum, there was a discussion about it. I’ve tried it, but I couldn’t program LimeSD-Mini using this device. We were able to program other FPGA if I recall correctly
I would go with this:
https://www.digikey.com/en/products/detail/terasic-inc/P0302/2003484
This will definitely work (we use these programmers in our lab).

hcb · 18 March 2021 00:52

This clone from Amazon was able to fix one of my SDR’s but the other one is still broken which makes me think it was somehow physically messed up. The only visible issue is that I accidentally flexed the USB port a little, but since it shows up normally in Device Manager and LimeSuite GUI’s connection dialog I don’t think that’s the problem.

When I plug in the one I was able to fix, it flashes red and yellow. The one that’s still broken does the same for a while but it sometimes stops on either red or yellow and then resumes the alternating pattern.

I also noticed that the lights now turn off completely on the fixed one when I stop transmitting but since it transmits properly I think it might just be how the new gateware works.

hcb · 19 March 2021 14:02

My second SDR just failed again and for some reason I can’t fix it this time. I also noticed that it’s giving a different set of errors compared to the first one. My computer’s USB ports failed again and stopped some downloads I was doing onto an external hard drive, which is what happened the first time the SDR’s broke.

I re-flashed both SDR’s today and tried them afterward and these are the errors I got.

I did a Google search and some LimeSDR users have had trouble when their USB ports didn’t provide enough power so I’m going to see if my SDR’s work on any other computers.

hcb · 19 March 2021 15:14

I just tested both SDR’s on my Raspberry Pi and the second one was able to transmit but the first one causes the same errors shown in the Windows screenshot for “SDR #1” along with a libusb warning saying “the application left some devices open”. For this test I powered the Raspberry Pi with a benchtop power supply set to 5.25 volts. I tested the SDR’s separately and their current (not counting the Pi) averaged 0.21 amps when they were first plugged in and, for the one that could transmit, 0.67 amps while transmitting. The average current used by the entire setup was 0.474 amps (2.49 watts) after the SDR was plugged in and 0.94 amps (4.94 watts) while transmitting.

This means the second SDR isn’t actually broken but since the first one still is, I think it might have a hardware issue.

andrewback · 20 March 2021 10:19

Raspberry Pi is not a great choice if you are looking to rule out power supply issues. It should work and we have used RPi boards fine before, but the LimeSDR Mini is a USB 3.0 device and any RPi version prior to 4 is only USB 2.0. In addition to which an RPi itself can struggle if the power supply is not up to scratch. Hence would strongly recommend trying another desktop/laptop.

hcb · 22 March 2021 23:34

I just tested both SDR’s on a computer with USB 3.0 and the second one works but the first one still doesn’t. I made sure to re-flash the first one right before testing it, just in case using it with an underpowered USB 2.0 port is what messed it up. The errors for the first one are the same but I know it’s able to send data over the USB pins because LimeSuite and my console program recognize it.

andrewback · 24 March 2021 05:39

OK. So I’m confused between which is which of the two boards. The one that is failing is the one with the bent USB connector, or has that one never worked since being damaged and do you mean the one that you previously reprogrammed with the USB Blaster?

hcb · 28 March 2021 15:04

"The one that is failing is the one with the bent USB connector" Yes
"or has that one never worked since being damaged" No, it continued to work from July 2019 (when I bent the connector) until late 2020.
"and do you mean the one that you previously reprogrammed with the USB Blaster?" I reprogrammed both of them so I’m not sure which one you’re referring to.

Board 1 has the bent USB connector. This happened around July 2019 and it continued to work until late 2020. Its serial number is 1D39984FFF88BF.

Board 2 is the one that was never physically messed up. I was able to fix it and use it on a desktop computer with USB 3.0 and a Raspberry Pi. Its serial number is 1D398F4769AE6A.

Zack · 29 March 2021 10:31

Hi @hcb

It looks like USB related part of the board still works even with connector was bent while it reads FTDI serial number successfully. It is obvious that there is no communication between FTDI and FPGA. Reasons may be:

FPGA is still not programmed;
It got some other issues which prevents FPGA operation;
Interface between FTDI and FPGA issues.

Would try to program it using Altera programmer instead of this cheap thing you are using (although it works OK for the other board but I do not trust this kind of equipment).