通过MCU实现Altera FPGA在线升级一．问题背景 在实际工程应用中，我们时常会遇到为解决某个老产品的BUG，需要在工程现场更新设备的FPGA代码，或者参加电信测试时需要现场升级设备FPGA程序以便于调试。公司现阶段所用的Altera FPGA程序代码一般存放于芯片配套的FLASH存储器中，而常见的对印制板上FLASH编程有几种方法，原始的方法是使用编程器，这种方法需要要将芯片取下，十分不便，或者通过JTAG接口连接到PC机上，但需要专用下载软件（一般由芯片生产厂商提供）。在测试现场或调测机房现场，要找到FPGA的专用下载线是比较困难的，且Altera FPGA的专用下载软件并不是每个PC设备上都有的。有时仅为了更新一个FPGA的程序就需要研发或客服人员亲自到现场去烧写程序，这既不便捷，也使得设备维护成本大大增加。

经过可行性与成本的考虑，我们找到一种既方便实用又低成本的方法来实现FPGA程序的在线现升级。即在MCU中（单片机或ARM均可）用软件来模拟XModem协议，将程序文件传输到FPGA的FLASH中。这种方法使用WINDOWS自带的超级终端软件来传送文件，无需安装专用软件，硬件支持仅需要一根通用串口线，只要在目标板MCU上增加一段实现XModem协议传输的代码，就可以方便的实现FPGA程序下载了。这种特点不仅方便了客服人员，也给研发和生产人员在现场调试和软件升级、修改中带来极大方便。

二．XModem协议简介 XModem协议是一种在串口通信中广泛用到的异步文件传输协议。协议以128字节块的形式传输数据，每个块都使用一个校验过程来进行错误检测。标准XModem协议帧格式如图1 所示：
________________________________________________________________ | | | | | | | SOH | 信息包序号 |   信息包序号的补码 | 数据区段 |   校验 | |_______ |___________ |___________________ |___________ |___________ | 图1 标准XModem协议帧格式 XModem协议传输逻辑：
对于标准XModem协议来说，如果传送的文件不是128的整数倍，那么最后一个数据包的有效内容肯定小于帧长，不足的部分需要用CTRL-Z来填充。

传输由接收方启动，方法是向发送方发送“C“或者NAK（注：这里提到的NAK是用来启动传输的）。XModem协议支持2种校验，接收方发送NAK信号表示接收方打算用累加和校验，发送字符“C“则表示接收方想打算使用CRC校验。当接收方发送的第一个“C“或者NAK到达发送方，发送方认为可以发送第一个数据包，传输已经启动。发送方接着应该将数据以每次128字节的数据加上包头，包序号，包序号补码，末尾加上校验和，打包成帧格式传送。

发送方发了第一包后就等待接收方的确认字节ACK，收到接收方传来的ACK确认，就认为数据包被接收方正确接收，并且接收方要求发送方继续发送下一个包。接收方首先确认数据包序号的完整性，通过对数据包序号取补，然后和数据包序号的补码异或，结果为0表示正确，结果不为0则发送NAK请求重传（注：这里NAK用来告诉发送方重传，而不是用来启动传输）。接收方确认数据包序号正确后，然后检查是否期望的序号。如果不是期望得到的数据包序号，说明发生严重错误，则发送一个CAN来无条件中止传输。如果接收到的数据包的包序号和前一包相同，那么接收方会忽略这个重复包，向发送方发出ACK，准备接收下一个包。接收方确认了信息包序号的完整性和是正确期望的后，只对128字节的数据区段进行算术和校验，结果与帧中最后一个字节比较，相同发送ACK，不同发送 NAK。

如果发送方正常传输完全部数据，需要结束传输，正常结束需要发送方发送EOT字节通知接收方，接收方回以ACK进行确认。虽然数据包是以SOH来标志一个信息包的起始的，但在SOH位置上如果出现EOT则表示数据传输结束，再也没有数据传过来。当然接收方也可强制停止传输，当接收方发送CAN字节给发送方，表示接收方想无条件停止传输，发送方收到CAN后，不需要再发送EOT确认。XModem协议相关控制字符含义详见附录1。

三．Altera FPGA在线升级的硬件实现 Altera FPGA用JTAG在AS模式下的程序烧写，是先将程序文件*.pof下载到芯片的FLASH中存储起来，每次重新上电后，程序文件会重新由FLASH载入到FPGA芯片中。Altera FPGA常用FLASH芯片为EPCS1和EPCS4，这两个FLASH芯片除了容量不一样，其他方面几乎完全相同，在引脚上也完全兼容。

图2 FPGA AS模式烧写硬件连接图 图2所示为FPGA用JTAG在AS模式下烧写程序文件的硬件连接图。我们需要用MCU模拟AS模式的硬件操作方式，通过XModem协议，将FPGA代码文件传输到FLASH中。AS模式烧写FPGA时，与7个信号相关，其中DATA、DCLK、nCS、ASDI是FLASH的四个SPI信号，分别代表FLASH的数据输出、读写时钟、片选、数据输入。MCU也需要通过这四个引脚，将数据传输到FLASH中去。另外三个信号CONF_DONE、nCONFIG、nCE分别是烧写FLASH时，需对FPGA进行控制的三个信号。

