TMS320C6000系列DSP的Flash启动设计

2万 · 2014-4-3 23:46

引言

随着近年来数字信号处理器(DSP)技术的迅猛发展，其越来越广泛地应用于国民经济的各个领域中。其中，TI公司推出的TMS320C6000系列DSP器件更是在许多需要进行大量数字信号处理运算并兼顾高实时性要求的场合得以应用。TMS320C6000系列DSP的系统设计过程中，DSP器件的启动加载设计是较难解决的问题之一。
C6000系列DSP的启动加载方式包括不加载、主机加载和EMIF加载3种。
3种加载方式的比较：不加载方式仅限于存储器0地址不是必须映射到RAM空间的器件，否则在RAM空间初始化之前CPU会读取无效的代码而导致错误；主机加载方式则要求必须有一外部主机控制DSP的初始化，这将增加系统的成本和复杂度，在很多实际场合是难以实现的；EMIF加载方式的DSP与外部ROM／Flash接口较为自由，但片上Bootloader工具自动搬移的代码量有限(1 KB／64 KB)。本文主要讨论常用的EMIF加载方式。
1 EMIF加载分析
实际应用中，通常采用的是EMIF加载方式，把代码和数据表存放在外部的非易失性存储器里(常采用Flash器件)。
下面以TMS320C6000系列中最新的浮点CPU——TMS320C6713(简称“C6713”)为例，详细分析其EMIF加载的软硬件实现。
硬件方面，其与16位宽度的Flash器件的接口如图1所示。

对于不同的DSP器件，加载方式的配置引脚稍有不同。C6713的配置引脚及其定义如表1所列。

应用程序的大小决定了片上的Bootloadet工具是否足够把所有的代码都搬移到内部RAM里。对于C6713，片上的Bootloader工具只能将1 KB的代码搬入内部RAM。通常情况下，用户应用程序的大小都会超过这个限制。所以，需要在外部Flash的前1 KB范围内预先存放一小段程序，待片上Bootloader工具把此段代码搬移入内部并开始执行后，由这段代码实现将Flash中剩余的用户应用程序搬移入内部RAM中。此段代码可以被称作一个简单的二级Bootloader。

2万 · 2014-4-3 23:47

图2所示为使用二级Bootloader时的CPU运行流程。

使用二级Bootloader需要考虑以下几个事项：
◇需要烧写的COFF(公共目标文件格式)段的选择；
◇编写二级Bootloader；
◇将选择的COFF段烧入Flash。
一个COFF段就是占据一段连续存储空间的程序或数据块。COFF段分为3种类型：代码段、初始化数据段和未初始化数据段。
对于EMIF加载方式，需要加载的镜像由代码段(如．vectors和．text等)和初始化数据段(如．cinit，．const，．switch，．data等)构成。另外，可以单独定义一个．boot-load段存放二级Bootloader。此段也需要写入Flash。
所有未初始化的数据段(如．bss等)都不需要烧入到Flash中。
2 二级Bootloader的编写
由于执行二级Bootloader时C的运行环境还未建立起来，所以必须用汇编语言编写。二级Bootloader可参照其他类似文献及TI相关文档。此处不再赘述。
CCS中用户工程编译链接后产生的．map文件包含了存储器的详细分配信息。一个典型的map文件中包含的存储器分配信息如表2所列。
与cmd文件不同，map文件不仅包含了各段存储在哪一段内存空间的信息，从map文件中还可以具体知道每个内存区间中有多少被实际使用(烧写Flash时会用到这个参数)。内存区间中未被使用部分是不需要写入Flash内容的，实际被使用的部分才是真正需要写人到Flash中的内容。

2万 · 2014-4-3 23:47

