Unbricking PlutoSDR in 2024

Hi m0set ,
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.

The last steps were done without the 'JTAG BOOT' jumper, but I tried it again with the jumper and still nothing seen on the UARTJTAG's USB UART at 115200 baud.

I also tried power-cycling the Pluto after flashing while keeping the 10-pin ribbon and UARTJTAG connected (and both with and without JTAG-HS3 connected) but again, nothing seen on the UARTJTAG USB UART still unfortunately.

Note also, probing the RX test point near the JTAG header on the Pluto with an oscilloscope shows characters being sent in from the computer to the Pluto when typed in the serial terminal at 115200, but probing TX during and after flashing (and also power cycling) shows no characters being sent from the Pluto to the computer (should be U-boot messages).

Hi,

Some ideas.

The JTAG BOOT jumper should not connected.

1. Use a second USB cable to power the Pluto on the power input micro USB. In case your main USB or power source is not reliable/sufficient.

2. You can use the system_top.xsa to create a "Hello World" app. That will let you know if the is any problem with the UART/FPGA.
maybe add some other code and some break points. To see if the zynq behaves as expected, if not, than that SoC can RIP.

Andrei

Hi Anrdei,

I tried a second USB cable to a USB plug-in charger in addition to the main port to the computer, but still nothing on the UARTJTAG USB serial (without JTAG BOOT jumper).

Searching for `system_top.xsa`, I came across building boot images - so is `system_top.xsa` an image that I generate from Vivado/Vitis/HDL code?  Maybe it results in a `system_top.bit` file?  Unfortunately, I haven't used a working Pluto or Xilinx tools beyond these unbricking attempts.

I can program the `system_top.bit` that came with the bootstrap zip separately from the GUI which causes the DS1 LED to light bright.  Separately, I can program `u-boot.bin` from `xsct`.  It all seems so close yet no serial output in either case.

I'll try to create a hello world project some time and will update whether it worked, but for now my Pluto is looking quite dead.

Hi,

From where you got the bootstrap files you can get an archive with all the files used for the firmware.
https://github.com/analogdevicesinc/plutosdr-fw/releases/tag/v0.39

plutosdr-fw-v0.39.zip

There you can find the system_top.xsa file which you can use to create your hardware platform in Vitis.
The xsa is the result of the hdl build. It is an archive containing the bitstream and other info related to the zynq and the rest of the bits and stuff.

You can find a lot of examples on you to create a hello world design for a custom design(xsa file).

Andrei

Thanks Andrei, I'll look into it and give this a try when I return next week... I'll update you.  Paul

Hi m0set,

I've encountered similar problems. Do you have luck now?

MUN

I'm having the same symptoms and have done most of the same experiments trying to unbrick a Pluto. Any news? Did you find a way?

If you described what have you tried and with what, some results/errors, we can try to help you solve it.

Andrei

I won't attempt to repeat the amazingly thorough recitation of results that m0set provided in the thread above. I had what seemed like indistinguishable results.

However, I was able to get back control of my Pluto. In my case, the problem was that I did not realize that dfu-util needs to be run as root (with sudo) on the host machine. I found this surprising, because the operation is one that seems privileged only on the target device, and not on the host device. In the tutorials and documentation I read, there was no strong emphasis given to this requirement. Worse, the dfu-util program never gave any diagnostic message about permissions or any hint that it was restricted from operating on the target device. It just gave wrong results like this:

dfu-util: Device has DFU interface, but has no DFU functional descriptor

Deducing device DFU version from functional descriptor length

dfu-util: Cannot open DFU device 0456:b674 found on devnum 44 (LIBUSB_ERROR_ACCESS)

In retrospect I see now that "LIBUSB_ERROR_ACCESS" was trying to tell me about the permissions problem, but on first reading it seemed that the host was successfully talking to the DFU target, but that it was getting back results pointing to a problem with the DFU support in the target.

Once I noticed that dfu-util needed privileges to work correctly, I found that entering DFU mode using the button on the Pluto was working after all, and I was able to follow the rest of the instructions in the wiki article wiki.analog.com/university/tools/pluto/users/firmware under "Debugging DFU" to restore my Pluto.

As a side note, the privileges dfu-util needs are probably better granted with a udev rule than with sudo, but I couldn't find any documentation suggesting that. Possibly this is on purpose, since a suggested udev rule would be even easier to overlook than the use of sudo to run dfu-util commands.

My problem is solved. I hope this message helps others to solve theirs.

  -Paul

I won't attempt to repeat the amazingly thorough recitation of results that m0set provided in the thread above. I had what seemed like indistinguishable results.

However, I was able to get back control of my Pluto. In my case, the problem was that I did not realize that dfu-util needs to be run as root (with sudo) on the host machine. I found this surprising, because the operation is one that seems privileged only on the target device, and not on the host device. In the tutorials and documentation I read, there was no strong emphasis given to this requirement. Worse, the dfu-util program never gave any diagnostic message about permissions or any hint that it was restricted from operating on the target device. It just gave wrong results like this:

dfu-util: Device has DFU interface, but has no DFU functional descriptor

Deducing device DFU version from functional descriptor length

dfu-util: Cannot open DFU device 0456:b674 found on devnum 44 (LIBUSB_ERROR_ACCESS)

In retrospect I see now that "LIBUSB_ERROR_ACCESS" was trying to tell me about the permissions problem, but on first reading it seemed that the host was successfully talking to the DFU target, but that it was getting back results pointing to a problem with the DFU support in the target.

Once I noticed that dfu-util needed privileges to work correctly, I found that entering DFU mode using the button on the Pluto was working after all, and I was able to follow the rest of the instructions in the wiki article wiki.analog.com/university/tools/pluto/users/firmware under "Debugging DFU" to restore my Pluto.

As a side note, the privileges dfu-util needs are probably better granted with a udev rule than with sudo, but I couldn't find any documentation suggesting that. Possibly this is on purpose, since a suggested udev rule would be even easier to overlook than the use of sudo to run dfu-util commands.

My problem is solved. I hope this message helps others to solve theirs.

  -Paul