You mentioned this starting after a GRC crash. However, this error is a symptom mixing up FW/FPGA versions which a few folks have run into with the recent merge of changes into master. I'm fairly certain this is what you're seeing, but mind just reviewing the last set of updates you may have applied, and what firmware/FPGA combinration you're trying to use?
I'll start with the assumption that you're seeing this from due to a FW/FPGA mismatch -- if I'm wrong, there's some potentially useful info in this thread for other folks, and the latter parts about recovering via the bootloader may still be helpful. Win win!
First, to summarize the situation...
Firmware v1.6.0 and FPGA v0.0.1 use a faster UART bridge baudrate to allow things like frequency tuning to be performed more quickly. This is obviously a reverse incompatible change (we're still in "unstable" dev mode at this point, marching toward a more stable set of release candidates), so an older firmware will not work with the new FPGA, and conversely, an older FPGA will not work with the new v1.6.0 firmware.
The host library communicates with the SI5338 over the following path. Therefore, if the FX3 and FPGA versions are mismatched, the UART baurdate will be mismatched, and we won't be able to communicate with the SI5338, hance the error you saw.
Code: Select all
Host <-(USB)-> FX3 <-(UART bridge)-> FPGA <-(I2C)-> SI5338
In short, no worries, there's nothing wrong with your bladeRF. We just need to ensure you've got the lastest FPGA and Firmware. (The latest host software is most desirable, although technically, you can still get away with a *slightly* out of data libbladeRF and bladeRF-cli.)
Now, back to our regularly scheduled debugging...
So you mentioned that you're forcing the Cypress bootloader... Are you doing this because you flashed firmware v1.6.0 but forgot to disable FPGA autoloading?
If not, there's no need to go through the whole bootloader process. You should simply be able to do:
Code: Select all
# Disable FPGA autoloading if it's enabled. This can be skipped if you're not using FPGA autoloading, but is harmless. $ bladeRF-cli -L X # Power cycle or plug the board in, just to start off in a known state # Fetch and flash the new firmware, and enable some debug output while doing so $ wget www.nuand.com/fx3/bladeRF_fw_v1.6.0.img $ bladeRF-cli -f bladeRF_fw_v1.6.0.img -v debug # Just for safe measure, power cycle the board after a successful re-flash. # Fetch and load the latest FPGA (change to hostedx115.rbf, depending on your board) $ wget www.nuand.com/fpga/v0.0.1/hostedx40.rbf $ bladeRF-cli -l hostex40.rbf # Now we should see the the latest versions reported by the CLI's "version" command $ bladeRF-cli -i bladeRF> version bladeRF-cli version: 0.10.0-git-4ce8a14 libbladeRF version: 0.11.1-git-4ce8a14 Firmware version: 1.6.0-git-89d57ff FPGA version: 0.0.1
However, as you mentioned being able to reflash the board as well, so here's a step-by-step of entering the bootloader and restoring things, assuming one got into the situation where they have a v1.6.0 flashed and are autoloading the older FPGA. Mind following along and noting where things seem to deviate for you?
The whole jumper thing is that we're forcing an SPI data pin to GND, so the firmware can't be read; the FX3 falls back to the bootloader. Therefore, it's important that you remove the jumper before performing flash operations.
Code: Select all
# Fetch the v1.5.3 firmware, the v1.6.0 firmware, and the latest FPGA $ wget www.nuand.com/fx3/bladeRF_fw_v1.5.3.img $ wget www.nuand.com/fx3/bladeRF_fw_v1.6.0.img $ wget www.nuand.com/fpga/v0.0.1/hostedx40.rbf # Apply the jumper and power on the device # Let's verify we see the Cypress bootloader in dmesg output: $ dmesg | tail ... (Unrelated output trimmed) ... [11816.806889] usb 9-2: new high-speed USB device number 7 using xhci_hcd [11816.825800] usb 9-2: New USB device found, idVendor=04b4, idProduct=00f3 [11816.825805] usb 9-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [11816.825808] usb 9-2: Product: WestBridge [11816.825811] usb 9-2: Manufacturer: Cypress [11816.825813] usb 9-2: SerialNumber: 0000000004B # Good! Now remove the jumper, or else we won't be able to access the SPI flash $ bladeRF-cli -i -v info [INFO] Found FX3 bootloader device on bus=9 addr=7. This may be a bladeRF. [INFO] Use bladeRF-cli command "recover 9 7 <FX3 firmware>" to boot the bladeRF firmware. No device(s) attached. bladeRF> # Now we'll load the firmware into RAM bladeRF> recover 9 7 bladeRF_fw_v1.5.3.img Success! Use "open" to switch to this device. Note that a "load fx3 <firmware>" is required to write the firmware to flash. # The firmware is loaded...now attempt to open the device and view info about it bladeRF> open bladeRF> info Serial #: 00000000000000000000000000000000 VCTCXO DAC calibration: 0x8100 FPGA size: 40 KLE FPGA loaded: no USB bus: 10 USB address: 10 USB speed: SuperSpeed Backend: libusb Instance: 0 bladeRF> version bladeRF-cli version: 0.10.0-git-4ce8a14 libbladeRF version: 0.11.1-git-4ce8a14 Firmware version: 1.5.3-git-276379e FPGA version: Unknown (FPGA not loaded) # Let's flash firmware v1.5.3... bladeRF> load fx3 bladeRF_fw_v1.5.3.img Flashing firmware from bladeRF_fw_v1.5.3.img... [INFO] Erasing 0x00020000 bytes starting at address 0x00000000. [INFO] Writing 0x00020000 bytes to address 0x00000000. [INFO] Verifying 0x00020000 bytes at address 0x00000000 Done. Cycle power on the device. bladeRF> quit # Now we power cycle the device... # Check dmesg again... $ dmeg | tail [12768.462660] usb 10-2: new SuperSpeed USB device number 11 using xhci_hcd [12768.480459] usb 10-2: Parent hub missing LPM exit latency info. Power management will be impacted. [12768.483510] usb 10-2: New USB device found, idVendor=1d50, idProduct=6066 [12768.483517] usb 10-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [12768.483521] usb 10-2: Product: bladeRF [12768.483525] usb 10-2: Manufacturer: Nuand [12768.483529] usb 10-2: SerialNumber: 00000000000000000000000000000000 # Hello, device! Now let's verify that we can probe for it... $ bladeRF-cli -p Backend: libusb Serial: 00000000000000000000000000000000 USB Bus: 10 USB Address: 11 # Now disable FPGA autoloading. $ bladeRF-cli -L X Flashing fpga... Disabling FPGA flash auto-load [INFO] Erasing 0x00010000 bytes starting at address 0x00040000. Done. # Flash new firmware $ bladeRF-cli -f bladeRF_fw_v1.6.0 Flashing firmware... [INFO] Erasing 0x00020000 bytes starting at address 0x00000000. [INFO] Writing 0x00020000 bytes to address 0x00000000. [INFO] Verifying 0x00020000 bytes at address 0x00000000 Done. # Now power cycle again (last time!) # Open up the device, and we should see that we're running v1.6.0 $ bladeRF-cli -i bladeRF> version bladeRF-cli version: 0.10.0-git-4ce8a14 libbladeRF version: 0.11.1-git-4ce8a14 Firmware version: 1.6.0-git-89d57ff FPGA version: Unknown (FPGA not loaded) # Load that brand new FPGA... bladeRF> load fpga hostedx40.rbf Loading fpga from hostedx40.rbf... Done. # And now we should be back in business... bladeRF> version bladeRF-cli version: 0.10.0-git-4ce8a14 libbladeRF version: 0.11.1-git-4ce8a14 Firmware version: 1.6.0-git-89d57ff FPGA version: 0.0.1
If you're still running into issues at this point, please share the logs from above. For bladeRF-cli infocations, provide verbose output via the "-v verbose" command line argument.
The following items might also be useful for us:
Code: Select all
$ bladeRF-cli --version $ bladeRF-cli --lib-version