Post Go back to editing

Unbricking PlutoSDR in 2024

Category: Hardware
Product Number: ADALM-PLUTO

Hi all, I am following the official Unbricking PlutoSDR wiki guide on a bricked Pluto, however as this guide is quite outdated, here I describe my attempt at unsuccessfully unbricking a Pluto.  The hardware was handed to me after a team of satellite engineers had difficulty unbricking it, so I am not sure how a working unit should appear.  My configuration is:

Following the steps of the guide as follows:

> After the JTAG programmer is connected, provide power to PlutoSDR using either of its USB connectors. Once powered the D5 led should illuminate to signal the JTAG connection to the programmer is alive.

With the 10-way JTAG ribbon cable connected, I power the JTAG-HS3, then power the PlutoSDR (USB port "P3" plugged in to the PC, as shown in the guide figure).  The red LED labeled "VIO" lights on the UARTJTAG board.  My Pluto dimly lights the LED with designator DS2 (the one in the corner of the PCB).  The Pluto LED DS1 remains off.

> 1. Plug in JTAG as documented above into Pluto and verify you can connect with Vivado

I run:

$ source /tools/Xilinx/Vivado/2024.1/settings64.sh
$ xsct

****** Software Commandline Tool (XSCT) v2024.1.2
  **** SW Build 0 on 2024-09-05-05:57:41
    ** Copyright 1986-2022 Xilinx, Inc. All Rights Reserved.
    ** Copyright 2022-2024 Advanced Micro Devices, Inc. All Rights Reserved.


Warning: XSCT has been deprecated. It will still be available for several releases.It's recommended to start new projects with new python command line tool.
         Use "vitis -s <script>" (script mode) and "vitis -i" (interactive mode) to load new Python CLI for Vitis.


xsct% connect -host localhost -port 3121
Connection refused
xsct% 

With the command having failed, I launch the `vivado` GUI from the command line and click on the "Open Hardware Manager" task link, then Menu -> Tools -> Open new target.  Connect to local server.  The `xilinx_tcf` hardware target is auto-detected with JTAG frequency 15000000 and hardware devices `arm_dap_0` and `xc7z010_1` are auto-detected.  Hardware server settings on next page reads `localhost:3121`.  Closing the dialog, the hardware list shows the status of `arm_dap_0` as "N/A", and the status of `xc7x010_1` as "Not programmed".

Now trying again with the command line, I get

$ xsct

****** Software Commandline Tool (XSCT) v2024.1.2
  **** SW Build 0 on 2024-09-05-05:57:41
    ** Copyright 1986-2022 Xilinx, Inc. All Rights Reserved.
    ** Copyright 2022-2024 Advanced Micro Devices, Inc. All Rights Reserved.


Warning: XSCT has been deprecated. It will still be available for several releases.It's recommended to start new projects with new python command line tool.
         Use "vitis -s <script>" (script mode) and "vitis -i" (interactive mode) to load new Python CLI for Vitis.


xsct% connect -host localhost -port 3121
tcfchan#0
xsct% targets
  1  APU
     2  ARM Cortex-A9 MPCore #0 (Running)
     3  ARM Cortex-A9 MPCore #1 (Running)
  4  xc7z010
xsct% 

There must be a command that is missing from the command line instructions, but now the command appears to work after the GUI procedure I described.

> 2. Download the JTAG bootstrap zip from the firmware release page (plutosdr-jtag-bootstrap-<Firmware Version>.zip)

> 3. Unzip the zip then source the run.tcl inside with xmd from the Xilinx tools (xmd -tcl run.tcl). We are done with JTAG now

The command `xmd` no longer exists, however the zip file contains a clue in the form of a file called `run-xsdb.tcl` with contents that look similar to the `run.tcl` in the instructions.  The command to run is found in the file comment.  Presumably, `xsdb` is a replacement for `xmd`.

~/Downloads/plutosdr-jtag-bootstrap-v0.39$ xsdb run-xsdb.tcl
attempting to launch hw_server

****** Xilinx hw_server v2024.1.2
  **** Build date : Aug 28 2024 at 13:40:10
    ** Copyright 1986-2022 Xilinx, Inc. All Rights Reserved.
    ** Copyright 2022-2024 Advanced Micro Devices, Inc. All Rights Reserved.

INFO: hw_server application started
INFO: Use Ctrl-C to exit hw_server application

INFO: To connect to this hw_server instance use url: TCP:127.0.0.1:3121

$

The command prompt returns without any explicit success message but no error neither.  LEDs are same as before.  The instruction reads "We are done with JTAG now", but not sure what that means, whether we should leave it plugged in or unplug it.  (spoiler: it made no difference in my case).  For what it's worth, I left it plugged in and considered it "done".

> 4. Next plugin a USB cable to the UART port of the ADALM-UARTJTAG connector and open a serial session (Putty or screen or …)

A green LED (labeled "VUSB") lights up on the ADALM-UARTJTAG when plugged in as described.  The guide doesn't give any details about what baud, stop bits, parity etc are needed, however despite trying virtually all possible common serial baud rate speeds and parameters, I was unable to get any sign of life from the serial port, and no u-boot menu was seen as indicated on the next step of the procedure.

Notably, after running the `xsdb` tcl script causes subsequent connection attempts with `xsct` to fail.  Heading back to the GUI and reconnecting to the JTAG-HS3, the Xilinx still shows as "Not programmed".

