is that the correct FW version from Github for programming link?
Yes, its correct FW for boards v1.4(s)
ok, something new.
Over USB3 after step 6 board disconnects and never connects back (no dmesg\udev messages, no device in ConnectionSettings).
But before disconnecting it gives success message box:
After i press reset button or unplug-plug it’s back to being WestBridge. Which is expected for RAM FX3 fw as far as i understand.
after step7 over USB2.0 device info looks like this:
if at this point i try to open self_test.ini i get Failed to load file: message box and in console i see LimeSuiteGUI spitting out:
########################################################
## !!! Warning: gateware version mismatch !!!
## Expected gateware version 2, revision 6
## But found version 0, revision 0
## Follow the FW and FPGA upgrade instructions:
## http://wiki.myriadrf.org/Lime_Suite#Flashing_images
## Or run update on the command line: LimeUtil --update
########################################################
steps 8, 9, 10 over USB2.0 give no error, except this one (which as far as i understand is minor wx gui issue):
full backtrace:
backtrace
ASSERT INFO:
../src/gtk/gauge.cpp(67): assert "0 <= m_gaugePos && m_gaugePos <= m_rangeMax" failed in DoSetGauge(): invalid gauge position in DoSetGauge()
BACKTRACE:
[1] wxGauge::DoSetGauge()
[2] void std::vector<unsigned char, std::allocator<unsigned char> >::emplace_back<unsigned char>(unsigned char&&)
[3] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[4] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[5] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[6] wxEvtHandler::TryHereOnly(wxEvent&)
[7] wxEvtHandler::ProcessEventLocally(wxEvent&)
[8] wxEvtHandler::ProcessEvent(wxEvent&)
[9] wxEvtHandler::ProcessPendingEvents()
[10] wxAppConsoleBase::ProcessPendingEvents()
[11] wxApp::DoIdle()
[12] g_main_context_dispatch
[13] g_main_loop_run
[14] gtk_main
[15] wxGUIEventLoop::DoRun()
[16] wxEventLoopBase::Run()
[17] wxAppConsoleBase::MainLoop()
[18] wxEntry(int&, wchar_t**)
[19] __libc_start_main
[20] _start
after i click continue i get success dialog:
in console there is following messages:
Programming finished, 186040 bytes sent! 129421 ms
Programming finished, 0 bytes sent! 21 ms
firmware is updated and device disconnects.
after it connects back device is WestBridge again.
addr=04b4:00f3 is the FX3 Boot-loader *1
addr=1d50:6108 is Myriad-RF LimeSDR-USB (ref: http://wiki.openmoko.org/wiki/USB_Product_IDs )*2
*1 The device is booting up from a 32K ROM inside the FX3 USB chip, in recovery mode. The normal reason for this is because it is being forced into this mode by jumper J13 being disconnected (ref: https://wiki.myriadrf.org/images/3/3b/LimeSDR-USB-Overview.jpg ).
*2 The device is either running the a firmware from RAM, or from flash. If it is running from RAM then this is when you should be installing the current firmware onto the the flash chip for the FX3 USB controller. And then the latest paired/corresponding firmware/gateware/bitstream onto the FPGA’s separate flash chip.
If you are seeing “addr=1d50:6108” on a disconnect-reconnect then you have a valid firmware on the flash chip for the FX3 USB chip (and you have reinstalled J13 jumper so that the device boots up normally from a valid firmware and bitstream stored on flash). And everything should be fine.
1 Like
Ok,
So after step 7 using USB2, it detects correct FX3 FW, bad FPGA GW, FX3 programming to Flash doesn’t give any errors but then it fails to boot from Flash.
The one more thing that you could try is programming FPGA GW first (maybe bad GW is preventing FX3 from booting somehow).
To do that after step 7:
a) In programming window select ‘Altera FPGA’ and ‘Bitstream to flash’ and click ‘Program’.
use GW from: https://github.com/myriadrf/LimeSDR-USB_GW/blob/master/output_files/LimeSDR-USB_lms7_trx_HW_1.4.rbf
b) After this the device will probably get reset so you will have to program FX3 to RAM again to check FW and GW version in device info.
c) If GW versions is no longer 0’s, try programming FX3 to flash again.
If all this fails, then I don’t have any more ideas.
Also, that issue with USB3 is strange, maybe there is something wrong with your board or power power delivery to board when using USB3 port.
i’ve never disconnected J13 (FX3 BOOT) jumper for update or boot, is that correct thing to do?
You would only need to remove it if you deliberately wanted to force the device into recovery mode, but if it is already in recovery mode. leave the jumper in place. With that jumper removed it would boot into recovery mode every single time that it is powered on whether there is valid firmwares on the two flash chips or not (FX3USB and FPGA). For a normal everyday flash updates, you would not touch J13.
1 Like
after programming your step a over USB2.0:
- i get two of same WX error message boxes
- then success upload message box
- then device disconnects
- it reconnects back as WestBridge
- connect to WestBridge from LimeSuiteGUI
- gw 0 rev 0 in device info
- i upload debug FX3 FW to RAM again
- connect to LimeSDR from LimeSuiteGUI
- gw 0 rev 0 in device info
I don’t have any more ideas now., sorry.
Are you sure you used FPGA programing in a) as success message that you posted says FX3?
Also ,when you get these ‘upload success’ messages, does the progress bar fills up or you get them right after clicking ‘Program’? (just thinking if there might be something wrong with status reporting)
yes, i’m sure, i just copy pasted wrong image without looking. sorry. updated image.
- ‘upload success’ seems instant when uploading to FX3 RAM (i guess it should be that way for RAM)
- it takes like a minute or so for upload to FX3 flash and progress bar fills up from 0% to 100%
- and it’s longest for bitstream to flash fpga upload and progress bar fills up from 0% to 100%
All that looks normal.
Yes, RAM programming should be instant.
As program bar fills up it means that software gets ‘good’ responses from FX3 when uploading images. At this point, I am not sure what could be wrong. I will ask people working with FX3 and hardware to look into this issue.
1 Like
I have just remembered that you can also try program FX3 FW to flash using tools from Cypress that come with FX3 SDK (requires registration for download):
http://www.cypress.com/documentation/software-and-drivers/ez-usb-fx3-software-development-kit
On windows the tools is called ‘Control Center’ (CyControl.exe) while on linux version it’s ‘cyusb_linux’. As you are using both Linux and Windows, I think Windows version may be more user-friendly.
It uses a bit different method for programming FX3 Flash, so it may be worth a try.
1 Like
i’ve installed cypress drivers on windows and now LimeSDR device identified as Cypress FX3 USB BootProgrammer Device.
i’ve tried CyControl.exe now and it does exactly the same thing for me:
-
USB 2.0
- when i program debug FW version from Github to RAM: device disconnects and connects back as Myriad-RF LimeSDR-USB
- after that if i programm debug FW version from Github to SPI FLASH or just reset it: device disconnects and connects back as Cypress FX3 USB BootProgrammer Device (that is expected result for RAM reset ofc, but not for SPI FLASH)
-
USB 3.0
- when i program debug FW version from Github to RAM: device disconnects and never connects back
- after reset it comes back as Cypress FX3 USB BootProgrammer Device
- if i try to upload debug FW version from Github to SPI FLASH without RAM step device disconnects and never connects back
I see two possible scenarios here, it looks like you have run through the logical steps (but it would be worthwhile putting the board to one side and waiting until office hours in the UK when I’m sure that someone working for Lime Microsystems will chime in and say something totally obvious that we are all missing).
- The the J13 jumper is not connecting both pins, I’d remove it and reconnect it carefully (no force should be involved in removing or connecting it).
- That the FX3 USB flash chip is kaput.It could be a faulty part or a dry solder joint on the PCB.
P.S. if you are programming the flash using SPI, you should be using the current (flash) firmware and not the debug (RAM) firmware.
- There does not seem to be much of a gap between plastic part of jumper base and removable jumper part. Jumper needs no force to put on and seems to have no jiggling and sits nicely on it’s pins. I don’t see solder connection between jumper pins on the back of the board to the best of my magnifying glass magnified sight.
- The thing about something being faulty is that before first update on Windows 10 i could see LimeSDR as Myriad-RF LimeSDR-USB in Windows 10 device manager. There is still plenty of things that could go wrong though.
PS: I’ve tried CyControl.exe upload LimeSDR-USB_HW_1.3_r3.0.img to SPI FLASH with same results (not working). Would that be correct version of FX3 FW for my LimeSDR v1.4s?
I’d be inclined, if it was my board, to put it to one side and just wait until the true experts are about (which would be IMO be UK office hours on Monday, so ~33 hours from now).
1 Like
Hello @rndr,
Let us start from the beginning.
There is not enough power from USB2 to supply LimeSDR-USB board. Hence forget USB2 ports as well as USB2 not powered (or even powered) hubs. Connect the LimeSDR-USB board to the USB3 PC port directly.
Actually it looks like you do not power your board properly. I would try these options:
- This one is preferable in your case: do you have a proper external power supply? If yes, then try update procedure from my post you are referring to.
- If you do not have an external power supply, then connect the board directly to USB3 port and then try update procedure from my post you are referring to again.
- Proceed up to step 6, inclusive. Then reconnect USB cable and check how the board is described in device manager.
- Let me know about the result.
By the way, is there any possibility to try another machine with USB3? What is your PC or mother board?
Hello,
Arn’t 2headed usb cable that came with the board should be adressing power needs?
- I don’t have external power supply
-
-
- I will have access to board after work, so I can try that then, but I beleive I have already done steps you are adressing over direct USB3 connection or maybe USB3 powered hub (not sure, can’t remember now) here.
-
I believe I don’t have any other USB3 capable machine. I’ll recheck after work. Motherboard is ASUS P9X79 PRO.
Cable itself is not a power source, isn’t?
I am waiting for item 4 results, when connected to PC directly.
1 Like