简介：这份文档面向初次接触德州仪器CCS5集成开发环境的嵌入式学习者与工程调试人员，围绕软件安装、许可配置及后续工程使用整理了一份较完整的图文指引。内容重点说明CCS5安装过程中的组件选择、工作区间设置与License文件添加，并涉及破解文件替换和full.lic获取等流程；同时延伸到已有工程导入、新建工程、头文件与源文件添加、目标配置文件创建及调试器启动等常见环节。压缩包仅含1个docx文件，大小约1.53MB，以分步文字和界面截图组织，方便按章节查阅。目前已有718人学习下载，适合需要快速搭建CCS5开发环境、理清安装与许可配置思路的读者参考，也可作为实验课前环境准备的自查材料。

1. 装机十分钟，排错三小时：CCSv5 这套老 IDE 到底卡在哪

翻出几年前课设用的那块开发板，插上仿真器，打开 CCS5 想点个灯，结果第一步就卡在安装向导——这种场景我见过太多次。CCS5（Code Composer Studio v5）是那几年主流的嵌入式集成开发环境，编辑、编译、链接、下载、调试全在一个窗口里完成，配套的 DSP 与低功耗单片机工程至今仍有大量存量代码在跑。这类老 IDE 的麻烦从来不在安装包本身：路径里一个空格、工作区里一个中文目录、目标配置文件没设成活动状态，任意一处都能让后面的编译和下载全线崩。这份 CCS5 安装教程把安装、导入工程、新建工程、目标配置和调试串成了一条完整的链，下面按「装之前 → 装完 → 导入/新建 → 调试」重走一遍，赶时间的老手直接跳到第 2 章的路径规则和第 5 章的排错记录。

2. 装机前把环境定死：安装包校验、路径规则与组件勾选

装 CCSv5 这件事，成败在双击安装程序之前就决定了一大半。我手上这份文档是从运行ccs_setup_5.3.0.00090.exe讲起的，但看过太多「装到 80% 回滚」「装完启动报错」的现场之后，我更愿意把前面这半小时单独拿出来——校验安装包、规划路径、想清楚勾哪些组件，后面能省下几小时的排错。

2.1 先确认手里这个安装包是完整的

CCSv5 的安装程序是几个 GB 级别的自解压包，下载中断、网盘二次压缩、复制过程中断都会留下一个「能双击、能跑起来、装到一半崩」的残缺文件。我一般的做法是先算一遍哈希再动手，并且把安装包放在纯英文目录下，不要直接扔在下载文件夹里跑。

import hashlib, os, sys INSTALLER = r"D:\download\ccs_setup_5.3.0.00090.exe" def sha256(path, chunk=1 << 20): h = hashlib.sha256() with open(path, "rb") as f: # 分块读，避免几个 GB 的文件一次性吃满内存 for block in iter(lambda: f.read(chunk), b""): h.update(block) return h.hexdigest() if not os.path.exists(INSTALLER): sys.exit("安装包路径不对，先把它挪到纯英文目录再跑这个脚本") print("文件大小: %.2f GB" % (os.path.getsize(INSTALLER) / 1024 ** 3)) print("SHA256 :", sha256(INSTALLER))

这段脚本只做两件事：报出体积、报出哈希。体积用来快速判断是不是下载残缺（明显小于正常值时不用再算哈希），哈希用来和资源包里附带的校验值比对，一致再装。chunk参数默认 1MB，机械盘上可以调到 4MB，速度会快一点；INSTALLER换成你自己的实际路径，注意字符串前面的r不要去掉，否则 Windows 路径里的反斜杠会被当成转义符。算完对不上，别抱着「也许能装」的侥幸心理往下走，重下一遍比装到一半回滚省事得多。

2.2 安装路径与工作区路径的三条硬规则

这一节是整个装机流程里最容易被人忽略、又最容易在后面咬你一口的地方。原始文档给的安装目录是\ti\ccsv5，工作区间是\CCS5.3Workspace，这个思路本身没问题，但细节必须补全。