After turning it off and on again, I reconnect with the GUI as before, except this time I click "Program device" with the bitstream file `system_top.bit`.  There appears to be no "Debug probes file", however this does not seem to prevent the programming from going ahead.  It appears to succeed, listing `arm_dap_0` as "N/A" (as before) but now `xc7x010_1` shows as "Programmed" and now the DS1 LED lights up much brighter than the constantly lit dim DS2 led.  Despite this promising sign of life, u-boot remains unseen on any serial port with any baud rate and parameters I have tried, repeatedly typing, sending CTRL+C, and hitting ENTER with no result (to both Pluto and JTAG serial ports).  There appears to be a `u-boot.elf` file in the zip archive, but I haven't yet found a way to get this onto the board by the command line or the GUI.  Typing the tcl script lines one by one appears to

Can anyone spot where it's going wrong, or if it may even be a sign of dead Pluto?

It would really benefit the community to at least update that official unbricking guide, even if only to instill us with some confidence that the guide isn't broken and that we're not doing anything wrong.  It would help with:

  • specifying the serial parameters (baud rate, stop bits, parity etc) needed to open the serial session (and whether it's to the Pluto's serial or the JTAG's serial)
  • whether the JTAG should be unplugged
  • a working command line procedure to connect to the debugger first time with `xsct` that doesn't rely on the GUI
  • update the `xmd` command to `xsdb` (or whatever the correct command is)
  • some links to the zip file in the guide would be helpful

I am still hoping to get myself back into HDL/FPGA/SDR development after this thing is unbricked.

  • Hi  ,
    Indeed the command xmd no longer exists, the valid one is "xsct run.tcl"

    In regards to the UART parameters: https://wiki.analog.com/resources/fpga/uart_setup
    However, when going trough the steps this has been observed:
    - after programming the bootloader with "xsct run.tcl" there is output on the UART (uboot boot log)
    - pluto then boots dirrectly into DFU mode, step 5 "run dfu_sf" is not needed

    I've observed the same behaviour, the UART is not responding after flashing with run.tcl as Pluto is already in DFU mode.
    I guess that your pluto is recoverable and in DFU.

    Also, when I tried this, disconnecting and reconnecting power to the pluto after "xsct run.tcl" did not seem to make it boot back to DFU, so it's possible that you will need to run "xsct run.tcl" again.

  • Hi Dumitru, thanks for the suggestions, however running `xsct run.tcl` also failed for me:

    ~$ source /tools/Xilinx/Vivado/2024.1/settings64.sh
    ~$ cd Downloads/plutosdr-jtag-bootstrap-v0.39/
    ~/Downloads/plutosdr-jtag-bootstrap-v0.39$ ls
    ps7_init.tcl  run.tcl  run-xsdb.tcl  system_top.bit  u-boot.elf
    ~/Downloads/plutosdr-jtag-bootstrap-v0.39$ xsct run.tcl
    unexpected arguments: arm hw
        while executing
    "error "unexpected arguments: $arglist""
        (procedure "::xsdb::get_options" line 69)
        invoked from within
    "::xsdb::get_options args $options"
        (procedure "connect" line 17)
        invoked from within
    "connect arm hw"
        (file "run.tcl" line 7)
    

    I also tried going through the standard DFU procedure both with and without flashing `system_top.bit` from the GUI however:

    • all of their `iio_attr`, `dfu-util` and `lsusb` commands I have installed but all of them failed to identify the Pluto
    • a mass storage device did not appear on my computer
    • there was no additional network device hardware detected
    • and `dmesg` didn't report any changes

    As before, I tried `xsct` and each step of the DFU procedure both with and without flashing the bitstream file from the GUI (as described in the opening post) and from each of the USB ports, while monitoring any serial port with the correct serial parameters but still nothing so far.

  • Hi  ,
    Sorry for the confusion, I meant to say "xsct run-xsdb.tcl". After running this command Pluto should boot into DFU mode.

    When Pluto is connected with usb to your PC, does the "Analog Devices, Inc. USB download gadget" device appear when running lsusb?

    Also, when booting into DFU mode, Pluto outputs a boot log to the UART port of ADALM-UARTJTAG. Test this by unplugging-plugging the USB connector that powers the Pluto.

  • Hi  ,

    I gave it another try with `xsct run-xsdb.tcl`.  The program appears to complete without any obvious error message shown however it seems (at least from the command output and its effects on the hardware) to be identical to running `xsdb run-xsdb.tcl`:

    ~$ source /tools/Xilinx/Vivado/2024.1/settings64.sh
    ~$ cd Downloads/plutosdr-jtag-bootstrap-v0.39/
    ~/Downloads/plutosdr-jtag-bootstrap-v0.39$ xsct run-xsdb.tcl 
    attempting to launch hw_server
    
    ****** Xilinx hw_server v2024.1.2
      **** Build date : Aug 28 2024 at 13:40:10
        ** Copyright 1986-2022 Xilinx, Inc. All Rights Reserved.
        ** Copyright 2022-2024 Advanced Micro Devices, Inc. All Rights Reserved.
    
    INFO: hw_server application started
    INFO: Use Ctrl-C to exit hw_server application
    
    INFO: To connect to this hw_server instance use url: TCP:127.0.0.1:3121
    

    Tried all the ports and all the combinations as before but the result seems the same i.e., no output on serial, no mass storage, the LED DS2 remains dim and DS1 remains off etc (unlike the GUI method I described above, which gives just an inkling to suggest there is still life in the unit but has its own dead end i.e. no obvious way to run `u-boot.elf` and to see it on the serial port).

    Does your `xsct run-xsdb.tcl` output look the same as mine?