从开始接触Altera（现在应该叫intel PSG了）的NIOS II处理器，到现在，已经有6个年头了。从开始的C语言都不懂，到现在能使用NIOS II开发一些实用的东西，中间的过程也是非常的曲折。最开始的时候，完全是炼狱一般，走一步，十个坑，没人指导，填几天，再走一步，再填一个坑。到了后来对这个东西开始心生敬畏，敬畏不是因为它有多么多么强大，而是在学习和使用它的过程中，让我对CPU架构，单片机系统实现思路和编程方法有了较为底层的认识，也算是一个升华吧，虽然在这个过程中还是常常掉入坑里好久才能爬出来。到了现在，能够指导大家学习和使用NIOS II处理器结合FPGA RTL逻辑实现一些功能，自己也能做一些不大的小东西。这6年，感觉就像是按照指数函数的曲线进步的，最开始很慢，后面越来越快。想想自己能坚持到现在，可真不容易（/偷笑）。

深知大家在自学这门技术的开始半年时间内有多么痛苦。我一早就想出一点NIOS II方面开发的实用性书籍文档，可一直一个人打理着各种事情，实在没有精力。我也深知当下讲解和使用NIOS II的开发已经有些不那么前沿了，毕竟现在嵌入硬核的FPGA应用已经较为成熟了，NIOS II这个处理器处于中间这样一个尴尬的位置，实用性和性价比值得思量。但是，毕竟NIOS II和Xilinx的MicroBlaze处理器设计和开发思路异曲同工，MicroBlaze和Xilinx当前非常受欢迎的Zynq硬核FPGA开发思路和过程很像，NIOS II和Intel（Altera）的SOC FPGA开发过程和思路很像，因此，学习NIOS II处理器，是一条经济轻巧的道路。真正掌握了NIOS II处理器的应用和开发，迁移到Intel SOC FPGA上，也就需要3~5周的时间，换到Xilinx的MicroBlaze或者Zynq平台上也只需要5~8周。所以，这个事情值得一做，毕竟，咱国家每年还有那么多高校学子需要一个合适的切入点来进入SOPC/SOC开发的大门。

当下定决心做这件事的时候，我却犯了难。到底，我该以一种怎样的方式来开启我的系列文档呢？是从CPU架构、指令集开讲，还是直接从LED点灯写起呢？每天在技术交流群里，看到大家学习时候遇到各种问题并却不知道如何解决时，我突然觉得，其实，大家暂时不缺入门的教程，缺的，是继续学习下去的信心。那么信心从何而来？就从解决NIOS II开发中常见的各种问题着手开始吧。如果大家首先就有一份“捉虫子”手册放在旁边，遇到各种问题马上能从手册中找到解决方法或解决思路，那么大家的学习信心必然会与日俱增。所以，我选择我的这一份文档，从教大家捉虫子开始。

唠叨了这么多，下面开始切入正题。

大家在进行NIOS II系统开发时，往往有很多的疑问，第一个疑问就是大家经常提到的，NIOS II CPU运行不稳定，NIOS II 开发bug太多。由于FPGA本身相对于单片机、ARM处理器来说，应用市场要小的多。加上NIOS II仅仅是FPGA应用和开发的一个小的分支，用的就更加的少了。所以，关于NIOS II 非常系统且科学的教程教材也是非常的少，导致大部分人在进行NIOS II的学习和开发的时候，都会遇到各种各样的问题，如elf文件下载失败，CPU运行不起来，程序运行不正确，CPU运行一段时间后停止，调试正常但是烧写到EPCS后无法运行等。那么今天，我就在这里将NIOS II CPU的各种问题做一个总结分析，希望大家通过本总结分析，以后在开发NIOS II相关应用时候，能够手到擒来。

1、elf文件下载失败

当大家将FPGA的编程文件SOF文件下载到FPGA芯片中后，就可以下载nios ii eds中编译好的软件固件，该固件的尾缀为.elf。那么大家在下载的时候，会经常遇到下述问题：

Launching New_configuration has encountered a problem. Downloading ELF Process failed。

个人目前总结的，出现该问题的原因主要有以下几点，

1)目标板/开发板上的NIOS II CPU系统未能正常工作，例如，未下载对应的SOF文件到FPGA中，或者时钟、复位、存储器（SRAM、SDRAM、DDR2）引脚分配有误，当使用SDRAM存储器作为NIOS II CPU的内存时，还有可能是SDRAM的控制器时钟和接口时钟之间的相位差不合适。

解决方法：重新下载sof；检查核对引脚分配；查看SDRAM参数配置和时钟配置。

