Post Go back to editing

Programming / Flashing a Blank Pluto Board


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.

  • Please take a look at the content of the pluto-jtag-bootstrap files released with each release.

    It's important to initialize the PS in particular the clocks and the DDR memory. Otherwise you can't load uboot.

    This step is done my sourcing he ps7_init.tcl script and then running ps7_init and ps7_post_config.


    connect arm hw
    xreset 64

    source ps7_init.tcl

    dow u-boot.elf

    disconnect 64


  • Hello, I was able to figure out my issues. I can now use the run.tcl file to program the bitstream, source the ps7_init tcl and download uboot.elf

    After the disconnect 64 command, the ready LED turns off and the LED1 LED turns on bright and solid. 

    After doing this step, what is the next step in order to fully program the pluto board?

  • 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.


  • 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...

    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'


  • 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?


  • 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?

  • Yes likely that’s an issue 

  • Thank you for your input, I will have to put that pluto aside for now. We are going to have the board parts looked at by our assembly team. 

Reply Children
No Data