本文将记录，大家在使用主板的过程中遇的一些奇奇怪怪的问题，给遇到相同问题的大家一点参考。
问题不作排序，大家有疑问的也可以在本页面下方进行留言。
问题都是平常大家在使用中来提问的问题，大家遇到相同问题时可以尝试按本贴内容进行调整。
问题一:ZYNQ 在调试PS 程序的时候遇到 Memory write error at (……..) MMU section translation fault
- 问题描述： SDK 或者 Vitis Debug 调试过程偶尔会遇到 Memory write error at (……..) MMU section translation fault。
- 问题原因：主板处于非 JTAG 模式，当我们debug时，系统正在跑原先的程序 ，导致没有响应你的新的DEBUG命令。
- 解决方法：
- 将主板上的拨码开关调到JTAG模式，重新上电或按下POR硬件复位按键，之后再尝试DEBUG。（这里说明下，并不是非JTAG模式下 PS DEBUG都会遇到这个问题，只是有概率会遇到）
- 另外在SDK工程下，勾选 复位整个工程和下载FPGA部分代码的选项 如下图所示 也能解决问题（但是在vitis下，即使勾选了似乎也会遇到报错，如果勾选后仍然报错还是老老实实把工作状态切换成JTAG模式）
问题二：ZYNQ 在调试网络功能的时候（MIO方式），不论如何设置网络功能都永远无法成功访问
- 问题描述： ZYNQ 在调试网络功能的时候（MIO方式），不论如何设置网络功能都永远无法成功访问
- 问题原因：遇到这种问题的情况，有可能因为你的网络工程是从EMIO方式改成MIO方式的，修改后网络ENET 的时钟仍可能保留EMIO的External （外部输入方式）
- 解决方法：将ENET的时钟从External ，修改成IO PLL方式
问题三、FLASH 固化失败，无法正常固化或工作
- 检查SDK或者VITIS工程中是否添加了FSBL部分
- 检查 BLOCK DESIGN 中是否使能了 QSPI FLASH 部分的内容 （如忘添加，添加重新编译后，需要删除SDK下的 FSBL，并重新再创建一遍FSBL）
- 检查 DDR的型号和DDR的位宽是否正确，不正确的DDR设置也同样会导致固化阶段卡住
- 正常SDK 或者VITIS 固化FLASH固件之后，如果此时VIVADO中仍然是连接主板的状态，这时候按POR重启板子，板子上的新固件启动过程会被vivado 打断（这种情况FLASH固化其实已经成功了，退出vivado的连接状态即可）
问题四、已连接下载器和主板，但是在Vivado 下不能发现主板
这个可能的情况有很多种，我们一一排查
A) 先确认是下载器端出现问题了，还是和主板通讯端出现问题了,
按下Open Target 之后，看右边是否出现我们的下载器：如果出现证明下载器被Vivado 正确识别，否则下载器驱动可能出问题
- 如果出现下载器型号：证明下载器被Vivado 正确识别 (这种情况请排查 主板和下载器之间的连接线，尤其是下载器的VREF 需要和主板的JTAG口电源连接，GND也必须共地，一共6根线(VCC GND TMS TDI TDO TCK)，如果接线正常，请尝试重新启动电脑，以及重新插拔JTAG下载器)
- 如果没有如下图这样出现下载器型号请继续检查步骤B
B) 检查下载器是否是Xilinx 专用下载器，是否支持ZYNQ芯片的调试（看下载器封面，或者询问下载器卖家，如果带BLAST字样，那一定是Altera 下载器，就不能适用了， 另外店铺的XILINX下载器使用国产芯片来制作，可能并不兼容ZYNQ系列）
- 是Xilinx 专用下载器：请检查步骤C
- 不是XILINX专用下载器，或者不兼容 ZYNQ芯片调试 : 更换下载器。
C）如果下载器是Xilinx 专用下载器，请检查电脑的设备管理器在插入或者拔出JTAG 下载器时是否会有变化（声音的变化类似插拔U盘时PC发出的声音，或者设备管理器里内容的变化 ）
- 如果没有任何声音或者内容的变化：请检查和电脑通讯的TYPE C线是否是数据线（部分手机的充电线内部只有两根电源线，不能进行通讯）（这种情况经常会遇到）一般更换TYPE C数据线即可。
- 如果有声音的变化，但是VIVADO 仍然没有显示下载器，请检查步骤D
D) 一般到这一步基本上都是XILINX 下载驱动问题了（安装vivado时未勾选安装下载器驱动， 或者驱动被错认成其他EDA的下载器了（下载器芯片方案相同），如：类似下图这种被认成libusb的设备了）
解决方法：这种情况只需要重新安装我们的xilinx 下载器驱动即可， 下载器驱动在vivado 的 安装路径下，下面以Vivado 2018.3 路径为例
\Xilinx\SDK\2018.3\data\xicom\cable_drivers\nt64\digilent
问题五：通过 USB 供电时，主板工作不稳定 (排除软件问题的情况)
- 问题描述：
- 部分用户反馈，在使用 USB 给主板供电时，系统运行过程中会报错，或者系统启动过程中出现卡顿、卡死等异常现象。
- 可能原因：USB 供电电压或电流不稳定，常见于以下情况：
- 板的 USB 接口通过 USB HUB 分线器连接，且 HUB 未独立供电。
- 使用的 USB 线材质量较差（如线太长、导线过细等）。
- 使用的是台式机前面板的 USB 接口，该接口通过内部引线连接至主板，部分组装机的引线质量差，导致供电不稳。
- 解决建议：
- 更换质量更好的 USB 线材，避免使用过长或线径过细的线。
- 将主板直接连接至电脑的 USB 接口，避免使用未供电的 HUB 分线器。若必须使用 HUB，建议选择带独立电源的型号。
- 如果使用台式机，建议将主板连接至机箱背部的 USB 接口，而非前面板。
- 也可使用排针接口（VCC 和 GND）为主板单独供电 5V。由于主板的 USB 电源输入处已设计有防倒流二极管，因此通过排针供电不会引起与 USB 电源之间的冲突或倒灌问题。
问题六：ZYNQ在运行较新版本的Petalinux 时，系统会停留在Uboot，需手动输入run mmc_boot后才能正常启动
- 问题描述：
- Smart ZYNQ 系列主板在运行较新版本的Petalinux 版本时，系统会停留在Uboot，需手动输入run mmc_boot后才能启动 （早些版本如本站例程中介绍的petalinux 2018.3版本不存在这个问题）
- 问题分析：
- 经过对比发现当主板的uart是采用emio uart的时候uboot会被uart rx意外打断，而主板的uart是采用mio uart的时候就不会存在这个问题。并且通过por或者reboot软件复位重启问题仍然会复现。
- 尝试过在硬件uart rx引脚外部加上拉电阻过并没有解决问题，所以这个问题和硬件无关。
- 经过分析猜测有两种可能的原因会引起这个问题的发生:
- 可能1:有可能是新版本的uboot读uart过早引起的问题（uboot在配置fpga的过程中rx信号会跳变，如果此时uboot直接读uart 了，就会错误的认为接收到数据了），而老版本的petalinux 不存在这个问题，很可能是因为uboot是在fpga配置稳定后才读取的uart。
- 可能2：除了第一种情形外，也可能是因为新版本的uboot在启动阶段读串口前没有对串口缓存进行清除引起的，系统在f’sbl阶段对uart等资源进行配置，随后再加载bit对fpga进行配置，配置的过程中fpga的信号会跳变，uart会误以为接收到数据并存储在串口寄存器或缓存队列中，如果uboot在启动阶段读取串口前没有先清缓存队列（或寄存器），那就会读到错误的数据，打断uboot的自启动。（至于2018.3很有可能这块做了清除操作，所以autoboot不会被打断）
- 两种情况都只是猜想，实际也可以通过修改uboot或者fsbl源码来验证，这里就不作展开了。
- 解决思路：
- uboot 默认 uart 接收到任意内容都会打断系统的 autoboot，我们只需要在uboot编译的配置页对autoboot打断条件进行修改即可（原先是任意键就中断，现可以改成特定字符组合进行中断），修改方法如下：（以2022.1版为例）
1 输入petalinux-config -c u-boot 进入uboot配置页， 选择Autoboot options
2 选择 boot options
3 在Stop autobooting via specific input key /string 按下键盘下的Y 选中
4 新增的界面里， 在stop autobooting via specific input key /string 里输入你要中断的字符串信息，这里以‘abc’为例（备注，选的字符串不要太长尽量短，所选择的字符串在键盘上的距离不要太远，可以类似‘qwe’这种组合）。 这里最好也对delay in seconds before automatically booting 等待时间的值进行修改，默认是2，修改以实际键盘上能输入完整的字符串信息为准。
之后可以在Auto boot stop prompt 里输入提示词，如press ‘abc’ to stop （这个仅作提示用）
之后保存修改 ，按原先流程编译系统即可。
之后系统重启 ，系统会出现我们的提示语句，此时依次按下键盘上的abc三个键可以打断自动启动，并进入uboot。 如果不要进入uboot，就正常等待几秒钟即可。
