Post Go back to editing

Programming / Flashing a Blank Pluto Board

Hello, 



I am able to program the FPGA bitstream, but I am unable to program the flash. 

I keep getting an error saying:

"Problem in initializing hardware."

Steps Taken from the Vivado SDK:

1. Program FPGA bitstream using system_top.bit - this finishes and upon finishing, I can see that in addition to the power LED being on, now the user LED is on and solid as well. 

2. From there I short pin 5 of the jtag connector to ground and try to program flash with the following files:

 - u-boot.bin

 - u-boot.elf

The programmer tries to perform the flash but I end up getting the below error message and the user led turns off
"Problem in initializing hardware".

From my experimentation this far, If I try to program the flash without grounding the JTAG_Boot pin, I get an error saying that boot mode is QSPI and the flash programming never finishes. This makes sense. But when grounding the JTAG_Boot pin, I either get the above: "Problem in initializing hardware" or an error relating to failure of the blank check and/or verify after programming. 

"Flash programming initialization failed"

I know i am using the correct bit stream, but I am unsure of the correct files being used for the flash. To my understanding, What I am really trying to do is flash the FSBL so that I do not have to flash the bitstream for every power cycle. 

Is there a generalized step by step list of files that need to be used? my ultimate goal is to learn the process from starting with a "blank" pluto board and being able to get it up and going into it's default delivered state.

