NIOS II CPU复位异常的原因及解决方案

近期在用nios ii做项目时，发现一个奇怪的现象，在NIOS II EDS软件中编写好的代码，烧写到芯片中，第一次能够正常运行，但是当我按下板卡上的复位键之后，系统却卡死了，再也运行不起来，除非重新下载程序。 在使用NIOS II嵌入式处理器进行项目开发时，可能会遇到一种特定的复位异常问题，即程序在首次加载后可以正常运行，但一旦通过板卡上的复位按钮进行复位，系统就会陷入死锁状态，无法再次启动，除非重新下载程序。这种问题通常涉及到处理器的复位机制、配置存储器(EPCS)以及Bootloader的位置设置。 我们需要理解NIOS II处理器的工作流程。在系统启动时，CPU会从预设的复位向量地址开始执行代码，这通常是配置存储器或系统内存(SDRAM)中的Bootloader。在Qsys系统配置中，复位向量的设置至关重要，因为它决定了CPU在复位后执行的第一个指令位置。 在本文中，开发者最初将复位向量设置在EPCS配置存储器上，这意味着在系统启动时，CPU会尝试从EPCS读取Bootloader。然而，如果EPCS中没有固化配置文件和代码，复位操作会导致CPU找不到正确的启动代码，从而导致系统无法正常启动。为了解决这个问题，开发者将复位向量改为指向SDRAM，这样CPU将在复位后从SDRAM中读取Bootloader。 尽管改变了复位向量，但问题依然存在。原因可能在于BSP(Bare Board Package)设置中的`allow_code_at_reset`和`enable_alt_load`选项。这两个选项与Bootloader的加载方式有关。`allow_code_at_reset`允许CPU在复位时从内存中执行代码，而`enable_alt_load`则是启用备用加载机制，通常用于在EPCS配置过程中加载程序。在不包含EPCS控制器的系统中，这两个选项默认可能是选中的，但在包含EPCS的系统中，它们可能未被选中。 根据找到的解决方案，取消这两个选项的勾选使得CPU在复位时不会尝试从内存中加载代码，而是等待配置完成后再执行。这是因为当复位向量指向SDRAM时，CPU需要在EPCS完成配置后再从SDRAM启动，而不是立即尝试执行其中的代码。这与不带EPCS的系统行为一致，避免了复位后的混乱。 在遵循这一解决方案后，重新生成BSP，并对系统进行编译和下载，处理器就能够正确地处理复位操作，系统在复位后能正常运行，不再出现卡死现象。 NIOS II CPU复位异常主要是由于复位向量设置不当和BSP配置不匹配造成的。正确配置复位向量和调整Bootloader加载选项是解决问题的关键。在进行FPGA开发时，深入理解硬件配置、系统启动流程以及处理器的复位机制对于排除此类故障至关重要。同时，保持良好的文档记录和及时学习社区资源也是解决技术问题的有效途径。