nCE为FPGA的芯片使能信号，nCONFIG为低电平时复位FPGA的信号，CONF_DONE为FLASH载入到FPGA完成信号。在AS烧写模式，nCONFIG=0， FPGA复位，nCE=1，使FPGA芯片不被选中，CONF_DONE=0，下载开始；
下载结束时，nCONFIG=1，nCE=0，进入代码由FLASH到FPGA的载入过程，当载入完毕后，CONF_DONE=1。

在对FLASH读写时，需要注意的是，EPCS1/EPCS4区别于一般的FLASH，有其自身对应的操作码，不同的操作码代表对FLASH进行不同的操作。如表1所示，有写使能、写禁止、读芯片状态、读字节、读芯片ID、写芯片状态、写字节、擦除整片、擦除片区这几个操作码。对EPCS1/EPCS4进行任何操作，都需在片选变低后，首先写入对应的操作码，然后是地址和数据。此外，在写字节、写状态、片区擦除、整片擦除之前必须要先进行写使能操作。上电、写字节、写状态、片区擦除、整片擦除完成后需要进行写禁止操作。

表1 EPCS1/EPCS4操作码 四．MCU中的软件实现 1. 软件流程 在MCU软件实现FPGA在线升级的过程中，除了对FLASH的读写，最主要的部分是通过模拟XModem协议，将文件传输到FLASH中。整个传输过程需同时遵循XModem传输逻辑以及EPCS1/EPCS4的读写规则。软件流程如图3所示：
图3 MCU模拟XModem协议流程图 2. *.pof到*.bin文件的转换 FPGA通过编译软件QuartusⅡ生成的烧写文件为*.pof文件，由于这个文件的末尾有大量的全“FF”，并无实际的代码含义，且*.pof文件没有*.bin文件兼容的烧写工具多。为了节约文件传输时间，我们将*.pof文件中无用代码去掉，并保存为*.bin文件。具体方法如下：（1）将*.pof文件用UltraEdit编译软件打开，如图4所示，在QuartusⅡ生成的*.pof烧写文件中，最前面一段是Quartus的版本等与代码无关的信息，可将图4中红色方框部分删除，直到第一行全‘FF’开始之前，将第一行全‘FF’为代码的起始行。

图4 *.pof烧写文件起始 （2）如图5所示，*.pof文件中，可用代码结束后，是大片的全‘FF’无用代码。可将这些全‘FF’保留15~20行，以保证XModem传输128字节的完整性，将其余多余的全‘FF’全部删除。

图5 *.pof烧写文件结束 （3）将无效代码删除后，可将新文件按自定义命名，‘另存为’后缀*.bin的文件即可。

3. 反相传输 我们通常的读写习惯或SPI的读写大多是由字节的MSB开始，LSB结束。按照此种方式对Altera FPGA的FLASH进行XModem传输，传输成功后，FPGA确并没有启动。通过将用JTAG烧写到FLASH的代码用编程器读出，我们发现了问题所在。

图6、图7所示为同一序列段代码的截取，图6为QuartusⅡ生成的*.pof烧写文件的代码，图7为通过烧片器从FLASH中读出的代码。通过观察，我们不难发现，这两段代码中的每一个字节均是互为反向的，即MSB与LSB的位置是相反的。

图6 QuartusⅡ生成的*.pof烧写文件 图7 通过烧片器从FLASH中读出的代码 在将FLASH进行XModem的传输中改为由LSB开始传输，传输完成后，FPGA运行正常。因此，我们需要注意，在对EPCS1/EPCS4进行XModem传输时，应先从LSB开始，MSB结束。

4. 在线升级示例 下面列举一个在线升级的操作示例，供大家参考。示例中XModem传输采用的是CRC校验方式。

l XModem协议传输预备阶段：打开超级终端，选好串口和波特率设置，先擦除FLASH，然后发送‘C’校验码启动传输。

l 启动传输后，选择发送文件。

l 在‘浏览’中选择所要传输的文件路径，在‘协议’中选择XModem。

l 开始传输。

l 传输结束后提示 小结：作为Altera FPGA的配套FLASH芯片，其烧写有一定的特殊性。本文描述了用MCU实现XModem协议升级FPGA程序的方法。这种方法不仅使FPGA芯片的程序升级变得非常简便，也给客服、研发和生产人员在现场调试和软件升级、修改中带来极大方便。

五、附录 标准XModem协议控制字符符合 ASIC II 标准定义，长度均为1字节，具体含义如下：
字符 对应十六进制数 含义 ACK 0x06 认可响应 C 0x43 CRC校验 CAN 0x18 撤销传送 CTRLZ 0x1A 填充 EOT 0x04 发送结束 NAK 0x15 不认可响应/启动传输时为累加和校验 SOH 0x01 数据块开始