CCS使用笔记

文档

TI 官方文档：Code Composer Studio™ User Guide

软件安装

CCS下载链接：CCSTUDIO IDE, configuration, compiler or debugger | TI.com

SDK下载链接：MCU-PLUS-SDK-AM62A 软件开发套件 (SDK) | 德州仪器 TI.com.cn

• SDK安装完成后，如果需要用CCS编译，则需要做如下配置：

SysConfig下载链接：SYSCONFIG IDE、配置、编译器或调试器 | 德州仪器 TI.com.cn

编译器下载链接：ARM-CGT-CLANG IDE, configuration, compiler or debugger | TI.com

MCAL SDK：

1. 使用以下链接申请

   https://www.ti.com/licreg/docs/swlicexportcontrol.tsp?form_id=337627&prod_no=PROCESSORSDK-MCAL-AM62X&ref_url=EP-Proc-Sitara-MPU

2. 获得批准后，从以下链接下载 MCAL SDK：

   https://www.ti.com/securesoftware/docs/autopagepreview.tsp?opnId=27760

3. 文档

   https://software-dl.ti.com/mcu-plussdk/esd/PLATFORM_SW_MCAL/AM62Ax/09.00.00.01/mcusw_c_ug_top.html

CCT

CTT：Clock Tree Tool，适用于TI处理器的时钟树工具，直观的显示系统时钟。

根据用户定义的时钟源（晶振、PLL等）、分频系数、输出频率等参数，工具可自动生成时钟寄存器配置。

在线使用

TI官网上针对AM62AX的CCT工具是在线的：Log in

其他在线工具：TI Developer Zone

在线的CCT版本是1.1.4。

本地安装

在链接里面可以找到CCT的安装包：TI Resource Explorer

1. 解压下载好的压缩包

2. CCS里面需要导入CCT

   

   可能会有版本不匹配的问题，按照提示解决。

3. 找到sysconfig的安装路径，双击打开

   

   按照如下配置，点击start，会创建cfg文件。save的时候会保存相关的寄存器配置文件。

   

生成物

生成文件说明

• .syscfg 文件：是ClockTree生成的配置文件，可在TI的开发环境中导入使用(目前无法打开，会报错，可能和CCS 的版本有关系)。

• .gel 文件：是用于CCS的脚本文件，可在调试时加载，用于打印时钟寄存器值。

• .py 文件：在Linux环境下，使用k3conf打印时钟寄存器值的Python文件。和gel作用一样，也是打印寄存器的值。打印的结果可以保存到txt，然后再导入CCT里面。

• .rd1 、.rd2 寄存器转储文件：记录寄存器的值，用于调试和验证配置是否正确。

编译报错

SDK和sysconfig版本不匹配报错

sysconfig版本需要和SDK版本匹配，如果不匹配需要自己在TI官网下载并安装SDK以及sysconfig。 修改版本方法见下图，SDK和sysconfig设置方法一致。

如果选择的版本不匹配，会有报错提示

Norflash相关函数链接报错

MCU R5F核添加了norflash驱动，据说是TI修改了SDK，改完的SDK用CCS去编译会出现如下错误：

从上面这个报错，可以推测有一些文件使用了其他C文件的函数，但是编译这个库的时候，没有包含对应文件去编译，导入我们自己的工程后，找不到对应的函数实现，导致链接报错。

MCU+SDK v10.01已经解决了这个问题。

解决方法一：添加缺失的文件

去SDK里面找到缺少的函数定义，找到对应的C文件，添加到我们自己的工程里面。

解决方法二：切换成Release编译

用makefile编译是ok的，CCS编译不行，对比了一下发现makefile是Release的配置，用的库也是release，所以尝试把CCS改为Release，测试是可行的。

1. 选择Release

   

2. 修改完后，发现没有添加对应的头文件，需要手动添加。修改工程文件，添加头文件路径如下

   //找到Release标签
   <cconfiguration
   id="com.ti.ccstudio.buildDefinitions.TMS470.Release.1770007231">
   //添加如下内容 主要就是头文件路径
   <listOptionValue builtIn="false"
   value="${workspace_loc:/${ProjName}/xxx/inc}"/>
   <listOptionValue builtIn="false"
   
   ...

fatal error: ‘xxx.h’ file not found

前提：xxx.c包含了xxx.h文件。

问题的根本原因

在编译命令中，通过 -I 参数指定了多个头文件搜索路径，但这些路径中没有包含 xxx.h 的实际位置。

subdir_rules.mk 的编译命令没有这个路径，因此，编译器无法自动搜索到 xxx.h ，导致报错。

解决方法：

1. 改为相对路径

• 相对路径是相对于当前源文件（ xxx.c ）的位置解析的。编译器会从xxx.c所在目录出发，按照相对路径找到 xxx.h 。

• 相对路径绕过了编译器默认的搜索路径机制，直接指定了文件的实际位置，因此不再依赖 -I参数。

2. 修改 .cproject文件

由于 subdir_rules.mk是自动生成的，而且在项目配置中也添加了头文件路径，但是还是出现了这个错误。于是想到查看 .cproject 文件：

问题在于 xxx.c文件有一段单独的配置，但是这段配置没有包含对应的头文件路径。

• 可以增加xxx.h实际所在的路径

  <listOptionValue builtIn="false" value="${workspace_loc:/${ProjName}/xxx/inc}"/>

• 或者直接把这个单独的配置整个删掉（推荐）

current parser token ‘include’ xxx.h

解决方法：再编译一次。

编译命令：

"D:\\ti\\ccs1240\\ccs\\utils\\bin\\gmake" -k -j 16 all -O

• -j 16是明确的并行编译标志，表示允许同时运行 16 个编译任务。

• -O选项表示输出同步（--output-sync ），确保不同线程的编译日志不会交错显示。

可能的原因：

1. 首次编译：如果某些生成的代码（如 xxx.h ）尚未完成生成，而其他线程已经开始编译依赖它的文件（如 xxx.c ），会导致头文件缺失错误。

2. 第⼆次编译：生成的文件已经存在（如 xxx.h ），竞态条件消失，编译成功。

降低并行度测试

可以使用单线程编译验证是否为竞态问题，如果单线程编译始终成功，则可确认是并行竞态问题。

“../linker.cmd”, line 53: error #10099-D: program will not fit into available memory,

按照ti demo工程替换linker.cmd文件后，使用ccs编译报错，原因是内存不⾜。

查看map文件发现，ccs debug模式下，没有编译优化，编译出来的文件text段比较⼤。

解决方法：可以和makefile文件使用相同的编译优化参数

打赏