mvernengo

Hi, Arthur, thanks for your answer and sorry for delayed answer, I was checking a copuple of things. I must tell you that I have no issue with the SD Card. How do I know? Because I have 2 (two) ZedBoards one "faulty" and another "brand new" and when I swap the SD cards nothing changes (both continue doing the same, tha "faulty" is still faulty and the "brand new" keeps working well). Hence it cannot be an issue with the SD Card because swapping with another ZedBoard's SD Card nothing changes. Just in case let me explain what "faulty" means: 1) When booting with jumpers in "SD Card boot mode" (FAULTY CASE): The "done" LED never lights up; Neither Vivado nor Vitis detect the board. The OLED display never shows "Digilent" brand image. If I connect the UART cable, a strange character is being continuously transmitted. BTW, this is probably because of how the problem started: I had programmed a PS (ARM processor) application that sent some characters with "print" command and I guess this program is called by the system instead of the SD boot. 2) When booting with jumpers in "JTAG boot mode" (in this case, the "faulty" ZB is NOT faulty, it works as expected): The done LED lights up. Both Vivado and Vitis detect the board that can be programmed normally. The UART connection works well and a "Hello Program" in the PS (ARM processor) side works. The OLED display does not show the "Digilent" brand image: this is correct to happen in this JTAG boot mode, I just mention it for reference. In case of the "brand new" ZB, with the jumpers in "SD Card boot mode" the OLED display shows the "Digilent" Brand (correct) and in the "JTAG boot mode" it doesn't (also correct). As far as I can see, there is SOMETHING that cannot be explained that even though the jumpers are programmed to boot from the SD Card, IT STOPPED WORKING on the "faulty" ZB. However I could not find anything wrong in the QSPI Flash ROM because when I put the jumpers in this mode, the two ZedBoards do exactly the same (a 01010101 pattern apears in the 8 main red LEDs). Hence in principle, I cannot assume that any image in the QSPI Flash ROM was damaged in the "faulty" ZB. But then I cannot explain WHY the behavior is so different when in "SD boot mode". You see: what I want is just to put the ZedBoard in the "factory default status" which means that when in the "SD Card boot": a) At power ON, the "done" LED lights up and the OLED display shows the "Digilent" Brand. b) The ZB can be programmed with Vivado and Vitis. But with this "faulty" situation, I can only program the ZB putting the jumpers in "JTAG boot mode". Why I want this? For example in order to hand out the ZB to another person in the university in the same original status that I received it (which means he or she can work normally with the "SD Card boot mode" and they can see the expected "Digilent" brand in the OLED and that they do not need to change to "JTAG boor mode"). Also, because I don't have the LEAST idea of WHY this change of behavior happened and this means that there is something about how the ZedBoard works that I should know but I don't (actually the latter is the main reason). Many thanks. Martin.

I recently posted the below request for assistance for restoring my ZedBoard's original default booting, but even though I did receive an answer, there was no solution. The problem is that my ZedBoard is no longer showing the Digilent brand image in the OLED display and I want to restore this default behavior when booting. As I had no solution, I looked in ChatGPT, and the robot answer was that I needed to get the "original boot image for the ZedBoard". Is this the correct answer? (I am not sure that I can rely on ChatGPT). Does anybody know how I can get the boot image? My previous post: The following is the complete ChatGPT answer: Restoring the Zedboard to factory booting typically involves re-flashing the board's boot image with the original factory image. Here are the general steps to do so: 1. Obtain the original factory boot image for the Zedboard. This might be available from the manufacturer's website or by contacting their support. 2. Connect the Zedboard to your computer using a USB cable, and ensure it is powered on. 3. Use a flashing tool or software provided by the manufacturer to flash the original boot image onto the Zedboard. Follow the instructions provided with the flashing tool to complete this process. 4. Once the flashing process is complete, disconnect the Zedboard from your computer and power it off. 5. Power on the Zedboard and it should now boot using the factory settings and configuration. It's important to note that flashing the boot image will erase all existing data and settings on the Zedboard, so ensure you have backed up any important data before proceeding. Also, always follow the instructions provided by the manufacturer to ensure a successful restoration to factory booting. Thanks for anyone who can help.

Sorry, I forgot answering about the board revision. I can read PB200-24B Rev. F near the serial number DB1888A.

