1. 项目背景为什么6678需要SPI NOR Flash烧写攻略1.1 这个项目到底在解决什么问题先交代一下背景。TMS320C6678是TI的8核C66x DSP主频轻轻松松上1GHz用在通信、雷达、图像处理这类场合很常见。这种级别的板子启动方式却经常让人头疼。它不像单片机那样一个U盘就能下载程序也不像Linux板卡那样有个SD卡引导就完了。6678支持多种Boot模式包括EMIF16、SPI、SRIO、PCIe等而最常见、成本最低、最省事的量产方案就是SPI NOR Flash启动。这里说的“SPI NOR Flash烧写”就是把编译出来的DSP程序固化到一片SPI接口的NOR Flash芯片里让6678上电后通过ROM里的Bootloader把程序读出来并加载运行。整个过程说起来一句话做起来却要踩不少坑尤其是从.out到.bin的转换环节很多人第一步就被卡住了。1.2 为什么选SPI NOR Flash而不是并口Flash很多人第一次接触6678时会问为什么不用并口NOR或NAND原因很实际。并口NOR Flash的引脚多、封装大、布线麻烦在这类高速DSP板卡上EMIF16接口还要留给FPGA或者CPLD去用。NAND Flash虽然有容量优势但操作复杂、有坏块管理、启动协议也复杂不适合做轻量的启动介质。SPI NOR Flash的优势就在于引脚少、协议简单、启动稳定。一片8MB的SPI NOR比如常见的S25FL256S或W25Q128就能装下几个完整的应用程序。加上6678的SPI接口本身支持主模式和从模式配合ROM Bootloader上电就能自动加载量产时也方便焊一片Flash就完事不需要仿真器挨个写。1.3 整个烧写链路到底长什么样把这条路完整走通需要经历这几个环节编写应用代码、编译链接生成.out、把.out转换成适合SPI引导的.bin、把.bin写入NOR Flash、设置启动模式、上电验证。任何一个环节出问题现象都可能是“板子没反应”“程序跑飞”甚至“DSP内部扫描不到”。我见过很多新手程序在CCS里用仿真器跑得好好的一脱离仿真器就废。问题往往不是代码本身而是.out到.bin这一步没做对。因为CCS直接加载.out时仿真器会按段的信息把程序放到DDR或MSMC里这些操作都是仿真器自动完成的。而SPI启动时不再有仿真器帮忙全靠一颗小小的Flash芯片把程序喂给DSP喂错了地方、喂错了格式那自然跑不起来。2. 从.out到.bin的转换原理这一步为什么绕不过去2.1 .out文件里到底装了什么东西想要把转换做对先得知道.out文件里有什么。用CCS编译出来的.out文件常见的是COFF格式或者ELF格式。不管哪种格式它都不是纯粹的、可搬进Flash的机器码镜像。一个.out文件内部包含了文件头、段表、符号表、字符串表以及各个代码段的加载地址和运行地址。比如.text段是程序代码、.const段是常量数据、.cinit段是C语言全局变量初始化表。每个段都有自己的长度和存放地址。仿真器加载.out时会阅读这些段表信息然后把每个段的数据搬运到DSP内存里指定的位置再设置PC指针程序才能跑起来。问题在于Flash里的数据必须按照地址连续存放不能有一个段表、符号表夹在中间。DSP上电后是拿着ROM Bootloader去Flash里按固定地址读数据的它不知道你每段放在哪个地址只能按固定的格式去解析。所以必须把.out里那些可加载的段提取出来按目标地址排列好填平中间的空洞生成一份纯二进制数据这就是.bin的由来。2.2 hex6x转换工具是干什么的hex6x是TI Code Generation Tools里自带的转换工具专门负责把.out转换成各种烧写格式。对于C6000系列的DSP这个工具在CCS安装目录下就能找到比如C:\ti\ccsv8\tools\compiler\ti-cgt-c6000_8.3.x\bin\hex6x.exe它的工作方式比较特别不是在命令行后面直接跟一堆参数而是读取一个.cmd脚本文件。这个.cmd不是链接脚本而是转换配置脚本这一点特别容易混淆。我见过不少人在这一步卡了很久把链接脚本的内容套到hex6x上结果各种报错。2.3 hex6x命令行参数逐个拆解一个典型的hex6x转换脚本大概长这样app.out --image --zero --memwidth 8 --boot --bootorg 0x0C000000 --bootsection .boot_load 0x0C000000 --spi --outfile app.bin逐个解释一下作用。--image是让工具生成一个连续的镜像文件把所有加载段按地址顺序排列成一个整体。如果你不加这个参数输出的可能是分散的多个文件或者多段记录不适合直接烧入Flash。--zero是要求把段与段之间的空洞用0填充。比如.text在0x00800000.const在0x00810000中间空了一段地址如果不填0生成的bin文件就会有跳跃会导致Flash地址和内存地址对不上。--memwidth 8是内存宽度SPI NOR Flash是按字节寻址的所以这里设为8位。如果你的板子用的是16位数据宽度这里就要改成16。--boot表示生成带引导信息的Boot Table。这里要特别注意SPI启动模式下ROM Bootloader读到的不是纯粹的代码流而是一张张“表”每张表里记录了代码段的目标地址、数据长度、数据内容Bootloader按表逐段加载。--bootorg是Boot Table在内存中的存放地址这里写0x0C000000对应6678的MSMC起始地址。具体值要根据你的RBL版本和内存规划来定很多参考设计都是用0x0C000000。--bootsection .boot_load 0x0C000000是把生成的Boot Table放到一个独立的段里并指定这个段的加载地址。--spi表示Boot Table的格式按照SPI引导的要求来生成这个参数决定了表头的组织方式别漏了。--outfile app.bin是输出文件名。这么一组合工具就会读入app.out解析里面的段信息生成一个带Boot Table头的.bin文件这个文件就是可以直接往NOR Flash里写的东西。3. 完整转换实操以CCS环境为例从编译到生成bin3.1 准备工作和环境检查动手之前先把环境理清楚。你需要一个能正常编译工程的CCS版本不太重要5.5、6.2、8.3都行关键是找到对应版本的hex6x工具。还有一个已经编译通过的6678工程生成app.out。确认hex6x工具的路径可以在CCS安装目录下搜索hex6x.exe。路径通常是C:\ti\ccsv8\tools\compiler\ti-cgt-c6000_8.3.x\bin\建议把hex6x.exe所在目录加入系统PATH环境变量反正WIN10系统操作起来很简单加入之后就能在任意路径下直接调用命令。这一步能省不少事别懒得做。3.2 新建hex转换脚本并核对路径在工程目录下新建一个文本文件命名为app_hex.cmd内容就按前面那一段写。注意第一行是输入文件名app.out你要确认app.out确实存在于当前目录而且路径没有中文。工具对中文路径的支持一言难尽建议整个工程都放在纯英文路径下。另外输出文件名app.bin会被生成在命令行当前工作目录下。用命令行工具操作时先用cd命令切到工程目录再执行转换这样最不容易出错。3.3 执行转换并检查输出文件打开命令行窗口进入工程目录执行hex6x app_hex.cmd如果命令执行完没有任何提示一般来说就是成功了。此时目录下会多出一个app.bin文件。用dir命令看一下文件大小正常的话应该和你的代码量差不多几百KB到几MB之间。如果出现错误最常见的有几种一是找不到app.out检查路径和文件名二是outfile无法创建检查当前目录是否可写三是报地址重叠或段类型不支持这种一般是脚本参数写错了。生成bin之后不要急着往Flash里写先做一次内容检查。推荐用hexdump或者免费的HxD工具打开bin文件看前几个字节。如果是C6000系列的标准Boot Table开头应该是IBTL四个字母十六进制形式是49 42 54 4C看到这个标志说明转换基本成功了。如果没有IBTL大概率是脚本参数不对检查是否漏了--spi参数或者--boot参数。3.4 一个可复用的批量转换脚本实际项目里可能要反复生成bin每次敲命令太烦。我习惯写一个批处理脚本放在工程目录里内容大概是echo off set CGTC:\ti\ccsv8\tools\compiler\ti-cgt-c6000_8.3.x\bin %CGT%\hex6x.exe app_hex.cmd if exist app.bin ( echo 转换成功生成 app.bin ) else ( echo 转换失败请检查脚本 )以后每次编译完双击这个bat文件bin就自动生成了。省心也不容易漏参数。4. 烧写NOR Flash的现场流程从仿真器到脱离仿真器4.1 烧写方案怎么选拿到的bin文件要写进Flash方案不止一种。最通用也是最稳妥的是用仿真器加CCS来烧因为6678的JTAG接口几乎是每块板子的标配而且仿真器还能帮你初始化时钟、DDR等外设。如果你板子上有串口或者网口也可以把烧写程序固化到RAM里用上位机把bin文件通过串口或网口传下来再调用Flash驱动写入。这个方案适合产线批量烧写但对于第一次调通的工程师我建议还是先用仿真器把整条链路跑通了再说。4.2 用CCS直接把bin写进Flash的操作步骤以常见的XDS200仿真器为例流程如下。先在CCS里创建一个Target Configuration仿真器型号选XDS200连接6678确保能连上核心并加载GEL文件。GEL文件里通常有DDR初始化、PLL初始化等函数跑一下初始化让DSP处于可执行代码的状态。接下来有两种做法。一种是用CCS里的Memory窗口直接写但对Flash而言不太适用因为你没法直接往NOR Flash的地址写数据必须先擦除再写还要等状态寄存器。所以更常见的做法是加载一个专用Flash烧写程序这个程序运行在DSP上由它操作SPI控制器和GPIO去擦写外部的NOR Flash。我常用的做法是在CCS里加载烧写工具.out这个工具程序在RAM里运行会通过SPI接口读取NOR Flash的ID擦除指定扇区然后把bin文件写入。写入的数据源可以是CCS的PC端工具也可以是先加载到内存里的一块缓冲区。实际操作中很多开发板厂商会提供现成的烧写插件比如“SPI Flash Programmer”之类的菜单点一下选择bin文件工具自动完成擦除、写入、校验。如果你用的板子没有这类工具就老老实实写一个Flash驱动加载到DSP上代码不复杂无非是SPI初始化、Flash读ID、扇区擦除、页编程、状态检测这几个函数。4.3 校验和启动验证写入完成后一次性校验很重要。别偷懒直接从Flash里读回来和bin文件做比对。常规做法是把Flash读出的数据放回一块内存缓冲区然后和原bin文件做逐字节比较。如果校验通过就可以断开仿真器把板子的启动模式拨到SPI Boot复位看效果。检验标准很简单程序能跑现象正常比如串口打印输出、指示灯闪烁。要是板子没反应先别怀疑程序回到前面几步检查。5. 避坑指南SPI时序、片选和Flash操作常见问题5.1 SPI mode不对Flash读出来全是FF这是最高频的坑之一。SPI协议有四种模式由时钟极性CPOL和时钟相位CPHA组合决定见下表。SPI模式CPOLCPHA特点Mode 000空闲时钟低电平下降沿采样Mode 101空闲时钟低电平上升沿采样Mode 210空闲时钟高电平上升沿采样Mode 311空闲时钟高电平下降沿采样大多数SPI NOR Flash在数据手册里明确支持Mode 0和Mode 3。如果DSP的SPI模块配置的极性和相位跟Flash期望的不一致轻则数据错位重则读回来的全是0xFF看起来就像Flash没焊一样。排查方法很简单先读Flash的JEDEC ID命令是0x9F如果ID都读不对十有八九是SPI模式或者时钟问题。C6678的SPI配置时要特别留意时钟极性和相位寄存器的设置按参考设计通常用Mode 0。5.2 硬件片选和软件片选启动阶段没得选SPI通信要求主从之间通过片选信号建立连接片选拉低表示选中从设备。在普通调试程序里你完全可以用GPIO模拟片选想怎么拉就怎么拉灵活得很。但在6678的SPI启动阶段ROM Bootloader运行的时候它用的是硬件SPI接口片选信号必须连接到Flash的CS引脚上而且只能走硬件控制。我见过一个案例工程师为了省事在调试阶段用GPIO软控片选程序在仿真器下跑得挺好结果一脱离仿真器就起不来就是因为Boot ROM阶段软件片选逻辑根本没执行。所以硬件设计时CS引脚一定要连对软件上SPI用硬件片选模式别搞软件模拟。5.3 看待NOR Flash datasheet时最容易忽略的参数拿到一颗新的NOR Flash先别急着调SPI把数据手册这几个地方翻清楚页写大小一般256字节一页写入时要按页边界对齐跨页写要拆开否则会有意想不到的结果扇区擦除大小常见4KB、32KB、64KB擦除粒度直接影响你的烧写流程设计状态寄存器忙标志每次擦除和写入都要轮询状态寄存器的忙位别傻等固定延时地址字节数容量超过16MB的Flash要使用4字节地址模式而有些ROM Bootloader只支持3字节地址这种硬件组合就要换方案。另外还有个特别容易被忽视的点Flash的HOLD#引脚和W#引脚如果悬空读数据的时候会导致数据线被拉死或者误进入状态切换。正确的硬件设计是给这两个引脚加上拉电阻确保Flash始终处于可读写状态。如果板上没有上拉电阻而你又发现读数据偶尔出异常先查这两根脚。5.4 bin文件本身的问题地址、长度、端序排除了硬件和时序问题后剩下的大坑集中在bin文件本身。先说地址问题。Boot Table里的每个段都记录了目标地址如果链接脚本里段的地址和实际硬件连的存储器地址不一致程序加载后就会跑飞。比如你代码里.text段链接到0x0C000000但DSP启动时Bootloader把数据读回0x0C000000这没问题。但如果优化时改了内存映射没同步修改Bootloader的加载地址那就必挂。其次说长度问题。生成bin文件时--zero参数要不要加很多人会纠结。我的建议是一定要加。不加的话段与段之间的空洞不会出现在bin文件里Flash里的地址就和内存地址错位后面不管怎么调都是徒劳。端序问题也常遇到。6678支持大小端模式。如果你的.out是按大端编译的生成的bin文件的Boot Table头也是个特定格式而ROM Bootloader在SPI启动时默认按小端解析就会出问题。建议统一用默认的小端编译省去一堆麻烦。5.5 排除启动异常时的检查顺序板子启动不了不要慌按这个顺序查第一步确认转换后的bin文件头部是不是IBTL不是就回头查hex6x脚本。第二步用示波器抓SPI这几个信号CS、SCK、MOSI、MISO。上电后CS要有低脉冲SCK要有持续时钟MOSI上能看到读命令字节MISO上要能返回Flash数据。任何一路信号异常先查硬件连接。第三步确认Flash里的数据和bin文件一致。用烧写工具读回Flash逐字节比对别省这一步。第四步确认Boot mode拨码设置正确。6678的Boot模式由多个外部引脚决定拨错了优先级最高的排查项。第五步确认核0的程序是否有基础的外设初始化。SPI引导默认是核0启动其他核要靠核0来唤醒。如果核0的程序里没有正确配置PLL、DDR或者没有唤醒其他核现象可能非常迷惑。6. 个人操作心得这套流程我前前后后折腾过不下十次从最早的6713到6678每次都能遇到新的问题。印象最深的一次是bin文件转换正常IBTL头也对Flash和bin比对完全一致但上电就是不启动。查了两天最后发现是Flash的HOLD#引脚悬空导致的引脚受到噪声干扰后Flash在数据传输过程中突然进入保持状态数据流断裂。补上拉电阻之后一切正常。从那以后我养成了一个习惯拿到新板子先把Flash周边电路全部过一遍该上拉的上拉该串联匹配电阻的匹配好再开始调软件。硬件上的一个浮空引脚比软件上几十行代码还折腾人。bin转换和烧写这件事技术难点不大但操作链路长每一步的错误都会在下一个环节放大。把流程固化下来该写的脚本写好该做的检查做到位经验积累起来之后就很稳定了。