2)创建NIOS II软件工程时候，选择的sopcinfo文件与对应的FPGA工程不一致。这一点我在每次公开课的时候都会强调， NIOS II 软件开发需要两个工程，一个板级支持包（bsp）和一个应用工程。每次创建NIOS II BSP工程的时候都需要选择一个sopcinfo文件，该文件就是实际我们在Qsys中搭建的希望使用的NIOS II系统的描述文件。NIOS II软件开发环境根据该信息文件创建对应的硬件信息头文件“system.h”，但是，NIOS II开发软件有一个比较不好的地方就是每次选择sopcinfo文件的时候，都会记录上一次选择sopcinfo文件的路径并直接自动定位到该路径，所以大家如果一旦粗心，一点击浏览文件，发现一个sopcinfo文件就直接选择的话，往往就会选择到上一次的工程的文件，而不是本次新的工程的文件。这样我们创建软件工程时使用的sopcinfo文件就还是上一个工程的，而我们下载sof时又是下载的新的工程的，所以就出现了下载的sof文件与elf文件不是基于同一个工程的问题，导致无法下载成功。因此为了避免出现这个问题，新建工程时请时刻记住选择正确的sopcinfo文件。该问题一个更加奇妙的现象就是当前一个工程和这次的新工程两者之间差别不大的时候，elf甚至可以正确下载，NIOS II也能运行起来，但是就是现象与预期不一致，这一点可能往往也是让很多人误以为NIOS II不稳定的原因之一。如果你想知道你当前的工程的bsp文件是否正确，非常简单，打开bsp工程下的settings.bsp文件，查看第9行就可以啦。

解决方法：新建工程选择sopcinfo文件时务必选择正确的sopcinfo文件。

3)1)NIOS II的启动地址错误。

NIOS II 是一个CPU，其运行过程是受程序指令控制的，而程序有不同的存放位置。例如，程序可以直接存放在RAM中，然后CPU复位后直接从硬件定义的RAM中程序存放的初始位置开始执行。该种方式常见于我们在进行软件编写调试的过程中，这个过程，我们可能需要经常进行程序的调试，所以直接使用仿真器（USB Blaster）在线将程序下载到CPU的RAM中运行或者debug。另一种情况就是项目发布的时候，我们做一个项目或产品，当产品功能都调试通过之后，需要将程序烧写在板卡上，这样板卡在上电之后，不需要PC端下载程序，就可以自动从非易失性存储器（FLASH、EEPROM）中加载程序并运行。此时我们需要CPU设置从非易失性存储器中开始启动。那么如果我们设置了NIOS II的启动地址为FLASH（EPCS），而我们又下载了定义从RAM中启动的程序，那么程序会被下载到RAM中，CPU启动时候会去FLASH中读取程序，由于我们的程序并没有下载到FLASH中去，因此CPU无法读取到正确的程序，就会无法正常运行，然后报此错误。同理，如果我们设置CPU从RAM中启动，而我们又将程序烧写在了FLASH中，那么CPU上电运行后，由于RAM中没有下载正确的程序，因此也无法运行。这一点实际上是我们上面提到的另一个现象，即调试正常但是烧写到EPCS后无法运行。

好了，饶了这么多口舌，该说大家最关心的问题了，怎么设置CPU的复位地址呢？其实有两个地方需要设置，而90%以上的人只知道一个地方，那就是QSYS中选择CPU的复位地址。当我们的系统中FLASH使用EPCS芯片剩余容量，那么如果我们要定义CPU硬件上从FLASH中启动，就需要定义CPU 的Reset Vector为EPCS，如果我们要定义CPU硬件上从RAM（onchip_ram/SDRAM/DDR2）中启动，那么就选择Reset Vector为ram。当然，这没什么问题，但是我们任然可以在一开始就定义CPU 的Reset Vector为EPCS，然后在调试的时候，却从RAM中运行。为什么可以呢，这就是我说的90%人不知道的第二个地方，该设置在NIOS II 软件开发环境中。

我们选择一个bsp工程，打开bsp editor页面，在第一个选项卡main中，找到下面的Advanced选项，然后右侧相关内容中有个hal.linker选项，在该选项中有5个可选项，其中第一个叫做allow_code_at_reset。这个选项是什么意思呢，就是允许代码存放在复位向量处，好了我们回头来想一下，上面我们说过，我们可以选择CPU的Reset Vector为EPCS，而这里又使能了allow_code_at_reset选项，所以程序编译的时候就会将启动程序部分编译在EPCS所在的地址段。这就是真真切切的将复位地址设置在了EPCS中。此种模式下我们无法在线调试的，如果强行调试一定会出现上述报错。若有人反驳说他的工程此种情况下也能下载成功，那一定是因为你之前已经将EPCS中烧写过一次本程序了，所以你的CPU能够启动，是因为设定的启动地址EPCS中有能够支持CPU启动的程序，但能启动不代表其他功能也能正常运行哦。一旦选择该选项，下面的enable_alt_load也要一并选上，选上之后CPU就能够正常从EPCS中加载了。部分用户在烧写SOF和ELF到EPCS中进行固化时不成功，原因也与没有勾选这两个选项有关。

那么如果我们希望先在RAM中调试怎么办呢，想必大家已经想到了，不使能allow_code_at_reset和enable_alt_load就可以了。对的，当我们希望在RAM中调试的时候，将这两个勾选项取消，那么程序编译就会默认将启动代码编译到RAM中，然后就可以从RAM中启动并调试啦。

解决方法：调试时不勾选allow_code_at_reset和enable_alt_load。烧写时务必勾选这两个选项。