3 Flash的烧写
把代码等写入Flash的办法大体上可分为以下几种：
① 使用通用烧写器写入。
② 使用CCS中自带的FlashBurn工具。
③ 用户自己编写烧写Flash的程序，由DSP将内存映像写入Flash。
其中，使用通用烧写器烧写需要将内存映像转换为二进制或十六进制格式的文件，而且要求Flash器件是可插拔封装的。这将导致器件的体积较大，给用户的设计带来不便。
使用TI公司提供的FlashBurn工具的好处在于使用较为直观。FlashBurn工具提供的图形界面可以方便地对Flash执行擦除、编程和查看内容等操作。但这种力法的缺点也不少：首先，FlashBurn工具运行时需要下载一个．out镜像(FBTC，FlashBurn Target Component)到DSP系统中，然后由上位PC机通过仿真器发送消息(指令和数据)给下位DSP，具体对Flash的操作由FBTC执行。然而，这个FBTC一般是针对TI公司提供的DSP专门编写的，与板上使用的Flash的接口宽度(默认是8位)、操作关键字(因生产厂商不同而各异)都有关，所以，对用户自己制作的硬件不一定适合。例如：如果用户自己的电路板上使用的是与DSK同品牌的Flash芯片，接口为16位数据宽度，那么，使用FlashBur’n工具烧写将最多只有一半的Flash容量能够被使用，要想正确实现]EMIF加载就必须选择8位加载方式。这就造成了Flash存储器资源的浪费，同时限制了用户开发的灵活性。
虽然TI公司提供了FBTC的源代码供有需要的用户修改，但这样用户需要去了解FBTC的运行机制及其与上位机的通信协议，并对Flash烧写函数进行修改。用户可能需要修改的几个地方如下：对Flash编程的关键字和地址，BurnFlash函数中的数据指针和EMIF口的配置(针对1.0版本FBTC)。这就给用户开发带来了不便。把开发时间浪费在了解一个并不算简单的Flash烧写工具上并不是一个好的选择。

其次，FlashBurn工具不能识别．out文件，只接受..ex的十六进制文件，因此，需要将.out文件转换为．hex文件。这个转换的工具就是TI公司提供的Hex6x.exe工具。转换过程的同时，需要一个cmd文件(即图3中的Hex.cmd)指定作为输入的.out文件，输出的.hex文件的格式，板上Flash芯片的类型和大小，需要写入Flash中的COFF段名等。

使用用户自己编写的烧写Flash的程序较为灵活，避免了文件格式转换的繁琐。不过，此方法要求用户对自己使用的Flash芯片较为熟悉。

2万 · 2014-4-3 23:47

通常采用的Flash烧写程序是单独建立一个工程的办法：先把用户应用程序(包含二级Bootloader)编译生成的.out文件装载到目标DSP系统的RAM中，再把烧写Flash的工程编译生成的.out文件装载到目标DSP系统RAM的另一地址范围，执行Flash烧写程序，完成对Flash的烧写。这个办法要注意避免两次装载可能产生的地址覆盖，防止第2次装载修改了应该写入Flash的第1次装载的内容。
实际上，可以将Flash烧写程序嵌入到用户主程序代码中去，比单独建立一个烧写Flash的工程更为方便。Flash芯片的烧写程序段如下：

ChipErase函数和ProgramFlashArray函数的编写可参照用户使用的Flash芯片的Datasheet以及参考文献[1]。
ProgramFlashArray函数的第1个参数是源地址指针(指向内部Ram)，第2个参数是目标地址指针(指向外部Flash)，第3个参数是要写入的数据长度(单位为字)。

2万 · 2014-4-3 23:48