Parents Reply Children
  • Once you have bootstrapped uboot via JTAG. You should see it's command line interface on the uart console.

    The next step would be to DFU (boot.dfu) your initial uboot.

    $ sudo dfu-util -D boot.dfu -a boot.dfu

    But be aware in case you are still in JTAG boot mode, SPI access to NOR flash will fail until you remove the bootmode jumper.

    Once you have your initial u-boot in flash, please continue using DFU to load kernel and userspace 

    $ sudo dfu-util -D pluto.dfu -a firmware.dfu

    -Michael

  • Thank you for the reply, 

    For clarity, I will re-list my steps and provide the output of those steps. 

    1. Power on Pluto with JTAG_BOOT pin grounded, after power on, remove ground. 

    2. Run JTAG Bootstrap TCL

      - Programs bitstream

      - Runs ps7_init and ps7_post_config

      - Downloads u-boot

    3. At this point when the TCL is finished running from Vivado SDK, I can see the following output from the Pluto Uart


    U-Boot PlutoSDR v0.20-PlutoSDR-00051-gf5f001e (Oct 15 2018 - 20:38:02 +0200)
    
    I2C:   ready
    DRAM:  ECC disabled 512 MiB
    SF: Detected N25Q256A with page size 256 Bytes, erase size 4 KiB, total 32 MiB
    *** Warning - bad CRC, using default environment
    
    In:    serial@e0001000
    Out:   serial@e0001000
    Err:   serial@e0001000
    Model: Zynq Pluto SDR Board
    Hit any key to stop autoboot:  0
    Booting silently
    BOOT failed entering DFU mode ...
    SF: Locked
    gpio: pin 15 (gpio 15) value is 1
    Entering DFU SF mode ...

    If I try this again, but interrupt the autoboot,

    Hit any key to stop autoboot:  0

    I am presented with a Pluto Terminal 

    Pluto>

    Can you verify that I am following these steps correctly?

  • In addition, when trying to use the first command provided,

    $ sudo dfu-util -D boot.dfu -a boot.dfu

    I get the following output on the terminal. I am using Admin cmd on windows with dfu-util installed. 

    C:\Users\KevinE\Desktop\dfu-util\dfu-util-0.9-win64>C:\Users\KevinE\Desktop\dfu-util\dfu-util-0.9-win64\dfu-util.exe -D C:\Users\KevinE\Desktop\dfu-util\dfu-util-0.9-win64\boot.dfu -a C:\Users\KevinE\Desktop\dfu-util\dfu-util-0.9-win64\boot.dfu
    dfu-util 0.9

    Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
    Copyright 2010-2016 Tormod Volden and Stefan Schmidt
    This program is Free Software and has ABSOLUTELY NO WARRANTY

    Match vendor ID from file: 0456
    Match product ID from file: b673
    No DFU capable USB device available

     

    I can also see in my device manager that there is a new USB device labeled "USB Download gadget" and under properties of this device, it says that it is a Pluto SDR DFU

  • Try:

    dfu-util.exe -d 0456:b673,0456:b674 -D C:\Users\KevinE\Desktop\dfu-util\dfu-util-0.9-win64\boot.dfu -a boot.dfu

    If this doesn't work try to use the dfu-util deployed with the windows driver.

    https://github.com/analogdevicesinc/plutosdr_scripts/blob/master/UPDATE.BAT

    -Michael

  • One one of my pluto boards this works. I can download boot.dfu, pluto.dfu and firmware.dfu. 

    We have a second pluto board in which i am not able to follow the same steps. 

    Pluto 1 - I can follow all these steps.

    Pluto 2 has the following output.

    Using this pluto, I also cannot see the pluto dfu on the device manager as well

    "U-Boot PlutoSDR v0.20-PlutoSDR-00051-gf5f001e (Oct 15 2018 - 20:38:02 +0200)

    I2C: ready
    DRAM: ECC disabled 512 MiB
    SF: Detected N25Q256A with page size 256 Bytes, erase size 4 KiB, total 32 MiB
    *** Warning - bad CRC, using default environment

    In: serial@e0001000
    Out: serial@e0001000
    Err: serial@e0001000
    Model: Zynq Pluto SDR Board
    Hit any key to stop autoboot: 0
    ## Resetting to default environment
    SF: Detected N25Q256A with page size 256 Bytes, erase size 4 KiB, total 32 MiB
    SF: Unlocked
    gpio: pin 15 (gpio 15) value is 1
    Entering DFU SF mode ..."

    Any ideas why this could be? 

  • Update, I was able to fix this issue by interrupting (ctrl c) and lowering to the Pluto> terminal. I then used the cmd saveenv,  to save environment variables. 

    From here I no longer get the "bad CRC" error on booting u-boot. 

    I still cannot see the USB Pluto DFU device...

  • I also tried using your recommendation from the below post, but still, my pluto doesn't show up as a USB device...This is very odd...

    ez.analog.com/.../pluto-firmware-repair

    ok - use setenv instead. Maybe your old uboot doesn't know set.

    Pluto> setenv dfu_sf_info 'set dfu_alt_info boot.dfu raw 0x0 0x100000\\;firmware.dfu raw 0x200000 0x1E00000\\;uboot-env.dfu raw 0x100000 0x20000'
    Pluto> setenv dfu_sf_info 'setenv dfu_alt_info boot.dfu raw 0x0 0x100000\\;firmware.dfu raw 0x200000 0x1E00000\\;uboot-env.dfu raw 0x100000 0x20000'

    -Michael

  • On your failing Pluto was USB working before?

    Once in DFU mode can you connect it to a Linux PC and run the lsusb command?

    -Michael

  • Not sure  on this Pluto if the USB worked before, as we have not tested it in this manner. 

    I have checked the 24mhz clock feeding into the USB IC and there is a clock there.

    I also believe that the USB IC is being powered correctly because both the working and the non-working pluto display the same output for the following scenario.

    Interrupt the DFU SF mode and return the pluto> prompt of u-boot, I try running the usb start command and I receive the following output.

    Pluto> usb start
    starting USB...
    USB0: USB EHCI 1.00
    scanning bus 0 for devices... 1 USB Device(s) found
    USB1: usb1 wrong num MIO: 0, Index 1
    lowlevel init failed
    scanning usb for storage devices... 0 Storage Device(s) found

    When running lsusb on a linux machine with the broken pluto connected, there is no sign of any kind of enumeration. When I try the same test with the working pluto, I can see that there is a new analog devices "gadget" connected. Same results with windows.

    From this standpoint, there seems to  be no issues with the hardware, as both devices are able to start USB0.

  • What exactly is happening when running "run dfu_sf" ? It seems like the working pluto board can enumerate when using the "run dfu_sf" command, and disconnect when out of this mode. It can then re-enumerate when running "run dfu_sf" again. 

    Does this have to do with switching roles? ie. USB OTG Mode?