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.

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

  • Thank you mhennerich! We have been successful in flashing the pluto from a "blank" state! This is very helpful and I have learned a lot from this. 

    Here were the steps for clarity. Please correct me If I am incorrect at any point as I am hoping this post will help others. 

    For these steps to execute correctly, you need to have both a Xilinx Platform Cable II and a UART to USB converter.

    1. Ground JTAG_BOOT pin, power on board. After board has been powered on, remove the ground from JTAG_BOOT.

     - This will boot the Zynq into JTAG Mode as opposed to QSPI mode and will allow for writing to the flash.

    2. Open Vivado SDK 2017.4 and execute the run.tcl file in the XCST terminal. *Notice the command XMD being used is depreciated in later versions of Vivado. Once this step is completed, you should see uart output of u-boot. There should also be a new USB device recognized on the computer(Gadget Device).

    The following steps need to be executed from the run.tcl file. 

     - Program the bitstream into the Zynq

     - Source the ps7_init.tcl

     - Apply ps7_init and ps7_post_config

     - Download u-boot.elf 


    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

  • One minor comment -

    You don't need to write the bitstream.