cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
weifan
Visitor
Visitor
346 Views
Registered: ‎02-24-2021

Error while changing MIO assignment to I2C, and cannot find DGB_TRACE clock

Jump to solution

Hello,

I am trying to set up trace via MIO, and encountered two different issues. Much appreciate if anyone can provide some help

The board is ZYNQ Ultrascale+ MPSoC (zcu102) with Vivado and Vitis both 2020.2

I was following Lauterbach's document for ZYNQ trace. (page 19) In summary, to set up the MIO trace, I would like to connect MIO to trace and set the DBG_TRACE clock. My plan was to create appropriate hardware design and run hello world template first.

1. Usually after adding MPSoC to the design, and Run Block Automation, the xra works fine for the helloworld template. The Automation sets I2C 0, I2C 1 to MIO[14:15] MIO[16:17] respectively. However,  when I assign them to different MIO (after applying the preset and disable other conflicts MIO), and run the helloworld, error would generate. The reason for the reassignment is that I plan to use MIO[0:17] for the trace.

Screenshot from 2021-03-25 15-57-50.png

Screenshot from 2021-03-25 15-58-22.png

 I attached the xra file that generates the error ( I2C 0/1 to MIO[22:23] and MIO[24:25] ). I am aware that the I2C is a must for the FSBL https://www.xilinx.com/support/answers/66523.html . Am I doing something wrong? e.g. other actions to take when reassigning the I2C other than toggle the PCW menu?

2. Second issue arises when I use MIO[26:43] or MIO[52:69] for the trace ( so that I don't need to reassign the I2C after the Automation). But when I do that, the DBG_TRACE clock option disappears in the PCW. So what's the explanation for that..?

 

Thanks in advance if someone can give some help or give me a direction to investigate more (p.s. I am still on a huge learning curve on this, so I might miss some common sense procedures, so please don't hesitate to give any suggestions

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
weifan
Visitor
Visitor
153 Views
Registered: ‎02-24-2021

Update, still I didn't figure out the I2C issue. But for people who are also trying to set up the Lauterbach debugger, I found the solution provided by Xilinx is working under 2018.3 toolchains. If you already have the onchip trace working, after implement this design, the analyzer should be able to figure out the rest automatically. https://www.xilinx.com/support/answers/66669.html . This design does not need to reassign I2C. 

I use the above design plus Petalinux. 

View solution in original post

0 Kudos
3 Replies
venui
Moderator
Moderator
220 Views
Registered: ‎04-09-2019

Hi @weifan ,

On ZCU102 board MIOs which are mapped already will not allow you to reassign to other with out deselecting from the current user.

I hope the MIOs which you are trying are used by some other in the design please cross verify the dame before going to assign.

Regards,
Venu

0 Kudos
weifan
Visitor
Visitor
199 Views
Registered: ‎02-24-2021

Hi @venui ,

Thank you for your reply. I believe Vivado would raise an Error and prevent user from generating .xra, if there are MIO assignment conflicts. I have carefully deselect the conflict MIO assignment, so that to produce a xra that Vitis and Petalinux could read. I have attached the project, if anyone would be interested in looking more into it. The design is generated with Vivado 2018.3 , and in SDK with patch https://www.xilinx.com/support/answers/72113.html

I have did some tests. It seems that the moment I reassign the I2C to different MIOs other than the preset (MIO 14~17), a faulty FSBL would be generated. This faulty fsbl when executed, would not print any message via UART. In addition to that, the Petalinux would also generate a faulty zynqmp_fsbl in image/kernel which did not print any info via UART.

Under this condition, if I replace the faulty FSBL with another one generated with a design in which I2C are assigned to the preset MIO 14~17, then this FSBL would in fact run the hello world, and successfully boot the linux. But in this case, I don't know whether the MIOs are assigned as I intended them to be. On confluence, it says the FSBL is not responsible for many board setting, https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842019/Zynq+UltraScale+FSBL , but still I don't know whether this replaced FSBL would achieve what I want. At least, after using this method, the Lauterbach still cannot read the trace. 

The above behaviors exist for both 2020.2 and 2018.3

If anyone can explain whether the FSBL is responsible for the MIO assignment, or provide some other guidance that would be great. In our research we do need to use the trace to probe the core to get some insights. Thank you very much in advance! 

0 Kudos
weifan
Visitor
Visitor
154 Views
Registered: ‎02-24-2021

Update, still I didn't figure out the I2C issue. But for people who are also trying to set up the Lauterbach debugger, I found the solution provided by Xilinx is working under 2018.3 toolchains. If you already have the onchip trace working, after implement this design, the analyzer should be able to figure out the rest automatically. https://www.xilinx.com/support/answers/66669.html . This design does not need to reassign I2C. 

I use the above design plus Petalinux. 

View solution in original post

0 Kudos