F28P65x_cmd配置及工程环境问题整理

在开发P65X的BootLoader时，对cmd文件及工程环境建立的整理。

1. warning: Data is being written to auto-generated file

解决方法：首先，出现这个问题的可能性是在配置cmd文件时，通常会分为PAGE0(代码段)和PAGE1(数据段)两个段，工程会输出两个文件，一个.hex文件（对应PAGE0内容），一个.x01文件（对应PAGE1内容），但是生成.hex文件时，一般只会生成代码段的内容（因为代码段的内容会初始化），按照TI官方给定的分配方式决定了哪些量需要初始化，哪些量不需要初始化（见图1）。因此在section分配的时候，如果把原本数据段的内容放到了代码段的话，会造成两个文件输出混乱，产生警告。

另一方面16进制程序默认输出的是hex文件，默认的ROM宽度是8位，将宽度改为16位时（见图2），也会对这个警告有帮助。

图1  section配置需求

1. error: "You must define CPU1 or CPU2 in your project properties.  Otherwise, the offsets in your header files will be inaccurate.

由于28p65x有两个CPU，每个CPU都有自己的内存映射，自己的链接器命令文件以及自己的项目。所以一般我们需要分离项目并使用单独的.out文件对设备进行编程。因此需要在配置过程中预申明是CPU1还是CPU2。

3、No source available for "_system_post_cinit()代码无法dubug的问题。

图2 修改配置

目前项目中的工程一般都是烧到flash中的，可是如果只是从工程里的文件名是看不出烧在哪里的（不看cmd文件的前提下）。在开发28p65x的时候，选择Manage Configuration, 可以发现，有两种配置，一个是Debug，一个是Release。其中Debug 处于Active状态，因此我们配置的文件路径都是针对这个Debug配置的，但实际我们是烧到flash，为了更加形象，我将两个配置重命名为CPU1_RAM（对应Release）和CPU1_FLASH（对应Debug）.这也解决了上面的无法debug的问题。由于已经定义了CPU1_FLASH，要把之前的Debug文件屏蔽掉，不然会报重复定义的错误。

4、#10247-D creating output section xxx without a SECTIONS

出现这个错误后，程序能顺利生成.out文件，但是不能正常运行。出现问题原因及解决方法：cmd文件编写错误，重新编写

5、Unresolved symbol +各类函数+,first referenced....

解决方案：添加source下的相应C文件

6、Unresolved symbol+各种寄存器变量+，first referenced....   

解决方案：报错信息显示有无法解析的寄存器，说明缺少库文件的引入，这里则是缺少了GlobalVariableDef.c。这是一个定义了各种寄存器以及很多全局变量的库文件，不引入项目自然是无法编译的。

7、Unresolved symbol +各类以ISR结尾的函数（比如ADCINT1_ISR）,first referenced....：

分析：缺乏ISR，interrupt service routine缺乏中断服务 解决方案：项目中使用到了中断，则必须要引入defaultISR.c文件，用于默认中断的实现。

8、小知识

MemCopy(&RamfuncsLoadStart, &RamfuncsLoadEnd, &RamfuncsRunStart);

这几句程序是什么意思？

这几句是将FLASH中的程序COPY到RAM中运行，通常的目的是加快程序的运行速度，通常有两种情况需要这样去操作：

1、程序中对于要求比较高的函数，如中断；

2、程序需要对FLASH进行操作，这时就要把程序先复制到RAM中运行然后才能对FLASH操作。

RamfuncsLoadStart、RamfuncsLoadEnd、RamfuncsRunStart这三个变量是在CMD文件中创建的，创建方式如下：

LOAD_START(RamfuncsLoadStart),

LOAD_END(RamfuncsLoadEnd),

RUN_START(RamfuncsRunStart),

分别表示了装载函数的首地址，装载函数的结束地址和装载函数的运行地址；

执行完MemCopy(&RamfuncsLoadStart, &RamfuncsLoadEnd, &RamfuncsRunStart);后，便将FLASH中相关的程序COPY到了RAM中，之后的程序运行时，只要调用FLASH中RamfuncsLoadStart地址开始的相关函数，系统都会自动地指向RAM中相应的函数入口地址运行。

9、COFF输出格式设置

       目前工程输出文件有两种格式，一个是COFF类型的ABI,一个是EABI类型，COFF ABI 和 EABI 不兼容 - 链接到应用程序二进制文件的所有代码都必须遵循相同的 ABI。

       输出格式为COFF时，如果设置--idiv_support为idiv0，需要在编译选项中加入--abi=eabi 指令，因为idiv0只有在EABI格式的时候才支持，COFF时编译会报错：error #24018-D: Option --idiv_support=idiv0 is not valid without --abi=eabi，所以若工程输出为COFF时，将idiv0改为默认，并且加入--abi=coffabi

图4 COFF工程配置

另一方面，COFF与EABI格式下的cmd文件的section与ramfunc定义的格式也会有区别：

图5 不同格式下Section name

图6 COFF格式下的ramfunc

10、关于配置float函数及三角函数加速库rts2800_fpu32_fast_supplement、rts2800_fpu32的处理。

首先将工程里的浮点支持类型设置为32位

然后在C2000 linker- file search path中添加这2个库

然后在Build里加入库的Link Order

这里配置完之后编译会有个警告：#10247-D creating output section "FPUmathTables" without a SECTIONS specification

从警告中可以看出没有给FPUmathTables分配地址段，因此需要在cmd文件中分配地址，经过调试发现，当把FPUmathTables分配给数据段（PAGE1段）时，会产生输出文件错乱的警告warning: Data is being written to auto-generated file

由于这个告警与本文档的第一个告警一致，这也就表明FPUmathTables按照系统默认分配的话应该分配到代码段（PAGE0段）

但是怎么知道这个库确实在实际中调用了？是否真的在处理函数的时候加快了？

       第一：检查是否调用可通过工程输出的.map文件查看：

通过一个实例来验证是否加速了（通过一个简单的sin函数，通过打断点及CCS软件自带的可观测每步耗时多少个时钟周期的功能来验证）：

没加库函数之前：

加入库函数（注意：这里在还原的时候，遇到了

#10211-D cannot resolve archive ../lib/rts2800_fpu32_fast_supplement.lib to a compatible library, as no input files have been encountered，将lib文件夹下的库函数屏蔽，告警解除）：

可以看到加入库函数的确是加速了函数的运算速度。