LimeSDR gives Gateware version 0 / 257 when cold, is OK when warmed up

Projects LimeSDR
1

Hello all,

Today I ran LimeUtil --update my LimeSDR, which was working fine so far, And yes, once done, I experienced the “Gateware version 0, revision 0” bug (actually I experienced “Read(64 bytes) error” and some Write errors too), but then I did a LimeUtil --make and that’s when I saw the “version 0, revision 0” line) and searching the Web, I saw than I was not the only one. I knew I had not made a single HW modification, so the only cause could be software – the upgrade. So I thought maybe downgrading, or re-upgrading, would fix things.

Long story short, I tried going through LimeSuite or LimeUtil, I tried with different USB cables, through an externally-powered hub, and also by supplying 12V on the DC connector, but always the board would show read or write errors and gateware version 0, regardless of the versions of the firmware files I ran through LimeUtil --fw / --fpga – (these commands, by the way, never gave a single warning).

Eventually, I noticed something: Starting from power-on or reset, if I did a LimeUtil --fw, the LED closest to the USB connector and the PCB edge would turn from green to red while the (assumed) flashing was underway, and it did so until after the first LimeUtil --fpga, and then LimeUtil --fw or --fpga would not turn the LED red anymore until reset or power cycle.

So I tried this: with the LimeSDR powered externally by a 12V / 1.5A supply and connected through USB3.0, just after power on, run the LimeUtil --fpga (the LED would turn red), repeat it (this time the LED would stay green), run the LimeUtil --fw (the LED would stay green) then cycle a few LimeUtil --make.

The first time I did this, the LimeSDR would show the correct Gateware version (2.12 at this point), then after a few turns, read or write errors would crop up and the gateware version would go back to 0.

Then I tried the sequence again, this time with the 18.04 firmwares (Gateware 2.16)… And this time the Gateware version 0 messages went away as did the read/write errors, GNU Radio was able to talk to the LimeSDR again, and all was fine again.

I am still wondering why this worked – my only clue to trying this sequence was the LED’s behavior. I am not claiming this works for everyone, but just in case it helps someone else… (or if the issue crops up again… fingers crossed).

[side note: the LED color is not simply always “green=ok, red=ko”: right now, if I run a LimeUtil --make every second, the LED will bleep red every second, without any read or write error being logged.]

Cheers,
Albert.

2

After a few hours’ stop, the LimeSDR USB again shows read errors and Gateware version 0 issues.
The only difference is time, since I just unplugged it then and plugged it back now, so the only factor may be device temperature. I will try to leave it plugged for a few hours and re-run the tests (not the flashing) to see if temperature is indeed a factor.

(note : I edited the title according to the new development)

3

OK, this is to confirm that the issue is temperature related.

This afternoon, I plugged the LimeSDR in (both a 12V power supply and the USB3 connection) and cyclically ran LimeUtil --make: the LimeSDR replied alternatively with a Gateware version of 0 and 257 (which is not unheard of, see LimeSDR USB Gateware Update Oddities : Version 257?).

Then I just let it rest while supplied for about 20 minutes, and then unplugged and replugged the USB and ran LimeUtil again – now it consistently gives Gateware version 2, revision 16 as expected.

As the computer is always on, its own temperature did not change; only the LimeSDR’s did.

Paradoxically, if I did put a fan on it, it might get worse…

(title updated according to experiment result)

Cheers,
Albert.

4

@Zack, anything to suggest?

5

I am afraid it sounds exactly like the issue I was having with two of my boards (described here), where I have also found that the probability of “gateware 0 problem” depends on time of keeping the device unpowered (thus, it may be temperature related). But in my case it was happening right from the beginning.

Sadly, in the end I had to replace both boards :neutral_face:

6

Thanks @ccsh – note that in my case, the LimeSDR USB is totally unmodified, and it works reliably once warm (also, I only use it for RX, in case this helps).

7

Hi, if you have the opportunity, could you check if LimeSuite 17.06 with FW 1.3 and gateware 2.8 also fixes the problem?

As I reported in https://discourse.myriadrf.org/t/limesdr-dead-flashing-does-not-help/2520/3 I had similar problems, but heating does not seem to help.

I moved to using my HackRF, but I would like to get it back to work.

Thanks
Job
PH4AS

8

I’ve had this issue as well, with latest everything. Seems like about 50% of the time when I go to start a session, it shows gateware zero. So, I stop the session, wait a few seconds, and then try again, and usually it comes up with the correct gateware version and everything is happy.

9

But it was fine with previous versions?

@Zack, do you have anything to suggest here?

10

@ph4as: cannot test right now, but I will try next week-end.

11

Hi aaribaud,

I have the similar problem with my LimeSDR-USB, just tried to warm up the FX3 chip by using a rework station and the board starts to work! It fails again after cool down though, but now I can confirm the issue is temperature related.