Post Go back to editing

Unbricking PlutoSDR in 2024

Thread Summary

The user attempted to unbrick a PlutoSDR Rev C/D using the official guide but encountered issues with serial communication and DFU mode. The solution involved running `dfu-util` as root (with `sudo`) to resolve a permissions error, which allowed the Pluto to enter DFU mode and be restored. The user also noted that the `JTAG BOOT` jumper should not be used, and the UART output should be monitored from the ADALM-UARTJTAG USB port at 115200 baud.
AI Generated Content
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.