vitis 2020.2 Program Flash 问题-爱代码爱编程
使用vitis 2020.2的Program Flash的时候，Console会显示下面的异常。串口调试口也会打印FSBL的DATA ABORT之类的异常。主要原因就是如果设置启动模式不是JTAG的情况下，FSBL会异常。所以需要修改FSBL的代码固定位JTAG启动。
主要解决方法：
Problem 1: Default FSBL stops working with error stage,because it didn’t find bootable image on flash.
Solution: used special FSBL where boot mode is set fix to JTAG, see Xilinx AR#70548
Case 2: flash contains bootable design
Problem 1: Vivado starts design from QSPI Flash before selected FSBL will be programmed. This seems to prevent Vivado from starting the selected FSBL correctly, which leads to inconsistencies and terminates the programming
Solution 1: use the same FSBL which was used on the design which was programmed
Solution 2: change boot mode some other a mode which does not boot any design and use special FSBL。
Possible Problem 2: running OS zynq can prevent vivado to get access to QSPI
Solution 1: Stop booting for example on uboot console and try again
Solution 2: change boot mode some other a mode which does not boot any design
wiki的解答：
https://wiki.trenz-electronic.de/pages/viewpage.action?pageId=105689937
AR#00002 - QSPI Programming issues
Issue 1: Programming with Vivado /SDK tools failed in case the boot mode is QSPI
Affected Series:
all Zynq Modules, especially 7 Series Zynq
Possible cases and solutions:
Vivado 2017.2 and older
Case1: flash is empty
no issue
Case 2: flash contains bootable design:
Possible Problem 1: running OS on zynq can prevent vivado to get access to QSPI
Solution 1: Stop booting for example on uboot console and try again
Solution 2: change boot mode some other a mode which does not boot any design
Vivado 2017.3 up to 2018.3
Programming procedure has changed (AR#70146), user must add additional FSBL now which initialise PS before Xilinx micro Uboot starts
Case 1: flash is empty
Problem 1: Default FSBL stops working with error stage,because it didn’t find bootable image on flash.
Solution 1: used special FSBL where boot mode is set fix to JTAG, see Xilinx AR#70548
Case 2: flash contains bootable design
mostly no issue, default FSBL or special FSBL can be used to program flash
Possible Problem 1: running OS zynq can prevent vivado to get access to QSPI
Solution 1: Stop booting for example on uboot console and try again
Solution 2: change boot mode some other mode which
Vivado 2019.x or newer (last tested version 2020.1)
Same programming procedure like 2017.3 up to 2019.3, but Vivado access to Zynqs seems to be changed.
Case 1: flash is empty
Problem 1: Default FSBL stops working with error stage,because it didn’t find bootable image on flash.
Solution: used special FSBL where boot mode is set fix to JTAG, see Xilinx AR#70548
Case 2: flash contains bootable design
Problem 1: Vivado starts design from QSPI Flash before selected FSBL will be programmed. This seems to prevent Vivado from starting the selected FSBL correctly, which leads to inconsistencies and terminates the programming
Solution 1: use the same FSBL which was used on the design which was programmed
Solution 2: change boot mode some other a mode which does not boot any design and use special FSBL
Possible Problem 2: running OS zynq can prevent vivado to get access to QSPI
Solution 1: Stop booting for example on uboot console and try again
Solution 2: change boot mode some other a mode which does not boot any design
Issue 2: Programming with third party tools or own software (barmetal, uboot) failed, in case PS is configured for x4 mode
Affected Series:
all Zynq Modules, especially 7 Series Zynq
Possible cases and solutions:
Problem 1: QE Bit of the QSPI Flash is not set and X4 access failed.
Solution: Write QSPI Flash one time with Xilinx Tools(Vivado or SDK), this will set QE Bit correctly. → This only needs to be done once in case of a problem
Issue 3: Using more than 16MB flash on 7 Series Zynq
Affected Series:
all 7 Series Zynq with more than 16MByte QSPI Flash
Issue 3: Using more than 16MB flash on 7 Series Zynq
Affected Series:
all 7 Series Zynq with more than 16MByte QSPI Flash
