最近在开发280039C
重新安装了CCS开发环境,版本12.8.1
在固化自己建立的工程的时候,发现memcpy函数总是定位到string.h标准库中的定义,从而导致编译报错
另,导入C2000ware中的gpio控制led闪烁工程,调整为固化版本后,发现是memcpy无法找到定义,但是编译并不会报错,固化工程后重启电源工作也是正常的。
所以,我在想,有没有可能是和工程编译选项中是否开启了使用标准库这样类似的功能有关呢
不知道大家遇到过类似的问题没有
您好!我有了一些新的进展。
注意到C2000ware下的280039基础例程中的led闪烁工程使用的是eABI格式,所以我也将我自己建立的280039的Flash版本工程由原本的COFF格式调整为eABI格式,并将运行支持库由rts2800_fpu32.lib调整为rts2800_fpu32_eabi.lib,只改了这一点,工程中的其余配置均未改变,再进行编译就不会报告缺少RamfuncsRunStart、RamfuncsLoadStart、RamfuncsLoadSize了,并且烧录工程后,脱离仿真器、重新上电,程序执行都是正常的。
我之前的工程是COFF格式的,编译出错了以后,虽然在文件中定义RamfuncsRunStart、RamfuncsLoadStart、RamfuncsLoadSize这三个变量如下可以编译成功:
Uint16 RamfuncsRunStart;
Uint16 RamfuncsLoadStart;
Uint16 RamfuncsLoadSize;
但是程序运行后会跑飞。
我在开发TI C2000系类的其他型号处理器时都没有遇到这样的情况。
请问这是为什么呢?
这个l路径下的
\C2000Ware_5_04_00_00\device_support\f28003x\examples\led_ex1_blinky工程
是输出文件是eabi格式,编译就不会报错,如果调整为coff格式,就会报告如下错误
1.能尽快解答一下是为什么吗?或者能告诉下COFF格式下应该怎么定义报错的三个变量呢,还是说280039固化flash只能用eabi格式
2.280049的这个工程,flash版本的输出文件格式是COFF,编译并不会报错,能对比说明下是编译配置有什么区别吗
您好
您需要将给定设备的 driverlib 文件夹作为 CCS 项目导入 CCS。
1. 从以下位置导入 Driverlib 项目(例如,从 C:\ti\c2000\C2000Ware_x_xx_xx_xx\driverlib\f28p65x\driverlib\ccs)
2. 右键点击并选择属性 -> 常规 -> 项目选项卡 -> 输出格式 <COFF>
3.然后你就可以构建了。
这是相关帖子给出的处理方式,您可以尝试一下。
您好,感谢帮助!
您发的图片点不开,也看不到。另外请注意我的处理器型号是TMS320F280039C,而不是28P65,如果是28P65,按照您说的操作有没有问题,我没有亲子操作。
不过,我已经知道问题出在哪里并且解决了!
我的工程使用了instaSPIN BLDC的无位置传感器库,这个库是COFF格式的,因此我一定会用COFF格式建立工程,否则存在兼容性问题。
我使用的280039的Flash版本CMD文件如下
对比该文件和0049的Flash版本CMD文件,可以发现问题所在,如下图所示:
左侧是0039的CMD文件,右侧是0049的CMD文件,可以看到,左侧0039的Flash版本发布是有问题的,并没有像0049那样区分用户使用的是COFF格式还是eABI格式,如果使用的是COFF格式,定义RamfuncsRunStart、RamfuncsLoadStart、RamfuncsLoadSize这三个变量前是要加下划线的“_”,这就是问题所在。
所以,我觉得这是官方发布的CMD文件有问题,或者说不够严谨、完整,新版SDK更新一下吧。0039的SDK里面,有很多版本的CMD文件,有的就区分输出文件格式了,有的就没有区分。0039应该不是一个太新的处理器,老版本的COFF格式应该还是允许用户使用的,在这个系列通用的Flash.cmd文件里出现这个问题,看起来不应该。
这个帖子里提到的问题在以下处理器里都不存在,下面的这些处理器,我都是用过
2808
28335
28027
28069
28379
28388
2812
280049
28035
28075