Hi, JColvin, thanks for your kind response. 1) The image of jumpers was not from my board (sorry for not clarifying that), it was from AVNET booting guide. This one in below image is of my ZB (now set with "JTAG booting mode"): 2) As the jumper names changed from AVNET booting guide and my ZB (MODEx --> MI 0x) I assumed the jumper number is the one to be respected. Hence, I can tell you that all the boards that my university purchased come with the following factory setting: JP7 = MI 02 (= MODE0) ---> GND. JP8 = MI 03 (= MODE1) ---> GND. JP9 = MI 04 (= MODE2) ---> 3V3. JP10 = MI 05 (= MODE3) ---> 3V3. JP11 = MI 06 (= MODE4) ---> GND. 3) I will carefully read the documentation you sent me, but for your reference at this moment my understanding about ZB booting process is almost null. What I can tell you is that: - Until 2 weeks ago I had just used Vivado ( = PL/FPGA programming) with the factory setting as in 2) above and the booting consisted simply in (a) power LED ON, (b) "done" LED ON, (c) OLED displaying the "DIGILENT" logo. - Whenever I powered OFF the ZB, the FPGA programming was lost and the booting was exactly the same as before mentiones (which I assumed was normal unless I changed to some kind of "baremetal" application). - I started using Vitis first time just 10 days ago and followed a tutorial on the web, managing to program a "NAND application" with "AND in the PL and NOT in the PS". The app communicated through serial port without problems to send some hello world message. I also modified it so that it sent an incremental counter of the PS-side through the console every time the NAND output was = 1, stopping the transmission if the NAND output = 0. Hence there is no issue with baud rate at all, I am sure. - Then, I tried to program a more "complicated" (not really) application with (a) information sent from the PS to the PL, (b) the PL doing some data processing (c) the PL sending back the result to the PS and (d) the PS showing the result of the processing in the console. But "something went wrong", it never worked but when I powered OFF/ON the ZB, the "done LED" never lit up again and the OLED displayed remained dark for eternity. I had only power ON LED. - Additionally, the communication was completely lost with ZB, either through the UART-USB or the PROG/JTAG-USB (XSCT). Of course, as PROG interface stopped working, I could neither program the FPGA. - Finally, I found the AVNET booting guide and tried the jumper cofigurations with JP7 to JP11 all to GND ("JTAG booting mode") and I "magically" recovered the communication with ZB through the PROG/JTAG/XSCT USB (again, no baud rate issue I am sure), and I am also being able to program the FPGA side again, but the booting process has not changed: "done" LED never goes ON (except if I program the FPGA, which is now possible) and the OLED display is still not showing "DIGILENT" logo. - I also tried to program with Vitis the app that had originally worked (the incrementing counter) but it is not working anymore. It shows garbage in the console (the FPGA side of this app does work, a LED lights depending on the result of the NAND). But I am sure the baud rate is correct on the PC side because I am still able to communicate and send commands with XSCT, which works with the same baud and other communications settings. - Anyway the important part for me is that the booting process has not returned to normal. Hence, I will keep waiting for additional ideas that you may figure out after my above comments. And meanwhile I will read the documentation that you sent. In case that I have some questions after reading it, I will be grateful if you could continue kindly answering. Thanks again for your help and regards, Martin (mvernengo).

