TE0726 "temporarily bricked"?

[offroad]

Hi,

my TE0726 is giving me a hard time. Maybe I should have picked a less complex first Zynq board.
I'm trying (unsuccessfully) to flash the most simple hello-world design, including FSBL, an empty bitstream and the Xilinx "Hello World" C example with an added loop to print repeatedly.
When I write the bitstream and then run "Hello World", it works and prints through the UART.

Now I've flashed those three files repeatedly, and it never booted. So far so good, but after the latest flashing round (flashing was successful, still no boot) the Zynq does not show on JTAG anymore. Instead, Labtools "autoconnect" complains with "No device detected on target ... (name and number of the Digilent port). It then locks up with "Closing Hardware Target... (Cancel)" in the bottom of the window, the Cancel button does nothing.

open_hw
connect_hw_server
INFO: [Labtools 27-2285] Connecting to hw_server url TCP:localhost:3121
INFO: [Labtools 27-2222] Launching hw_server...
INFO: [Labtools 27-2221] Launch Output:

****** Xilinx hw_server v2018.1
  **** Build date : Apr  4 2018-19:32:53
    ** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.

open_hw_target
INFO: [Labtoolstcl 44-466] Opening hw_target localhost:3121/xilinx_tcf/Digilent/251633001307A
ERROR: [Labtools 27-2269] No devices detected on target localhost:3121/xilinx_tcf/Digilent/251633001307A.
Check cable connectivity and that the target board is powered up then
use the disconnect_hw_server and connect_hw_server to re-register this hardware target.
ERROR: [Common 17-39] 'open_hw_target' failed due to earlier errors.

The same happens with Vivado 2017.4 on one PC and 2018.1 on another PC and a different USB cable.
Is it possible that faulty flash contents interfere with the Zynq chip responding to JTAG?
What I did then is short J5 (not sure exactly what it does) and it showed up on JTAG. I was able to erase the flash from SDK (add memory device, "Program configuration memory device", enable "blank" but disable "program" check boxes) and everything works as before. The problem is gone.

My question is, does this make any sense or am I chasing shadows with a broken board (unfortunately, it's my only Zynq so far)?
Can a jumper on J5 cause damage to the FTDI chip when it's trying to drive LOW at the same time?

[Antti Lukats]

yes, if you by accident as example flash FSBL that say fails on DDR init it would disable JTAG and semibrick ZYNQ this is a feature of the ZYNQ architecture

you can temp pulldown SPI DO pin as example to force the bootrom to not load the bad FSBL then you should re-gain access to JTAG and recover the spi flash

[offroad]

Hi Antti,

thanks for the explanation. I somehow expected it might need some paperclip acrobatics. As mentioned before, I think I got out of the state by shorting J5 (not sure what JTAGEN actually does - haven't reached that point in the Zynq manual yet...)

BTW, I got it working 30 seconds before the forum notification came in. With the Trenz board files copied into the Vivado directory, the procedure was 99 % as explained by other sources, the missing percent being the modified FSBL_...elf file needed for flashing, as already explained by John above. I used .MCS as binary file for flash (it's stated somewhere else "use .BIN for SD boot (on a larger device), use .MCS for Flash). Might be a red herring, though

[JH]

Hi,

you mean J15, this is for access JTAG on CPLD.
It's currently not directly explaint on TRM, only here:

• https://wiki.trenz-electronic.de/display/PD/TE0726+TRM#TE0726TRM-BlockDiagram

Or schematic(page :

• https://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/Modules_and_Module_Carriers/special/TE0726/REV03/Documents/SCH-TE0726-03.PDF

it's normally not needed to get access.

PS for other readers: special FSBL for 2017.3 and newer, see: https://forum.trenz-electronic.de/index.php/topic,794.0.html

br
John

[offroad]

Oh OK. Now I see it... Then J15 was a red herring, too.
So I wonder how I got it out of its locked state... but the flash chip has nice, large pins, should be straightforward to ground when it happens again.

[user348957]

Thank you for this post.  I ran into this issue today (programmed a bad QSPI image into my TE0726 and zynq device was subsequently not found on JTAG chain).  I was able to pull down pin 5 of U5 and get to the point where the zynq device is present.  I am able to program the FPGA in this state, but I am unable to program a new QSPI image.  The SDK reports the following error when attempting to program the flash...how can this error be overcome?  I am so close to recovering my board!

Zynq> sf probe 0 0 0

SF: unrecognized JEDEC id bytes: 00, 00, 00
Failed to initialize SPI flash at 0:0 (error -2)
Zynq> ERROR: [Xicom 50-186] Error while detecting SPI flash device - unrecognized JEDEC id bytes: 00, 00, 00
Problem in running uboot
Flash programming initialization failed.

ERROR: Flash Operation Failed

By the way, the issue started for me when I created an MCS image for the QSPI with encryption enabled.  The subsequent boot put me into the error state where the zynq was not found on the JTAG chain.  I guess I still have things to learn about secure boot.

[JH]

Hi,
for Zynq use .bin format. .mcs is for native FPGA.

U5-5 is pulled down via R33, see schematics page 4.
MIO2 is a shared pin, it's for boot mode option and flash data signal, you didn't changed boot mode option, but you has disturbed flash access to SoC Boot rom could not get access to flash.
--> on your boot log, xilinx micro Uboot try to read  flash ID, but it get wrong JTAG ID. Maybe connection is still brocken,did you r removed your additional pulldown?



with encrypting you can brick the whole SoC, depending on setting. It's also possible to deactivate JTAG permanently.
I'm not familiar with encrypting, but as I know you must also configure SoC with correct key. Ether use efuse to save key, than it's permanently or bbram than key is only available as long as battery power is available. On TE0726, battery pin is connected to 1.8V, so it's available as long as you not power off the module

For more details see: https://www.xilinx.com/support/documentation/application_notes/xapp1175_zynq_secure_boot.pdf

see https://www.xilinx.com/support/documentation/application_notes/xapp1175_zynq_secure_boot.pdf

br
John