第一条，全路径不能有中文、不能有空格。CCSv5 底层调用的是 GNU make 和其它一堆命令行工具，路径里出现空格时，某条规则就会被拆成两段参数，编译阶段报出莫名其妙的No rule to make target，你盯着源码看半天也找不出错。第二条，不要装在Program Files下面，也不要装在桌面或任何云同步目录里——前者会碰到权限和虚拟化重定向，后者会在同步时锁文件，装到一半卡死。第三条，安装目录和工作区必须是两个独立目录，且尽量放在同一个物理磁盘上，工程里的相对路径引用才不会在跨盘时失效。

装完之后别急着点 Finish，先用一段脚本把目录结构核一遍。这一步花十秒，能提前发现「组件没勾全」这种返工级别的问题：

import os INSTALL_ROOT = r"D:\ti\ccsv5" NEEDED = [ r"ccs_base\DebugServer", # 调试服务，下载和断点全靠它 r"ccs_base\common\targetdb", # 器件与板卡描述库，新建工程选型时读这里 r"tools\compiler", # 编译器，工程属性里的版本号对应这里的目录 r"ccs_base\emulation\drivers", # 仿真器驱动，设备管理器认不认板子看它 ] missing = [p for p in NEEDED if not os.path.isdir(os.path.join(INSTALL_ROOT, p))] print("缺失目录:", missing if missing else "无，结构完整")

NEEDED里这四项分别对应调试、选型、编译、连接四条链路，缺任何一项都要回去补装。注意tools\compiler下面通常会有按版本号命名的子目录（例如ti_cgt_c6000_x.x.x），工程属性里指定的是具体版本而不是这个父目录，这一点在第 3 章还会再说一次。如果你打算把安装目录挪到别的盘，请在装之前就想好，装完再搬会因为注册表和快捷方式里的绝对路径失效而翻车。

2.3 组件勾选：Complete Feature Set 与 Custom 的区别

运行安装程序后，向导第一个关键岔路口是组件选择。原始文档给的路径是先选Complete Feature Set，进入手动选择通道，然后把所有选项勾上。这套做法在硬盘充裕的机器上是对的，全勾最省心；但如果你的机器盘位紧张，或者需要同时保留多个版本的 CCS，就得知道每一项到底在干什么。

全量安装的磁盘占用是几个 GB 的量级，装之前看一眼剩余空间，别装到 95% 再去找哪里能删。安装过程中还有一个老生常谈的问题：系统自带的实时防护和第三方杀毒软件会对解压出来的大量可执行文件做扫描，表现就是进度条卡在某个百分比不动，或者干脆弹窗拦截。我的习惯是安装期间临时关掉实时扫描，装完再打开，并且把安装目录加进排除列表——不是为了绕过什么，纯粹是几百个小文件被逐个扫描会让安装时间翻好几倍。

2.4 点 Finish 之前的三件事

很多人的习惯是装完直接点 Finish，勾着「立即启动 CCS」，然后在一片混乱里开始找问题。我一般会把那个勾去掉，先做三件事。

一是回安装目录确认ccs_base\emulation\drivers里的驱动文件齐全，然后插上开发板，打开设备管理器看有没有未知设备；二是确认安装目录下没有多余的可执行文件被塞进来，尤其是调试服务目录（ccs_base\DebugServer），这个目录一旦被替换过二进制文件，后面调试阶段的报错会变得完全无法归因，属于典型的黑匣子；三是重启一次。别嫌麻烦，仿真器驱动是在内核层注册的，不重启的话设备管理器和 IDE 看到的状态可能不一致，第一次连板子就报连接失败，白白浪费半小时怀疑硬件。

3. 第一次启动的三个岔路口：Workspace、License 与器件支持

安装向导走完，真正的第一道坎才刚开始。第一次启动 CCSv5 会连着问你三件事：工作区放哪、License 怎么给、这颗器件支不支持。三个问题任意一个答错，后面都会以「编译不过」「下载失败」的形式报出来，而错误信息往往指向完全无关的地方。

3.1 Workspace：那个装满元数据的黑匣子

Workspace 不是一个简单的文件夹，它是 Eclipse 框架的工作区，里面除了你的工程目录，还有一个隐藏的.metadata目录，存着工程列表、窗口布局、断点记录、目标配置的活动状态。原始文档建议在某个磁盘下新建CCS5.3Workspace，并且在启动对话框里不勾Use this as the default and do not ask again——这个建议我完全认同，理由不是「每次问一下更安全」，而是当你要在多个版本的 CCS 之间切换时，强制每次确认能避免工作区串味。

Use this as the default一旦勾上，之后每次启动都会静默加载同一个工作区，你哪天想切到另一个版本的工程，会发现工程列表里空空如也，还得去翻偏好设置改回来。多版本共存时我的命名习惯是带版本后缀：D:\CCS5.3Workspace、D:\CCS6Workspace，一个版本对应一个工作区，互不干扰。工作区路径同样遵守第 2 章的规则——纯英文、无空格、不放同步盘。

还有一个不太被提及的点：.metadata是易碎品。工作区崩溃、强制关机、磁盘写满，都可能让它损坏，表现是启动时提示工作区无法加载，或者工程列表整个消失。工程源码本身还在，只是索引丢了。所以我的习惯是工程代码一律放在工作区的子目录里，并且定期把整个工作区目录打包备份一份，出问题时删掉.metadata重建索引，代码一行不丢。这段可以用脚本做一次健康检查：

import os, glob WS = r"D:\CCS5.3Workspace" meta = os.path.join(WS, ".metadata") print("工作区存在:", os.path.isdir(WS)) print("元数据目录存在:", os.path.isdir(meta)) # 扫出工作区下所有带 .project 的目录，这些才是真正的 CCS 工程 projects = glob.glob(os.path.join(WS, "*", ".project")) for p in projects: print("工程:", os.path.dirname(p))

glob那一行扫的是.project文件，它是 Eclipse 判定「这个目录是不是一个工程」的唯一依据，没有它，目录里放再多.c文件也导不进来。这个脚本在接手别人机器的时候特别好用，能一眼看清工作区里躺了几个工程、哪些是半成品。

3.2 License 配置：三条正规路径与一条我不建议走的路

第一次启动 CCS 会弹出许可选择窗口，点 OK 进主界面，然后走Help → CCS License Information，切到Manage选项卡，点Add打开Add License Location，Browse找到你的许可文件打开即可。流程本身很简单，真正需要说清楚的是「许可文件从哪来」。

正规路径大致三条。第一条是随开发板或仿真器附带的授权，很多教学板和评估板出厂就带一份可以在本机激活的许可，找板子包装里的资料或者供应商给的下载包里通常能找到。第二条是官方提供的免费档位，通常对代码体积有限制（不同器件族的阈值不一样，具体数值以License Information View窗口里显示的为准，不要照抄别人的数字），用来跑跑例程、点点灯、验证链路完全够用。第三条是机构或项目采购的正式授权，需要把许可文件和你的机器绑定，换机器要重新申请。

注意：网上流传的一类做法是往安装目录的调试服务目录里替换二进制文件来绕过许可。这条路我不写，也不建议走，原因很实在：替换过的调试服务在杀毒软件眼里就是可疑文件，随时可能被隔离；一旦被隔离，Debug 阶段会报出跟许可毫不相关的连接错误，你会花几个小时去查仿真器驱动；更麻烦的是团队交接的时候，这台机器为什么能跑、那台为什么不能跑，没人说得清。

判断自己的安装目录有没有被动过，有个简单办法：看调试服务目录里文件的数量和修改时间，正常安装出来的文件时间戳应该集中在安装那一刻，出现几个明显更晚、来源不明的可执行文件就要警惕。这条检查在接手别人的机器时尤其管用。

3.3 器件支持与编译器版本核对

License 过了之后，下一个隐性坑是器件支持与编译器版本。CCSv5 的器件库在ccs_base\common\targetdb下，新建工程时Device那一栏能选到什么，取决于你安装时勾了哪些器件族。原始文档在新建工程时选的是Family: C6000、Variant: C674x Floating-point DSP，如果你装的时候只勾了单片机族，这一栏里根本找不到对应选项，会误以为是安装包坏了。

编译器版本是另一回事。tools\compiler下可能同时躺着好几个版本的工具链，工程属性里有单独一栏Compiler version，指定工程用哪一个来编译。导入别人做的工程时最容易在这里翻车：工程里写死了某个版本号，你的机器上恰好没装那个版本，编译立刻报错，提示找不到编译器。解决办法不是重装，而是右键工程 →Properties→General→ 把Compiler version改成你机器上已有的版本，再重新编译。改版本可能带来少量语法兼容问题，跑通了再考虑要不要补装原版本。

3.4 编码设置：中文注释乱码的根治

这一条看起来跟安装没关系，但它决定了你第一次打开别人工程时的心情。CCSv5 默认的文本编码在不同版本、不同系统语言环境下不一致，表现是打开.c文件，中文注释全变成一堆方块或者问号，编译倒是能过，但代码基本没法读。

根治的办法是统一编码，而不是每次打开文件手动改。走Window → Preferences → General → Workspace，把Text file encoding设成UTF-8；如果原有工程是 GBK 编码保存的，要么改成 UTF-8 后整体另存一遍，要么把这个工程的编码单独设成 GBK，不要一半一半混着来，混合编码是后面合并代码时最容易出问题的地方。顺带把字体调大一点，CCSv5 默认的编辑器字号在高分屏上看着是真的累。

4. 工程进出的两条路：导入、新建与 .ccxml 目标配置

IDE 装好了，工作区定了，接下来就是让工程跑起来。这一步分两条路：把现成的工程导进来，或者从零新建一个。两条路最后都要汇到同一个地方——目标配置文件.ccxml，它决定了编译好的程序到底往哪块板子上送。

4.1 导入既有工程：先复制，再导入

原始文档讲导入的流程是：File → Import，展开Code Composer Studio，选Existing CCS Eclipse Projects，Browse选中工程所在目录，Finish。流程没错，但它有一句特别提示容易被跳过——「需在此之前，将实验代码复制到工作区间下」。

这句话是关键。CCSv5 的导入有两种模式，一种是引用原位置的工程，一种是复制进工作区。如果你直接把 U 盘或者别人机器上的工程目录导进来而不复制，工程里的相对路径会指向那个临时位置，拔了 U 盘或者对方改了目录名，下次打开就是满屏红叉。我的习惯是先复制、再导入，路径永远落在自己的工作区里。

import os, shutil, sys SRC = r"E:\课设资料\myccs1" # 别人给的工程目录 WS = r"D:\CCS5.3Workspace" # 自己的工作区 DST = os.path.join(WS, os.path.basename(SRC)) if not os.path.isdir(os.path.join(SRC, ".project")): sys.exit("源目录里没有 .project，这不是一个 CCS 工程") if os.path.exists(DST): sys.exit("目标已存在，先确认要不要覆盖再动手") shutil.copytree(SRC, DST) print("已复制到:", DST) print("下一步：File → Import → Existing CCS Eclipse Projects → 选这个目录")

脚本干的事很直白：检查源目录里有没有.project（没有就不是 CCS 工程，导也导不进去），再把整个目录复制到工作区下。SRC和WS换成你自己的路径，注意SRC里如果混着.metadata或者编译产物，copytree会一并复制过来，想干净一点可以加ignore参数把Debug、Release这类输出目录排除掉。导入完成之后如果工程名前面带个红叉，先别慌，多半是编译器版本不匹配，回到 3.3 节改一下就正常了。

4.2 新建空工程：Output type 与器件选型

新建工程的入口是File → New → CCS Project。弹窗里有几个字段必须想清楚再填。Project name就是工程名，建议全英文、不带空格。Output type有两个选项：Executable构建完整可执行程序，Static library构建静态库，做应用选前者，做可复用的算法模块选后者。原始文档在这里保留Executable，跑例程的话这是对的。

Device部分是整个新建流程里最需要谨慎的地方。Family选C6000、Variant选C674x Floating-point DSP、再挑具体型号，Connection保持默认即可。这里的选项决定了工程默认的链接命令文件、寄存器定义、启动代码，选错了不是改两行代码能救回来的，编译能过，下载进去跑飞，现象跟硬件坏了几乎一样。选完之后勾「空工程」，Finish，工程会出现在Project Explorer里，一个干净的骨架，什么都没有。

接下来是往骨架里填文件。新建头文件走右键工程 →New → Header File，文件名必须以.h结尾；新建源文件走New → Source File，必须以.c结尾——后缀漏了，IDE 会把它当普通文本处理，不参与编译，你会对着一个「明明有代码却什么都没发生」的工程发呆。

已有文件要挂进工程，走右键 →Add Files，弹窗里有个容易被忽略的选项：Copy files还是Link to files。选Copy files，文件会被物理复制进工程目录，工程自包含，换机器照样能用；选Link to files，工程里只存一个指向原位置的链接，原文件一挪、一删、一改名，工程立刻报文件找不到。团队协作的工程我一律要求Copy files，代价是多占一点磁盘，换来的是不会在半年后打开工程发现一堆断链。

4.3 .ccxml 目标配置：一个工程只能有一个活动配置

这是 CCSv5 里概念最绕、也最容易漏掉的一环。编译通过不等于能下载，中间还隔着目标配置——它告诉调试器「用哪个仿真器、连哪颗芯片」。

创建方式是右键工程 →New → Target Configuration File，文件名以.ccxml结尾，原始文档按开发板命的名，TMS320C6748.ccxml，这种「按器件型号命名」的习惯很好，一看就知道这个配置是给谁用的。Finish之后会打开目标配置编辑器，Connection一栏如果是纯软件仿真就选模拟器，要连真板子就选对应的仿真器型号；Board or Device里选具体器件，注意大小端要和工程一致。

配置文件本身就是一个 XML，节点名在不同版本里略有差异，但关键的id和href两处含义稳定：

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <configurations XML_version="1.2" id="configurations_0"> <configuration XML_version="1.2" id="configuration_0"> <!-- connection 决定用哪个仿真器：模拟器 / 外置仿真器 / 板载仿真器 --> <instance XML_version="1.2" desc="TI Instruments Simulator" href="connections/TI_Simulator.xml" id="TI Instruments Simulator" xml="TI_Simulator.xml" xmlpath="connections"/> <connection XML_version="1.2" id="TI Instruments Simulator"> <!-- device 必须和工程 Device 选项一致，不一致会在下载阶段报器件不匹配 --> <instance XML_version="1.2" href="devices/C6748.xml" id="C6748" xml="C6748.xml" xmlpath="devices"/> </connection> </configuration> </configurations>

改这个文件我更推荐用可视化编辑器改，手改 XML 容易漏掉一个必填属性，导致配置文件加载失败。配好之后Save，配置会自动设为活动状态。一个工程可以挂多个.ccxml——比如一个给模拟器跑算法验证，一个给真板子跑硬件联调——但同时只有一个是活动的。想确认哪个是活动配置，去View → Target Configurations里看，带高亮的那个就是。

4.4 编译前必查的三处

在点Project → Build Project之前，有三处值得花两分钟过一遍。一是包含路径，头文件搜索路径尽量用$(PROJECT_ROOT)这类工程变量加相对路径，写死成D:\xxx\inc的绝对路径，换台机器就编译不过。二是编译器版本，就是 3.3 节说的那个字段。三是优化等级，调试阶段建议关掉优化或者只开最低档，高等级优化会把变量优化掉、把循环展开、把行号对不上，你在断点处看到的变量值跟源码逻辑完全对不上，这种玄学现象十有八九是优化开的太高。

编译结果看Problems窗口和Console窗口。Problems里没有错误、Console里最后一行是构建完成的提示，就说明可以进入调试。有错误的话从第一条开始改，编译器的错误提示经常有连锁反应，第一条修好了后面十条自动消失。

5. 避坑与排查：五条装机后最容易翻车的记录

这一节是我这些年被问得最多的问题，全部按「现象 → 原因 → 解决」写。装 CCSv5 这件事的诡异之处在于，同一个报错背后可能有三个完全不同的原因，所以别急着搜错误码，先按下面的顺序自查一遍。

5.1 安装到一半进度条不动，最后回滚

现象：安装程序跑到某个百分比长时间没反应，或者弹窗报错后自动回滚，安装目录里留下半套文件。

原因：按出现频率排序，第一是实时防护在逐个扫描解压出来的可执行文件，几百个小文件扫下来进度条就跟冻住一样；第二是安装包本身残缺，从网盘拖下来的时候断过；第三是装在了Program Files或者带空格、带中文的路径下，解压阶段的写权限被拦。

解决：先算哈希确认安装包完整（2.1 节的脚本），再把安装包挪到纯英文目录、装到非系统盘，安装期间临时关闭实时扫描并把目标目录加入排除列表。已经回滚过的机器不要直接重装，先把残留目录删干净，注册表里的残留交给安装程序自带的卸载入口处理，硬删目录再装的后果是第二次装完启动时报一堆缺库。

5.2 点 Debug 报连接目标失败

现象：编译一切正常，点绿色小虫子下载，弹窗提示连接目标失败，常见的是Error -1135、Error -1180这一类编号，或者干脆提示找不到仿真器。

原因：这类编号基本都指向连接层，跟代码没关系。可能是仿真器驱动没装好，设备管理器里挂着未知设备；可能是.ccxml里选的仿真器型号和实际插的那根不一致；可能是板子没供电或者被复位键按住；也可能是目标配置里选的器件和板子上实际焊的型号对不上。

解决：按「物理层 → 驱动层 → 配置层」的顺序查。先确认板子供电正常、仿真器线插紧、复位键没卡住；再打开设备管理器看有没有黄叹号设备，有就回安装目录装驱动然后重启；最后打开View → Target Configurations确认活动的那个.ccxml里Connection和Board or Device都对。三步都过了还连不上，换一根线或者换一台机器交叉验证，能快速判断是板子的问题还是环境的问题。

5.3 导入工程后满屏红叉，编译提示找不到编译器

现象：按 4.1 的流程导入别人的工程，代码里一堆波浪线，编译报错说指定的编译器版本不可用。

原因：工程里的.cproject文件写死了作者机器上的编译器版本号，你的机器上没装那个版本。这不是工程坏了，是环境差异。

解决：右键工程 →Properties→General，把Compiler version下拉框改成你本机tools\compiler下已有的版本，确定后Project → Clean再Build。如果改完还有零星报错，多半是该版本对某些语法或内建函数的支持有差异，逐个看报错位置改，别一上来就怀疑人生。长期做法是把团队统一用的编译器版本号写进项目文档，新机器装的时候直接勾那个版本。

5.4 中文注释乱码，或者编译报 No rule to make target

现象：打开源文件中文注释全乱；或者编译时 console 里刷出一行No rule to make target，指向一个看起来完全正常的源文件。

原因：乱码是编码不统一，工程是 GBK、IDE 按 UTF-8 解，或者反过来。No rule to make target十有八九是路径问题——工程路径、包含路径、链接命令文件路径里混进了空格或者中文，make 把一条路径拆成了两段。

解决：编码问题按 3.4 节统一成一种，整体另存，不要混用。路径问题就老实把工程挪到纯英文无空格的目录，包含路径全部改成工程变量加相对路径。还有一种情况是文件确实被删了但工程里还留着引用，去工程属性的源文件列表里把失效条目删掉即可。

5.5 启动极慢，调试卡在加载 GEL 文件

现象：双击图标到出现界面要等好几分钟，点 Debug 之后卡在某个初始化步骤长时间不动。

原因：工作区里的.metadata膨胀了，历史工程、断点、搜索索引全堆在里面；或者启动时自动加载了多个目标配置和 GEL 初始化脚本，每个都要去连一遍硬件；再或者安装目录和工程目录都被实时扫描盯着，每个文件访问都要过一遍。

解决：先给工作区分盘，一个版本一个工作区，老工程该归档就归档出当前工作区；再走Window → Preferences把不用的自动加载项关掉，调试时只保留当前工程的.ccxml；最后把安装目录、工作区目录、工程目录一起加进杀毒软件的排除列表。这三步做完，冷启动时间通常能压到原来的几分之一。

6. 调试链路的验证与进阶：断点、寄存器与 Memory Browser 的实战技法

环境装好、工程导入、编译通过，很多人到这一步就以为完事了，其实还差最后一环：证明「代码真的跑在板子上」。我习惯用一段最小的验证代码走完整条链路，跑通了再往里塞业务逻辑，出问题的时候才能快速定位是环境坏了还是代码坏了。

/* 链路验证用：变量全部 volatile，防止被优化掉后断点对不上 */ volatile unsigned int g_step = 0; int main(void) { unsigned int i; g_step = 1; /* 断点打这一行，命中说明下载成功 */ for (i = 0; i < 1000; i++) { g_step = i & 0x0F; /* 单步时看 g_step 递变，确认没跑飞 */ } g_step = 0xAA; /* 跑到这里说明循环正常结束 */ while (1) { } return 0; }

这段代码的每一处都是为调试服务的。volatile是关键，没有它，开了优化之后编译器会把g_step放进寄存器甚至直接消掉，你在观察窗口里看到的永远是 0，然后开始怀疑下载是不是没成功。断点打在g_step = 1那一行，能命中就说明工程、目标配置、仿真器、板子这条链全通了；在循环里单步几次，看g_step按i & 0x0F递增，说明变量观察窗口是活的；最后跑到g_step = 0xAA，说明流程控制正常。

验证通过之后，调试的几个窗口值得挨个打开熟悉一遍：View → Variables看局部变量，View → Registers看内核寄存器，View → Expressions手动加观察表达式（右键变量选Add Watch Expression也能加），View → Disassembly看汇编和源码的对应关系，View → Memory Browser按地址看内存，View → Breakpoints统一管理断点。两个我养成的习惯：一是断点不要一次打十几个，打到第三个就开始乱了，宁可分成几轮调试；二是怀疑变量值不对的时候先去看Disassembly，确认源码行和实际指令对得上，对不上就是优化等级的问题，回去把优化关掉重新编译。

提示：Memory Browser里按地址查内存时，注意区分数据空间和程序空间，地址填错看到的是另一片区域，读出来的值当然对不上，别急着判定内存坏了。

从那以后我每次装完这类老版本 IDE，都会强制走一遍「最小验证代码 → 断点命中 → 变量符合预期」这条链，跑通了才开始导入真正的工程。这个习惯救过我很多次——环境有问题的时候，一段二十行的代码比一个几千行的工程好排查太多。这份 CCS5 安装教程连同样例工程和这份验证清单一起放在资源包里，按第 2 章的路径规则和第 5 章的五条记录对一遍再动手，能少走不少弯路。希望帮到你。

本文还有配套的精品资源，点击获取