I have been working with ZedBoard for one year by now, but always on the "PL" (FPGA) side. I managed to test many FPGA designs with Vivado 2022.2 without any problem. However when I tried to program the PS side, I did something wrong and now, when I power ZB off and on, the system is not booting with the factory setting anymore. Hence the DIGILENT brand is no longer shown at the OLED display and the blue "done" LED is not lighting up anymore. ---> What I want is to restore the ZB to the original factory setting booting. ---> So that the DIGILENT brand is displayed again at the OLED. In case somebody can help me, I explain below in detail what happened. However, I want to state in advance of below description that I later managed to recover some kind of communication with ZB by changing the settings of the JP7 to JP11 jumpers the "JTAG mode", but the problem is that now I don't know what commands to use with xsct and JTAG-USB connector in order to recover the original configuration booting. ---------------------------------------------------------------------------------------- DETAILED DESCRIPTION OF THE PROBLEM: Some 10 days ago I made my first application for communication between PS (dual core ARM Cortex-A9) and PL with Vitis 2022.2. But when I tried my second application of this type, I did something wrong and lost the communication with Zedboard, either through Vivado or Vitis. This means that Vivado stppped detecting ZB as target and with Vitis, the xsct "target" command could not detect any target giving the message: xsct% targets 2 whole scan chain (DR shift output all ones) (The above result was obtained connecting my notebook serial port to the USB-JTAG port used for programming). Fortunately, as I have another ZB at the university I work, I can know what would be the expected "factory setting" result which is the following: xsct% targets 1 APU 2 ARM Cortex-A9 MPCore #0 (Running) 3 ARM Cortex-A9 MPCore #1 (Running) 4 xc7z020 Additionally, when connecting my notebook serial port to the UART-USB port of ZB, I keep receiving a permanent transmission of a strange ASCII character like in the following image: Interestingly, when I press the PS-RST red button at ZB, the terminal stops receiving this weird ASCII character, but reception is automatically resumed when the PS-RST button is released. Hence, my assumption is that I did something wrong when programming the ZB with Vitis, and for some reason, the ARM CPU got caught in an infinite loop that sends an ASCII character continuosly, and it can no longer execute any normal booting. As a matter of fact, the C program I had tried to implement actually is supposed to send an ASCII text continuosuly inside a loop, (although not the same character all the time but different ones depending on what the FPGA side detects). Also, when I tried to access to the PL side through Vivado, the "Open Target" command at the GUI could NOT manage to detect my "faulty ZB" and of course this means I no longer was able to program any "LED blinking" hardware to test if the xc7z020 SoC was "still alive". All of this happened with the JP7 to JP11 jumpers set to factory status: I then looked into the "ZedBoard Configuration and Booting Guide" and saw that there is a "JTAG booting mode": After setting the faulty ZB jumpers to the "JTAG booting Mode", I managed to obtain the same response as with the "non faulty ZB": xsct% connect tcfchan#1 xsct% targets 6 APU 7 ARM Cortex-A9 MPCore #0 (Running) 8 ARM Cortex-A9 MPCore #1 (Running) 9 xc7z020 Moreover, with this jumper setting, I recovered the connection to the "Faulty ZB" with Vivado on the PL-side and managed to program a "LED blinking" hardware-test configuration without problem. ---------------------------------------------------------------------------------------- CONCLUSIONS: I did something wrong with Vitis and programed the PS-side into some kind of "baremetal application with an infinite loop" that does not allow the "faulty ZB" to communicate with any notebook application that connects through the JTAG-USB (PROG) connector in case the JP7 to JP11 are configure to factory settings. But when I change the jumper settings to "JTAG booting mode" I recover the communication through the JTAG-USB interface, being able to send xsct commands and program the PL again. But what I want is to simply return the "faulty ZB" ti the original factory state, meaning that with the normal factory setting of the ZB I can also program the de PL side and connect using xsct commands and more important that the booting process has the result of showing the DIGILENT brand in the OLED display. Any help or comment will be deeply appreciated. Thanks in advance.

Where can i find for downloading the following files mentioned as "reference design" in the "ZedBoard Configuration and Booting Guide"? BOOT.BIN: Boot image of First Stage Boot Loader (FSBL), PL bistream, and GPIO test application. bootimage.bif: Boot image information text file. cp_from_sdk.bat: Batch file to copy hardware bitstream and software executables from the SDK workspace. gpio_test_0.elf: The golden ARM executable for the GPIO test application. load_bits.tcl: TCL script to load the PL bitstream via XMD. make_bootbin.bat: Batch file to run the command to create the boot image file. ps7_init.tcl: TCL script to initialize the ARM processor. run_gpio_test.bat: Batch file to run the commands to load the PL bitstream of the hardware design, initialize the processor, and download the GPIO test application. run_uboot.bat: Batch file to run the commands to initialize the processor and download the u-boot application. system.bit: The golden FPGA bitstream of the hardware design required to run the GPIO test application. u-boot_autoboot_disabled.elf: The golden ARM executable for the u-boot application used to program the QSPI Flash. xmd.ini: Command file used by XMD to configure the PL with the hardware bitstream, initialize the processor, and download the software applications. zynq_fsbl_0.elf: The golden ARM executable for the Zynq FSBL.doc: Contains documentation for this design: pa: Contains the PlanAhead hardware project and SDK workspace files and folders. SDK_sw: Contains the GPIO test software application source files. boot_image_golden.zip: Contains pre-built BOOT.BIN boot image for this design. demo_golden.zip: Contains the golden copies of the files in the demo folder.