Hi, Just wondering if you have tried powering your mini from an external power source?
When I first tried to use my limesdr usb, I was getting similar results as your original post.
After powering with an external source(battery) it now runs just fine.
You may have verified that it is not a power issue, this is a long thread!
Cheers
@zack thank you. Both .sof and .pof can be opened, will investigate the difference.
The UI gets populated with the proper device of MAX 10 series:
as listed in LimeSDR Mini specs ( 10M16SAU169 ).
Hope to be able to check the update process asap.
@Smdude : i do not have a suitable external power source, so I cannot try in that way. In any case, my board has always run fine since the first moment with older sw versions.
I would just like to leverage all the improvements/changes listed on github for the various sw items and I need the latest GW to be compatible and use those. So the need to go through the JTAG programming process…
The difference is this: .sof file will be uploaded to SRAM configuration memory hence will vanish after power cycle; .pof will be uploaded to the internal FLASH memory and will be uploaded to SRAM memory each time after power cycle.
I would try .sof first.
@zack do you mean try .sof first and if I get no programming error then repeat using .pof to have it permanently store?
…I was actually reading the pdf guide and found paragraph “3.3.3 Programming .pof into Internal Flash” at pages 40 and 41.
It lists 4 options:
— To program any of the CFM0/CFM1/CFM2 only…
— To program the UFM only…
— To program the CFM and UFM only…
— To program the whole internal flash including the ICB settings…
which one should I use in our case ?
Correct. Just to be on a safe side, if any.
Select all Programming checkboxes after you open .pof file.
@zack I successfully programmed the LimeSDR Mini with latest GW bitstream.
Thank you again for all your support.
Please find below some screenshots and additional info to get a working device driver for clone USB Blaster.
First test programming session using .sof file:
Second programming session using the .pof file (all programming options checked):
Now GW v1.24 is reported when connecting to the board using LimeSuite GUI:
I initially had blue screens or Quartus Programmer crashing due to issues with USB Blaster device driver. I was using the one supplied with Quartus standalone programmer but there seems to be some incompatibility with 64bit Windows and/or signatures.
I found another driver in this post on Altera forum: http://www.alteraforum.com/forum/showthread.php?t=19233 (scroll to message #5 ).
I uninstalled and removed previous driver and installed this one after disabling the windows signature enforcement. Not a best practice but no virus was detected in the downloaded zip file.
Please note that this new driver is FTDI related. I guess the clones emulate FTDI chips using the STM32 micro programmed for this…
One last important note about the 2x5 female/female cable that comes with the clone: pin sides are reversed compared to the male one represented in the new wiki page.
Look at this image to understand how the USB blaster cable pinout should be considered when connecting it to 7 pins on LimeSDR:
in the male connector the odd pins are on the left and even pins are on the right, while in the female on cable odd are on the right and even are on the left. Especially important if you don’t want to cut the cable and use jumpers instead:
Not bad for a 9 Euro clone + 7 pin header + some spare jumpers
Happy programming!
mario
Hi @mariocannistra,
Thank you for update! Glad to hear it is working fine!
Could you share ebay link of this clone, please 
Found it searching for “Altera Mini Usb Blaster”.
I think all those with same photo are good candidates
I just ordered the closest one to avoid long shipping times. There are lots for < 10 Euro.
mario
Thanks for posting the link to the alternative USB-Blaster driver. I’ve also been struggling with BSODs when attempting to program the Altera device using a new TerASIC programmer that has what looks like a genuine FTDI part in there. Unfortunately I suspect it must have been a cloned part and was falling foul of the ‘protection’ built into FTDI’s latest drivers. Now I can get back to doing some proper development!
Chris.
Hello @cjholgate
Sorry I’ve been a lot busy recently and left behind lots of email…
Happy to hear you found this useful
Kind regards,
Mario
Hello all,
received my 2 LimeSDR-mini last week and one is working fine whilst the other one isn’t !
I run the small test utility (both under Windows 7 Pro and Linux (different flavors)) and indeed something is wrong with Rx. Here is the log from the LimeSDR-Mini test tool under Windows:
[ TEST STARTED ]
->Start time: Wed May 2 19:08:52 2018
->Device: LimeSDR Mini, media=USB 2, module=FT601, serial=1D3AC7F79EFB9B, index=0
Serial Number: 1D3AC7F79EFB9B
[ Clock Network Test ]
->REF clock test
Test results: 63939; 11600; 24797 - PASSED
->VCTCXO test
Results : 6710944 (min); 6711105 (max) - PASSED
->Clock Network Test PASSED
[ FPGA EEPROM Test ]
->Read EEPROM
data: 18 02 23 18 02 23 2
->FPGA EEPROM Test PASSED
[ LMS7002M Test ]
->Perform Registers Test
->External Reset line test
Reg 0x20: Write value 0xFFFD, Read value 0xFFFD
Reg 0x20: value after reset 0x0FFFF
->LMS7002M Test PASSED
[ RF Loopback Test ]
->Configure LMS
->Run Tests (TX_2 -> LNA_W):
->On board loopback test:
SetFrequencySXR(1000 MHz) - cannot deliver frequency
Test 1:(SXR=1000.0MHz, SXT=1005.0MHz, TXPAD=8): Result:(-16.0 dBFS, 5.00 MHz) - FAILED
->Configure LMS
->Run Tests (TX_1 -> LNA_H):
->On board loopback test:
SetFrequencySXR(2100 MHz) - cannot deliver frequency
Test 1:(SXR=2100.0MHz, SXT=2105.0MHz, TXPAD=8): Result:(-16.0 dBFS, 5.00 MHz) - FAILED
->RF Loopback Test FAILED
=> Board tests FAILED <=
Elapsed time: 5.94 seconds
As I’ve already tried everything mentioned in this topic (including using LimeSuiteGUI which failed to “Load Default” and set Rx Frequency) I started suspecting a faulty hardware. I ran a visual scrutiny and found out several CMS either broken and/or completely gone. The faulty components more or less follow a line starting near RX SMA connector with C28 (broken and gone), and going up-to FR5 (broken and gone), with also C75 (broken and gone) and FR4 twisted across C86 on one side (excuse the crudeness of the explanation). This last one make me think of a shock while the board was still in the reflow oven, at the start of the cooling in the reflow profile: solder joints already cool enough simply broke (or the components broke), while FR4 managed to rotate and got stuck to C86.
FR4 and FR5 (with decoupling capacitors C46 and C45) are powering, respectively, VDD18_SXR and VDD18_VCO_SXR. It makes perfect sense that the SXR would fail under those conditions !
Arnaud
Hi all,
also noticed that C176 and C181 are stuck together, but this is also true for the working board, and it seems to be on the ground side of both, so no electrical issue, but one of the solder joint of C181 is ugly because it has moved during cooling (at least it looks like it has.)
Arnaud
Check it with USB3 port, please. USB2 is not powerful enough for this board.
Indeed, I though that might be a power-supply issue (I’ve been down that road with the LimeSD-USB), that’s why I used the Y cable I got with the LimeSDR-USB. The power-only connector was specifically plugged into a monitoring power supply, providing 5.1V with up-to 2A to be sure no power-supply issue went into the test (in that configuration no power is drawn from the power-and-data port on the Y cable). And by the way, even if I do know it doesn’t mean a lot, the other LimeSDR-mini is working fine, even when only powered from a single USB2 port.
Here are close-up pictures for you to see what I was poorly describing in text yesterday.
This is FR4 having moved and got stuck to C86 (which it shouldn’t):
This is FR5 broken and gone:
C75 broken and gone:
C28 broken and gone:
C176 and C181 stuck together:
C181 ugly solder joint than shows evidence of movement while cooling:
Not saying that all weird behaviours come from faulty hardware (In my experience poor power-supply (underpowered, or poorly decoupled) is the primary cause), but sometimes they do, and, in my case, visual inspection showed actual hardware issue related to the function not working in the test software. If you have checked software version and power supply, a visual inspection might reveal some problem. This is also one interest of Open Hardware: you have all the needed CAD files to do basic expertises.
EDIT : OK I made a quick-and-dirty fix, replacing FR4 and FR5 with solder (yes, I’m aware this can have a negative impact on power supply noise and RF performance all together) but it did the job: now LimeQuickTest give me “PASSED” for all steps.
Hello,
I tried to follow instructions in this post connecting the output of the USB blaster clone to the LimeMini JTAG 7 pin header with the pinout mentioned but it cannot be recognized by the programmer (running Auto-Detect)
This is Quartus Prime version 18.0.0 on Linux Ubuntu 16.04.4
Brgds, Edouard.
Do you get the same message with 15.1 patch level 2 that was used with the limesdr-usb or possibly Prime Version 17.1.0 Build 590 10/25/2017 SJ Lite Edition that is mentioned in some of the FPGA gateware files for the mini.
It may not be the cause, but best to clone Lime Microsystems development environment as much as possible.
EDIT: Oh and did you download and install the Altera qdz files for the MAX 10 (10M16SAU169C8G is in the mini).
As I mentioned some time ago, I was not successful as well with this kind of programmer.
Hello @F4EXB
Did you also try using another device driver?
This was fundamental in my case to solve issues and proceed to programming…
Quoting from my previous post:
mario
