|
||||||
|
"The emPower Zynq evaluation board with its fast CPU offers the optimal evaluation platform for testing SEGGER software. The components of the all-in-one solution emPower OS included in the software package require very little RAM capacity which results in eliminating the need for external RAM on the board. With the programmable FPGA of the CPU developers can configure additional circuits and functions, for example speeding up the software algorithms. The emPower Zynq evaluation board is built around the Xiliny Zynq XC7Z007S SoC from Xilinx and comes with the J-Link OB on-board debug probe, a version of SEGGER’s industry-leading debug probe. The board has four extension connectors: an Ethernet and SD Card interface as well as HiSpeed USB host and device interfaces." (Source: "emPower Zynq" SEGGER) The problem is that you can very quickly make the board unusable if you’re not careful. I can tell you that I know what I’m talking about. If you only want to develop software for this board in the first step, or use the examples from SEGGER, there should be no problems. My mistake was that I created and used a faulty FPGA (PL) image myself. More on this later. To make this perfectly clear: There are no problems with the board. The problems were caused by my own mistakes.
And that’s why this type of marking exists, to show you what I did wrong and how I tried to fix it.
Important: Do not power the board simultaneously by the J-Link OB (J700) connector
and the main debug/trace (J201) connector!If you use the debug/trace connector J201, the board
must be powered by J400, the USB device connector.The "Cascade JTAG chain" mode is
only available if you using the main debug/trace connector J201.
When you receive the board, the SPI flash contains the "OS_StartLEDBlinky" program. To understand what can go wrong during use, you first need to know the hardware’s characteristics. A Zynq device contains one or two ARM cores (PS) and the FPGA logic (PL). After power-on, the PL is still "empty" and the ROM Code bootloader ist starting the PS application out of the SPI flash. Among other things, the PS application has the task of writing the "PL image" to the PL. In the case of the emPower Zynq, the "PL image" is a component of the PS application and is stored there in a data array named "_aFPGAData" which is located in the file "BSP_FPGA.c". When using the J-Link OB Connector, J700, the Zynq is in "Independent JTAG chain" mode. This means there is one JTAG for PL and another JTAG for PS available. The PL-JTAG is direct connected to the MIO pins, but the PS-JTAG is connected by EMIO pins and routed through the PL logic. This also means that you can only access the PS via the PS-JTAG if the PL is already loaded.
And that was my problem. I had been working on a PL image and had modified the data array
"_aFPGAData". The new image was accidentally for a 7010 instead of a 7007 Zynq. I was even able
to debug the new version once and could see that the PL component hadn’t accepted the new image.
But after a reset, I couldn’t access the PS anymore because there was no longer a valid PL image
available that provided the PS-JTAG. But there’s also the Main Debug/Trace Connector available.
Perhaps I can solve the problem with it?
J201: Main Debug/Trace Connector When using the Main Debug/Trace Connector, J201, the Zynq is in "Cascade JTAG chain" mode. This mean there is one JTAG available for the PL and PS, which is here direct connected to the MIO pin. This JTAG is available even if the PL is not loaded. An external J-Link can be connected here using a 19-pin Cortex-M adapter. But remember, the board must not be connected by J700 too. Since the J-Link now also supports a Xilinx Virtual Cable (XVC), it can also be used from Vivado to load the PL. The J-Link XVCD Server is part of the J-Link software package (starting with v7.92e). A detailed description of the J-Link XVCD server can be found here. The external J-Link can be used here not only as a Xilinx Virtual Cable (XVC), but also simultaneously as a J-Link for connection to the PS. This allows Vivado and SEGGER Embedded Studio to be used simultaneously via this connection.
I have already used J-Flash to backup the connected SPI flash memory via this port before. I was able to
establish a connection to the PS using the J-Link Commander. However, attempts to establish a connection
using J-Flash were not successful.
Even with J-Link SPI, I couldn’t erase the SPI flash memory. I could read it, but not erase it. So I thought it would be a good idea to remove the SPI flash memory and replace it with a new, empty one. However, when desoldering the SPI flash chip, I damaged the circuit board and was unable to repair it. If you’re unsure about the soldering process or need a helping hand, consider reaching out to someone with experience ;o) When using the PL Config Connector, J200, the Zynq is in "Independent JTAG chain" mode. Here only the PL can be accesses by this connector. For this connector, a Waveshare Platform Cable USB or an external J-Link with Xilinx Adapter can be used. This "empower-z7-embos" project consists of the two projects PS (blinky) and PL (fpga). After unpacking the ZIP file, separate directories for the PS and PL projects are available:
For further example projects such as Ethernet or USB, I would add additional directories like "ethernet" and "usb" here. At the time of writing this tutorial, the following software was used:
To create the blinky project, I installed the emPowerZynq Board Support Package. This automatically installed the Embedded Studio PRO extension as well. Here is an overview of my installed packages in SEGGER Embedded Studio:
The contents of the blinky directory look like this:
The project structure of the blinky looks like this:
I modified the file "BSP_FPGA.c". Normally, this file contains the _aFPGAData array which holds the PL image. I removed the array and now include the file "top_level.c" there:
Accordingly, the additional include path must be added to the project:
The path "../fpga/release" has been added here. How the file "top_level.c" was created from the FPGA bitstream will be explained in the next section. At the time of writing this tutorial, the following software was used:
Additionally, I received a "StarterSrc" project for the PL logic from SEGGER. You can find this project in the download section too. This part is not needed separately, as I already use it in the project here. It is only listed here for your reference.
Note: The AMD Vivado software is not strictly necessary for the PS (blinky) project.
I have already created the corresponding "TopLevel.bin" file and added it to the project.
Vivado is only required if you want to make changes to the FPGA logic.
Here is the description if you would like to create the "TopLevel.bin" file yourself too. The contents of the fpga directory look like this:
The Vivado project is not fully complete at first. It needs to be restored using "RestoreProject.tcl". But why is it stored this way? Vivado projects are very large. A full project contains many generated files (such as synthesis and implementation results, logs, and caches). These can easily reach gigabytes in size and change with every build. Storing all of that in Git would quickly make the repository bloated and hard to manage. Non-deterministic artifacts. Vivado produces files that differ even if nothing in the design has changed (timestamps, internal IDs, etc.). This makes version control noisy and unreliable. Portability issues. Exported Vivado projects are often tied to a specific Vivado version or operating system. Using a TCL script to recreate the project ensures reproducibility across environments. The TCL script "RestoreProject.tcl" contains all commands to rebuild the project. Instead of versioning the entire project, only the sources and the scripts are stored in Git. The project itself can be regenerated later by running the TCL script. And what do I need to do now with "RestoreProject.tcl" to restore the project? Assuming you have extracted the entire project under C:\work, then the full path including the fpga directory is as follows: C:\work\empower-z7-embos\fpga Next, start Vivado and use the TCL Console to change to this directory:
And now run RestoreProject.tcl
It should now take a moment for the entire Vivado project to be generated. You can now generate the "TopLevel.bin" file by clicking on "Generate Bitstream". Depending on the computer’s performance, creating the bistream may take several minutes. If Vivado has finished and hasn’t aborted with an error, then the file "TopLevel.bin"
has been created. The file should now be located in the following directory: Use now the batch file "_create_aFPGAData.bat", located in the directory Double click on "_create_aFPGAData.bat" and the "top_level.c" file will be generated in the "release" folder. A terminal will be launched, and the contents of the window should look like this:
The following files should now be present in the "release" directory:
If you now have the file as well, congratulations! The circle is now complete, and you can now create the "top_level.c" file yourself, which is included in "BSP_FPGA.c" in the PS (blinky) project.
Note: Be warned, be careful, you should only make changes to the PL logic if you know
exactly what you are doing.
No changes to the PL logic are required to run the PS (blinky) project. You have another question: What exactly is xbin2c doing here? xbin2c is part of my xtool collection and can convert a binary file to a c source and header file. In this particular case, simply converting the binary into an array is insufficient. To ensure the array in "BSP_FPGA.c" is recognized as valid in the "BSP_FPGA_Init" function, a corresponding header is required. Additionally, it is assumed that the PL image data is also compressed. xbin2c now fulfills all these requirements when using the "-empz" option. You can see exactly how xbin2c is used in the batch file "_create_aFPGAData.bat". The contents of the file look like this:
Learn from my mistakes, so your projects don’t have to end the same way.
|
||||||