编写Flash烧写函数时有3点需要注意：
① 指向Flash地址的指针。由于C6713的低两位地址用于译码作字节选择，地址总线的最低位是EA2，所以，逻辑地址需要适当的移位才能正确地指向日标。
对8位存储器而言，应该左移2位；对16位存储器而言，应该左移1位；对于32位存储器，则不需要移位。例如要从(往)Flash的0x00000003地址读(写)一个字，其逻辑地址应该是0x90000000+(0x0003<<1)，而非0x90000003。
② map文件中各内存区间被实际占用的尺寸大小是以字节为单位的，而ProgramFlashArray函数写入Flash的数据单位为字，所以需要将map文件中得到的尺寸大小的一半作为ProgramFlashArray函数的参数。
③ 烧写函数中使用了flash_burned常量作为判断是否需要对Flash操作的依据，且将其初始化为1。这是为了避免Flash加载之后会执行对Flash的操作。此变量应在烧写Flash时手动修改为0。
在仿真加载方式下，可以在CCS里的watchwindow窗口手动修改flash_burned常量为0，强迫CPU进入对Flash编程的程序段。实验证明，在仿真加载方式下手动修改flash_burned并不影响写入到Flash中的flash_burn-ed的值(仍为1)，所以，写入Flash的flash_burned的值仍然是1。在系统Flash加载之后，CPU就会跳过此段代码，实现正确运行。
4 结论
本Flash加载方案以C6713为例，稍加修改即可适用于TMS320C6000系列的其他DSP器件。经过在研制的伺服测试平台中的应用，证明本方法切实可行且易于实现，避免了目标文件格式的转换，比通常采用的FlashBurn工具使用起来更灵活方便，用户可以通过简单修改Flash烧写函数使之适应自己的硬件情况。对于Flash器件接口与TI的DSP不一致的情况，本方案是一个很好的选择。

-43 · 2014-6-25 17:15

好贴啊，正需要。

-43 · 2014-6-25 17:17

本帖最后由 sjl0991 于 2014-6-25 17:19 编辑

求助，使用C6701向片外的am29lv800b FLASH芯片写数据的问题

大家好，使用C6701向片外的am29lv800b FLASH芯片写数据。有如下反应：
program(int *flash_ptr)
{
   int i;
   * ctrl_addr1 = 0x00aa;  //memory 显示 0x00aa00aa
   * ctrl_addr1 = 0x0055;  //memory 显示 0x00550055
   * ctrl_addr1 = 0x00a0; //memory 显示 0x00a000a0
   for(i=0;i<length;i++)
   {
      * flash_ptr++=i; //memory 显示所有flash区域一起写，最后程序执行完，就是最终写入的数据
   }
}
问题1：
写控制字时，flash区所有地址一起变化，这样是不是正常的反应？
问题2：
* flash_ptr++=*source_ptr++; 这一句本来应该地址不断偏移，不同地址写入不同的数据，在watch窗口能看到地址偏移正常，但是也是所有flash区域一起写，最后程序执行完，flash映射区所有地址写入的是最终写入的数据，这样不对呀，这种错误怎么解决呢？

1万 · 2014-6-26 22:03

3种加载方式的比较：不加载方式仅限于存储器0地址不是必须映射到RAM空间的器件，否则在RAM空间初始化之前CPU会读取无效的代码而导致错误；主机加载方式则要求必须有一外部主机控制DSP的初始化，这将增加系统的成本和复杂度，在很多实际场合是难以实现的；EMIF加载方式的DSP与外部ROM／Flash接口较为自由，但片上Bootloader工具自动搬移的代码量有限(1 KB／64 KB)。

1万 · 2014-6-27 22:13

C6000系列DSP的启动加载方式包括不加载、主机加载和EMIF加载3种。
3种加载方式的比较：不加载方式仅限于存储器0地址不是必须映射到RAM空间的器件，否则在RAM空间初始化之前CPU会读取无效的代码而导致错误；主机加载方式则要求必须有一外部主机控制DSP的初始化，这将增加系统的成本和复杂度，在很多实际场合是难以实现的；EMIF加载方式的DSP与外部ROM／Flash接口较为自由，但片上Bootloader工具自动搬移的代码量有限(1 KB／64 KB)。本文主要讨论常用的EMIF加载方式。

TMS320C6000系列DSP的Flash启动设计

相关下载

相关帖子

坚毅之洋流

技术高手奖章

精英会员奖章

常驻人口

技术新星奖章

突出贡献奖章

沉静之湖泊

湍急之河流