Trouble flashing firmware. (Among other things)

[jynik]

Hi there,


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

So, why all the fuss about disabling FPGA autoloading before flashing the v1.6.0 firmware? When the libbladeRF opens a device, it queries some information from the device, and performs some first-time initializations if need be. As a result, if the new firmware is running, and the old FPGA gets autoloaded, we'll run into errors while reading state and peforming configuration during the device open operation.


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

Note that bladeRF-flash -l -f bladeRF_fw_v1.6.0 can be used instead of the CLI's "recover" command to load the firmware into RAM. I figured it'd be simpler just to stay with one tool...

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

Thanks for your patience!
Jon

[schrambo]

Just adding my 2c.

Same issue with windows when loading the new hostex115.rbf (release date 28/12/2013) with the bladeRF-CLI under Windows.
Just stick with the 23/07/2013 FPGA release for now.

[jynik]

jowijo,

If you aren't seeing those errors now, I think you're all set.

If you pull, build, and install the latest host items (libbladeRF, bladeRF-cli, etc) from git, you should see the version numbers matching up, including the FPGA. In the libbladeRF 0.10.0 and earlier, the FPGA version "0.0.0" is just a hardcoded placeholder, since no mechanism to fetch this info was made available until FPGA v0.0.1. Once you're running >= libbladeRF 0.11.0, you should see things match up nicely. Try giving that a shot and let me know if you run into any more problems.

Sorry for the scare! On the bright side, you now are familiar with a surefire way of getting the device back into a known state if you run into bumps in the future. Just make sure you keep the host-side stuff matching as well if you ever revert to old stuff -- use the git changeset posted along with the firmware and FPGA images to locate the appropriate git changeset to checkout.

======

schrambo,

You mentioned similar troubles with new hostedx115.rbf in Windows. Could you confirm that you were loading that FPGA while running FW v1.6.0 and nothing earlier?

If you're seeing anything other than SI5338 errors, please share, and I'll look to dive into things in Windows tomorrow and/or Thursday.



Cheers,
Jon