TI 德州仪器 开发指南

编制日期 2026-10-14

MSP430 / C2000 / Sitara / CC 四大系列 —— 一份把「选错调试器」「SysConfig 改了不生效」「RAM 初始化漏了一段」这些坑全部前置的工程手册

结论：TI 的四大系列共用一套 Code Composer Studio，却分属四条完全不同的工程链路。 最容易踩的坑不在代码，而在选错调试器（XDS110 / XDS200 的官方「不支持器件」列表里MSP430 在列）、 搞不清 SysConfig 生成的代码与手写代码谁覆盖谁、以及C2000 与 CC26xx 的 Flash 编程行为。 本文按「选型 → 环境 → 配置 → 下载 → 调试 → 外设 → 硬件 → 量产」的真实流水线组织，每一节都给出可对照的表格、可复制的命令、以及该环节最常踩的坑。

报告总结

TI 的资料体系是全行业最规范的之一 —— 每颗芯片都有数据手册（DS）讲电气与引脚、技术参考手册（TRM）讲寄存器、用户指南（UM）讲模块用法、应用报告（APP）讲设计取舍，而且全部免费公开。但官方文档回答的是「这个模块怎么工作」，不回答下面这三类问题：

• 四个系列之间的关系：MSP430 的 FRAM、C2000 的 CLA、Sitara 的 R5F、CC26xx 的 SCE 分别是为什么存在的？为什么一个做电表的公司会同时做实时控制和无线？
• 同一件事在不同系列怎么做：同样是「让一个引脚每 1 ms 翻转一次」，四系列的答案完全不同，而且官方不会并排给你。
• 工具链的真实边界：哪些器件能用 XDS110、哪些必须 MSP-FET、SysConfig 生成的 ti_xxx_config.c 能不能手改、UniFlash 的命令行参数怎么写 —— 这些散落在几十份文档和 E2E 论坛里。

本文档做了三件官方分散资料没做的事：把四条链路并排摆齐、把坑写在坑发生的那一章、把来源标到文档编号级别。

读者路径

本文档共 20 章 + 4 个附录，按「先跑通、再理解」的顺序组织：

• 只想尽快跑通第一个程序：第 4 章（装 CCS）→ 第 5 章（建工程点灯）→ 第 7 章（下载）→ 第 20 章（核查清单），四章足够。
• 正在做选型：第 2 章（四大系列全景 + 决策路径）→ 第 3 章（内核差异）。这一章能省掉一次错误的料号采购。
• 要调 C2000 电机控制：第 2.3 节 → 第 11 章（时钟与上电）→ 第 13 章（ePWM / HRPWM）→ 第 14 章（ADC / CMPSS）。
• 要做低功耗电池产品：第 16 章。注意 MSP430 的「LPM4.5 唤醒 = 复位」这件事。
• 做 Sub-GHz 或 BLE：第 15 章（射频与协议栈）+ 第 17.7 节（RF 走线与天线净空）。
• 从 STM32 切过来：第 18 章是专门的移植对照，先看这一章能省两三天。
• 调不通、报错：直接翻第 19 章，按现象分层定位。

1 · 文档导读与阅读路径

这一章说明本文档的边界：覆盖什么、不覆盖什么，以及为什么把内容按「流水线」而不是按「功能模块」组织。

1.1 覆盖范围

本文档覆盖从「确定用哪颗 TI 芯片」，到「固件跑起来、能断点停下、能量产烧录」的完整链路，四大系列各自独立成路径：

• 选型与内核：MSP430 的 16 位 RISC 与 FRAM 统一内存、C2000 的 C28x + CLA 双核、Sitara 的 A53/R5F/M4F 异构、CC13xx/CC26xx 的 M4F + M0 双核与 SCE 传感器引擎（见第 2、3 章）。
• 开发环境：CCS v20（Theia 框架）、SysConfig 的 .syscfg 元数据机制、各系列 SDK 的分工与版本对应关系（见第 4、6 章）。
• 构建：linker command file 的 MEMORY 配置、CMD 语法、启动代码、命令行 gmake、代码体积与 RAM 预算（见第 6 章）。
• 下载与量产：XDS110 / XDS200 / MSP-FET 的能力边界、UniFlash 的图形与命令行、MSP430 BSL、C2000 ROM 与外设引导、CC26xx 的 Serial Flash 与 CCFG、并发烧录（见第 7 章）。
• 调试：CCS Debug 配置、SysConfig 运行时视图、断点行为、实时 trace、Graph 工具，以及 Flash 编程的全片擦除特性（见第 8 章）。
• 外设：GPIO / 外部中断 / 中断控制器 / 时钟复位电源 / UART / SPI / I2C / ADC / DMA / 定时器 / PWM / RTC / 看门狗，以及 C2000 的模拟与控制专用外设（见第 9~14 章）。
• 射频与低功耗：CC13xx/CC26xx 的协议栈、频段、PA 与板级约束；MSP430 / C2000 / CC26xx / Sitara 四套低功耗机制（见第 15、16 章）。
• 硬件与移植：电源分区、去耦、上电时序、多电源约束、复位、晶振、调试口布线、RF 走线；以及从 STM32 / 8051 迁移的改动清单（见第 17、18 章）。

1.2 不覆盖什么

以下内容超出本文档范围，需要时请查阅对应官方资料：

• 寄存器位域全集：C2000 的 TRM 接近 3000 页，MSP430 与 CC13xx 的 TRM 也有数百页。本文只在需要解释「为什么会这样」的层面给出寄存器组名，具体位域请对照 TRM 核一遍。
• 控制算法本身：FOC、PI 整定、无感观测器、InstaSPIN-FOC 的数学推导属于电机控制理论。本文只覆盖它们所依赖的外设资源、同步时序与调试接口。
• Linux / RTOS 内核移植与驱动开发：Sitara AM62x/AM64x 的 Processor SDK Linux、Yocto、BSP 与设备树属于嵌入式 Linux 的独立体系。本文只讲它与 MCU 侧的接口（FSI、GPMC、PRU-ICSSG）和启动链概念。
• 无线协议栈源码级细节：BLE 协议栈的 GATT 数据库、TI 15.4-Stack 的网络层与 MAC、Thread / Zigbee 的堆栈移植，属于各自 SDK 文档的范围。本文只讲选型、频段、功耗预算与板级约束。
• 每一款封装的完整管脚定义：本文只给最常用封装的关键引脚（调试、自举、电源、RF），完整管脚表请查对应 DS。
• 认证与合规的完整流程：SRRC / CE / FCC 的测试与认证流程由第三方实验室执行，本文只在 15.6 节列出「设计阶段就要考虑的分区与净空约束」。

1.3 型号命名约定

TI 的型号命名比多数厂商规整，看懂名字基本就能知道内核、主频档次与 Flash 容量。以四个系列的代表型号为例：

1.4 事实来源与免责

本文档所有数值型信息来自 TI 官方公开资料，正文中会就近标注出处。版本敏感的东西（IDE 版本、SDK 版本、下载入口）请以 ti.com 当日页面为准。

2 · 四大系列全景与选型

TI 是极少数同时做「最省电的 MCU」和「最复杂的实时控制器」的公司，而且它们之间几乎没有重叠。理解这一点，选型就简单了。

2.1 一句话认识 TI 的嵌入式四条线

很多工程师对 TI 的印象停留在「做 DSP 和模拟芯片的公司」。实际上 TI 的嵌入式产品线有四条，各自解决完全不同的问题，彼此几乎不重叠：

把四个系列的共同点也列清楚 —— 这决定了它们能共用哪些工具：

• 同一个 IDE：Code Composer Studio 从 CCS 7 到 v20 一直支持全部四条线（Energia 从 CCS 20 起不再支持，那是 Arduino 侧的独立产品）。
• 同一套配置工具：SysConfig 对四个系列都用「.syscfg 元数据 + 生成 C 代码」的同一套机制，只是生成的文件名和内容不同。
• 同一套仿真器家族：XDS110 / XDS200 / XDS560 在多个系列之间通用 —— 但有明确的不支持列表，见 7.1 节。
• 同一个烧写工具：UniFlash 同时覆盖这四条线的芯片（对 AMx 器件只支持命令行）。
• 同一条资源站：TI Resource Explorer 把文档、例程、SDK、Board 文件按器件树组织。

2.2 MSP430：超低功耗 16 位 RISC

MSP430 的设计目标只有一个：在最小的能耗下完成最多的工作。为了达成这个目标，它做了几个与主流 MCU 相反的选择：

• 16 位 RISC 而不是 32 位：寄存器少、取指周期短、译码简单，单位能耗下的有效吞吐更高。
• FRAM 与 RAM 统一编址：这是 MSP430 最独特的一点。以 MSP430FR5994 为例，256 KB FRAM 与 8 KB SRAM 在同一个地址空间里， 指针可以指向任何一处，写 FRAM 就像写 RAM 一样快（约 125 ns / 字），而且写入前不需要擦除。这直接带来两个工程优势：代码可以把自己改写（OTA 的基础），以及所有「变量」都能掉电保持而不用自己搬进 Flash。
• 把模拟外设做到与数字同级：12 位 ADC 带采样时间控制与窗口比较器、多通道比较器、内部基准、可编程增益 —— 这些在当年的 MCU 上是罕见的。
• LEA（低能耗加速器，FR599x 独有）：一颗独立于 CPU 的小型信号处理引擎，可以做 FFT / FIR / 矩阵运算而不唤醒 CPU。官方给的对比是「在 256 点复数 FFT 上比 Cortex-M0+ 快到 40 倍」。它只与 4 KB SRAM 共享。

MSP430 的低功耗数字同样有官方来源。以 FR5994 产品页给出的典型值为准：活动态约 118 μA/MHz、LPM3（VLO 时钟）500 nA、LPM3.5（RTC 由 3.7 pF 晶体驱动）350 nA、LPM4.5 关断 45 nA。 这四个数字背后的机制在第 16 章展开，这里先记住一条结论：MSP430 的低功耗不是靠「关外设」，而是靠 CPU 本身进低功耗模式 + 内存保持策略。

2.3 C2000：实时控制专用 C28x

C2000 的存在理由是：一般的 MCU 无法在确定性的时刻把 ADC 结果送到 PWM 输出。C2000 用一整套专用硬件解决这个问题，这就是它与其它 MCU 最大的分野。

• C28x 32 位流水内核：定点与单精度浮点混合流水线，带硬件乘法与专门的三角函数单元 TMU，在 200 MHz 下的等效实时信号链性能可达数百 eMHz 量级（TI 官方用 eMHz 这个自定义指标做横向对比）。
• CLA（Control Law Accelerator，控制律加速器）：一颗与 C28x 并行运行的 32 位浮点内核，专门跑控制律。典型分工是「C28x 跑通信与外设、CLA 跑电流环」，两个核的代码可以同时执行。这是 C2000 算力翻倍的根本原因。
• ADC 与 ePWM 的硬件同步：ADC 在 PWM 载波中点触发采样（ePWM 可以直接触发 ADC 的 SOC），采样结果再由 ADC 的 EOC（转换结束）直接触发 ePWM 更新。整条链路没有一个 CPU 指令参与，抖动只有纳秒级。
• CMPSS → Trip-Zone 硬件保护：比较器输出一旦越过上下限，直接硬件封锁 PWM 输出，不经过 CPU、不经过软件。这是「安全相关」设计的底座。
• CLC（Configurable Logic Block）：片内可编程的逻辑阵列，用外���逻辑（与、或、异或、移位、查表）代替一部分「用 GPIO 互连的逻辑」。它同时也是接绝对值编码器（EnDat / BiSS / SSI）的主流方式。

C2000 的型号谱系有一个必须理解的事实：TI 用「eMHz（等效 MHz）」这个自定义指标做跨内核横向对比， 定义为「达到同样实时信号链性能所需的 Cortex-M7 级设备主频」。厂商对比表里的数字全部是这个口径， 不要拿它和 Cortex-M 系列的真实主频直接比。真实的 C28x 主频写在 DS 里：F2837xD / F2838xD 是 200 MHz，F2807x 是 120 MHz，F28004x 是 100 MHz，F28002x 是 100 MHz，F28003x 是 120 MHz。

2.4 Sitara：AM 系列应用处理器与 Sitara MCU

Sitara 在近几年的产品布局上分成了两条路，容易混淆：AM62x 是 MPU（跑 Linux，做应用处理与人机界面）， AM64x / AM243x 是 MCU（跑 RTOS/裸机，做硬实时 + 工业通信）。两条路都叫 Sitara，但选型逻辑完全不同。

Sitara 的技术特色有三点值得在做架构决策时纳入考虑：

• 可配置 SRAM 分区 = 硬件级的域隔离：内部 SRAM 可以切成不同大小的块分配给不同核。 这让「Linux 应用」与「实时控制」在内存层面就是隔离的，一侧失控不会踩到另一侧 —— 这对功能安全设计非常关键（AM64x 明确把 Linux 应用与实时流之间的隔离列为架构能力）。
• PRU-ICSSG：可编程实时单元，能实现 EtherCAT、PROFINET、Ethernet/IP、IO-Link 等工业协议，以及 Σ-Δ 抽取滤波器和绝对值编码器接口。AM64x 用两个实例加上 CPSW3G，最多支持 5 个千兆以太网口。
• FSI（Fast Serial Interface）：与 C2000 直连的高速串行接口。AM64x/AM243x 的实时核做控制环、C2000 做功率级驱动，中间用 FSI 走，是 TI 主推的「双芯片伺服」架构。

另外注意 Pin-to-Pin 与封装兼容性：TI 在 Sitara 家族内做了跨型号的引脚兼容设计（同一封装下从 AM62x 到 AM64x 尽量保持一致）， 这意味着产品规划时可以在同一块 PCB 上跨越性能档位，不必为每个档位重画板子。具体兼容范围请查对应系列的 Software Build Sheet。

2.5 CC13xx / CC26xx：SimpleLink 无线

SimpleLink 无线 MCU 的架构创新点是三核分工，理解它就理解了这一系列所有的低功耗特性：

这个架构带来的直接结果是：协议栈、应用逻辑、射频、传感四件事可以分别在不同的时间点进出低功耗状态， 而不是被绑在一起整体睡眠或整体唤醒。这正是「1 μA 级长期待机 + 仍能保持无线连接」这个看似矛盾的组合得以实现的原因。

关于频段的具体范围，官方在 CC1352P7 的产品描述中给得很明确：Sub-1 GHz 部分覆盖 287–351 MHz、359–527 MHz、861–1054 MHz、1076–1315 MHz 四个子段；2.4 GHz 部分覆盖 2360–2500 MHz。 中国可用频段（SRRC）主要落在 470–510 MHz 与 902–928 MHz 区间，选型时务必对照目标市场的频段规划确定子型号。

2.6 跨系列选型对照

把四个系列放在同一张表上对比，是做立项评审时最有效的一步。这张表的每一行都是「你在设计评审会上会被问到的问题」：

这张表里最容易被忽视、也最容易造成返工的是最后三行：启动复杂度、调试器、量产烧录。 很多项目在实验室里跑通了，掉到产线上才发现「调试器选错了」或者「烧录口没引出来」，代价极高。立项时把这三项和功能需求一起定，比功能本身更值得花时间。

2.7 软件生态：CCS / SysConfig / SDK 的分工

TI 的软件栈可以拆成四层。搞清这四层的边界，就知道遇到问题该去查哪一层：

关于 SDK 之间的层级关系，有几条实用经验：

• C2000 的库是分层的：C2000Ware 是底座（DriverLib + 位域字段定义 + 启动代码 + 链接文件 + 例程）， C2000Ware MotorControlWare SDK 叠在它上面（电机控制算法 + DigitalPower + 实时控制库）， C2000Ware DigitalPower SDK 是数字电源的专用栈。三个 SDK 的版本必须互相对应， 混用会出现「位域字段定义与 DriverLib 不匹配」的编译或运行问题。
• Sitara 与 CC26xx 走的是两条不同的栈：AM62x / AM64x 用 Processor SDK（Linux 侧用 Processor SDK Linux + Yocto，MCU 侧用 MCU+ SDK）； CC26xx 用 SimpleLink CC13x2/26x2 SDK。两者不通用，但都在 SysConfig 里配置。
• SysConfig 不是必需的：你可以完全手写寄存器配置代码。但一旦用了 SysConfig， 它生成的文件会在每次构建时被覆盖 —— 这是本文档里第 6.2 节要重点讲的一个坑。
• TI Resource Explorer 是找例程最快的地方：比在 SDK 里翻目录树快得多，而且它按「板子 + 用例」组织， 很多例程直接就是你手上那块 LaunchPad 的板级配置。

2.8 选型决策路径

把上面这些收敛成六个问题的决策树，从上往下问，命中即停：

来源：各产品 Description 页与系列 DS/TRM

补充五条不成文经验：

• 先定调试器，再定芯片。MSP430 不支持 XDS110/XDS200；MSP-FET 又不能调 C2000。选芯片之前先确认你能拿到对应的探针。
• 同系列内优先选 Flash / SRAM 更大那档。TI 同一型号系列常有 4~6 个 Flash 档位，差价很小，后期发现不够用的成本远高于差价。
• C2000 一定要用 controlCARD 或 LaunchPad 起手，不要从自制最小系统板开始 —— C2000 的电源域数量与上电时序要求比想象中复杂（见 17.3 节）。
• 无线产品的第一步不是写代码，是读两份文档：对应型号的 DS（含 RF 电气参数）与 TI 的 CC13xx/CC26xx Hardware Configuration and PCB Design Considerations。射频部分的返工成本是全项目最高的。
• 功能安全项目从一开始就要看对系列。C2000 的 F28P65x 带锁步与 ASIL-B/SIL-2 使能，CC 系列有安全启动与安全固件更新；如果项目将来要做认证，选型时就要按认证需求选，而不是等认证阶段再换。

3 · 内核与架构差异

四个系列的差异，第一层在内核。但真正决定「能不能移植」的不是内核本身，而是它带来的地址空间模型与中断模型。这一章把这两件事讲透。

3.1 MSP430：16 位 RISC 与冯·诺依曼

MSP430 的指令集是 16 位 RISC，寄存器宽度也是 16 位。它的架构有三个特点，每一个都能在代码里直接观察到：

• 单总线冯·诺依曼：指令和数据走同一根总线。这意味着「取指时不能同时访存」—— 但也意味着硬件极其简单、面积小、功耗低。典型表现是：add @r4, r5 这类单字指令在时钟上升沿完成，而某些需要两次访存的双字指令耗时更长。
• 寄存器少：只有 R0~R15，其中 R0（SP）、R1（SR）、R2（PC）、R3（CG2）固定用途，R12~R15 是 Scratch 寄存器。好处是上下文切换只需保存 PC + SR + 少量寄存器；代价是编译器要频繁把变量搬到栈上，代码密度不如 8/32 位机。
• 统一地址空间：MSP430FR 系列最独特的一点 —— FRAM 与 RAM 在同一个 16 位地址空间里。地址 0x0000 以上是 FRAM，顶部 0xFFxx 附近是信息区（TLV / 校准值），没有「写 Flash 前要擦除」这回事。

3.2 MSP430 的「天然低功耗」从哪来

很多资料说「MSP430 天生低功耗」，但没说清机制。实际上是四条机制叠加的结果：

3.3 C28x：32 位定点浮点流水与 CLA

C28x 是 TI 自研的 32 位 DSP 内核，不是 Arm 也不是 RISC-V。它的定位非常明确：为实时信号链而生。理解它的三个设计取舍：

• 修正哈佛结构：程序空间与数据空间在物理上分立，通过页寄存器切换。这意味着指令与数据可以并行访问，这是它能在同样时钟下跑出比通用 MCU 更高「每周期有效吞吐」的原因。代价是：指针不能随便跨空间解引用，跨空间的调用要显式处理。
• 32 位定点为主 + 单精度浮点加速：控制算法里绝大多数工作是定点乘加（电流环、PI、Clarke/Park 变换）。C28x 对定点做了深度优化，同时提供浮点 FPU 与 TMU（三角数学单元） 加速 sin/cos/atan2 —— 因为这三个函数在电机控制里调用频率极高。
• CLA 作为第二内核：CLA 是一颗独立的 32 位浮点处理器，与 C28x 并行执行。这是 C2000 算力「翻倍」的来源。典型的分工方式：CLA 跑电流环（要求确定性延迟），C28x 跑通信、调度、后台任务（要求吞吐量）。

关于 CLA 有一个非常容易踩的坑：CLA 不是自动启动的。芯片复位后 CLA 处于不运行状态， 必须由 C28x 侧的初始化代码显式配置（分配它的内存、设置它的向量、使能它的时钟），CLA 才会开始执行第一条指令。 C2000Ware 的 device_init() 里包含了这一步，但如果你自己写启动代码或者裁剪了初始化流程，CLA 就「不响应中断」。 这个现象的表现是「控制回路完全没有输出」，但 C28x 侧的通信一切正常。

3.4 Arm：Cortex-A9 / M4 / M33

Sitara 与 CC 系列都用 Arm 内核，但三者的定位完全不同，混着理解会得出错误的性能预期：

AM64x 里 Cortex-M4F 被设计成「功能安全监控器」，官方明确说明它有「freedom from interference」的独立性 —— 可以跑安全相关任务而不被实时核干扰。这一点在做功能安全设计时非常关键：它不是「顺便带的」一颗小核，而是安全架构的一部分， 配套的专用外设（I2C / SPI / UART / GPIO）也可以被隔离出来单独使用。

3.5 地址空间与内存映射差异

这是移植时最容易出致命问题的地方。四种模型，四套完全不同的假设：

3.6 架构差异带来的移植影响

把上面这些汇总成一张「改动清单」，可以拿它对照评估一个移植项目的工作量：

三个实用结论：

• CC26xx 是最容易迁的 —— Cortex-M4F + NVIC + 常规外设，基本就是「换个头文件」。如果你手上是一个 Cortex-M 项目想上 TI，CC 系列是阻力最小的落点。
• MSP430 的迁移成本被低估 —— 它是 16 位，所有指针、所有地址计算、所有结构体在内存里的布局都要重新审视。特别是「把结构体指针强转成整数」这类写法，会因为指针宽度变化而静默出错。
• C2000 的迁移本质是「重写」 —— 但如果目标本来就是电机控制，那 C2000 的 SDK 与算法库能省掉大量算法工作，实际净收益可能是正的。关键在于判断你的代码里「控制部分」有多少。

4 · 开发环境：CCS 与 SysConfig

四个系列共用一套 IDE。这一章讲清 CCS v20 现在的样子、SysConfig 到底做了什么，以及安装阶段最容易坏在哪里。

4.1 Code Composer Studio v20（Theia 版）

从 CCS 20 开始，TI 把 IDE 从 Eclipse 迁到了 Theia IDE 框架（与 VS Code 同源），操作习惯与 Eclipse 版有明显差异。这一点对老用户尤其重要：网上大量教程是 Eclipse 版 CCS 的截图与操作步骤，直接照做会找不到菜单。

CCS 里几个值得知道的视图：

• SysConfig 面板：工程里带 .syscfg 时自动出现，改配置后会自动触发生成（见 6.2 节）。
• Graph 视图：CCS 内置的数据绘图工具，支持实时刷新曲线、FFT、直方图。调试 C2000 的控制量时它比 printf 有用得多（见 8.4 节）。
• Memory Browser / Registers 视图：直接看内存与寄存器，MSP430 上尤其好用（因为 FRAM 就是内存，你能直接看到「改一个字」的效果）。
• Scripting Console：CCS 20 之后增强了脚本控制台，可以用 JS/MJS 操作工程、构建与调试，适合写自动化脚本。

4.2 SysConfig：把配置变成可版本管理的代码

SysConfig 是 TI 现在统一推荐的配置方式，理解它的机制比记住每个字段更重要 —— 因为字段会随版本变，机制不会。

1. 你编辑的是一个文本文件 .syscfg：里面是「哪个外设的哪一路接到哪个引脚」「时钟源与分频」这类声明，不是二进制、也不是 GUI 状态。
2. 构建时 SysConfig 读它并生成 C 代码：不同系列生成的文件不同（见下表），但性质一样 —— 它们是产物。
3. 你的主程序调用生成的初始化函数：通常是一个总入口函数，调用它即可完成时钟、引脚、外设的初始化。
4. 改配置的正确流程：改 .syscfg（或在 CCS 的 SysConfig 面板里改，它写回 .syscfg），不要改生成的 .c/.h。

4.3 各系列 SDK 与它们的关系

SDK 是「除了 IDE 之外你还要装的东西」。四个系列的 SDK 互不通用，各自需要单独勾选安装。它们的定位与内容：

关于 C2000 的「三个 SDK 必须版本对应」，展开说：DriverLib 与位域字段定义只在 C2000Ware 里， MotorControlWare 与 DigitalPowerWare 依赖它。如果你在 MotorControlWare 里引用了新版才有的 DriverLib 函数， 而编译时链接到的是旧版 C2000Ware，就会出现「头文件有声明、链接时找不到符号」。
反查办法：TI 在 Edge AI Studio 与 C2000 SDK 的 release notes 里会给出一张「SDK / Compiler 版本 ↔ 支持器件」的对照表， 动手前先查这张表，比在论坛里问有效得多。

4.4 安装步骤与目录规划

安装本身不复杂，但目录规划值得花两分钟想一想：

1. 装 CCS：从 ti.com/tool/download/CCSTUDIO 下离线单文件安装包。安装路径建议纯英文、无空格（虽然 Theia 版对路径的要求比以前宽松，但中文路径在部分工具链的脚本里仍可能出问题）。
2. 在安装器里勾选你要的 SDK：这一步决定 CCS 认识哪些器件。四个系列的 SDK 可以只勾你需要的 —— 全勾会显著增加安装时间与磁盘占用。
3. 装 SysConfig：建议装独立版并在工程中指定它，这样它可以脱离 CCS 单独跑（命令行构建时很有用，见 6.6 节）。
4. 装仿真器驱动：XDS 与 MSP-FET 的驱动由 CCS 安装器一并装上；UniFlash 单独安装。
5. 装额外的命令行工具：SmartRF Studio（CC 系列射频配置）、Sensor Controller Studio（SCE 代码生成）、以及各系列的 Flash 编程工具。
6. 做一次「空工程」验证：新建一个最简单的工程，编译通过、下载成功、断点停在 main()。这一步做完再开始做正式项目，否则出问题时分不清是环境还是代码。

4.5 组件配置与工程创建

CCS v20 里创建工程的方式有两条，选择合适的能省很多事：

建工程时几个值得确认的选项：

• 器件型号要与实物一致：TI 的同系列产品型号极多（如 C2000 的 F28379D / F28379S / F28379E），选错型号会导致固件引脚定义与硬件完全不符，现象是「下载成功但没有任何反应」。
• 编译器的选择：C2000 用 TI 自己的 C28x 编译器（对应 C28-CLA Compiler 版本）；Arm 核用 TI Arm Clang 或 GCC；MSP430 用 TI 的 MSP430 编译器。不要随意换编译器，SDK 里的部分代码依赖编译器特有行为。
• 输出格式：除了 .out（含调试信息，用于烧录与调试），如果你要用 BSL / 外设引导烧录，需要额外生成对应格式的镜像文件（见 7.6、7.7 节）。
• 是否生成 SysConfig 工程：新建工程时选带 SysConfig 的模板，以后再想加回来需要手工补不少东西。

4.6 常见安装故障

把安装阶段最常遇到的五个问题按「现象 → 原因 → 处置」列出。这一节的价值在于：这几种情况占了安装失败的大多数。

5 · 第一个工程：从新建到点亮 LED

这一章的目标很具体：用最短路径让一个 LED 闪起来。三个系列各给一条，每条都以「跑通官方例程 → 改成自己的」为路径。

5.1 三条路径的最小工程概览

先说清为什么强烈建议从例程改而不是从空白开始：

三条路径的共同步骤是：

1. 确认硬件：目标板（LaunchPad / controlCARD / 自制板）与调试器都到位，且调试器接的是正确的口（C2000 controlCARD 有两个口：JTAG 与 USB 虚拟串口，别插错）。
2. 导入例程并原样编译：不改一行代码，先确认工具链完整。这一步失败说明是环境问题，不是代码问题。
3. 原样下载并验证现象：看到例程预期的输出（LED 闪烁 / 串口打印 / GPIO 翻转）。
4. 再做最小改动：只改一个地方（比如换一个 GPIO），重新编译下载验证。
5. 然后才逐块替换成自己的模块。

5.2 MSP430 路径：LaunchPad + CCS

MSP430 的入门资料极其丰富（MSP430Ware 里有大量 blink 例程），这条路径最不容易卡住。

1. 装 MSP430Ware（在 CCS 安装器里勾选），装完重开 CCS。
2. 导入例程：File → Import → CCS Projects，选 MSP430Ware 里对应芯片系列的 blinky / empty 例程。芯片系列名与目录名对应关系：FR59xx、FR60x、G2xx3、L2xx3 等。
3. 确认器件型号与 LaunchPad 对应：MSP430 LaunchPad 型号（如 MSP-EXP430FR5994）自带 板载调试器，多数情况下不需要外接探针，插 USB 就能调试。
4. 编译：Project → Build Project。产出 Debug/<工程名>.out。
5. 下载与调试：点 Debug 按钮，CCS 会自动连接板载调试器、加载符号、停在 main()。
6. 验证：Run（F8 / Resume），LED 应该按例程设定的频率闪烁。

MSP430 侧的最小代码（示意结构，具体 API 名以所用 DriverLib 版本为准）：

/* 时钟与 GPIO 由 SysConfig 或 DriverLib 初始化完成后，进入主循环 */
#include "ti_msp_dl_config.h"

int main(void)
{
    SYSCFG_DL_init();      /* 关键一步：SysConfig 生成的初始化总入口 */

    while (1)
    {
        /* 翻转 LED 对应引脚，具体宏名以 SysConfig 里配置的引脚名为准 */
        DL_GPIO_togglePins(GPIO_LEDS, GPIO_LEDS_USER_LED_1_PIN);

        /* 简单的软件延时。用定时器更好，这里为了最小化依赖先这样写。
           注意：这个延时的精度依赖主频，改了时钟就要跟着改。 */
        delay_cycles(CLOCK_FREQ / 2);   /* 约 0.5 秒，具体见 6.7 节关于预算的讨论 */
    }
}

5.3 C2000 路径：controlCARD + C2000Ware 例程

C2000 的起步比 MSP430 复杂一档，主要复杂在初始化流程与多核，但只要用好官方例程反而更稳（因为 C2000Ware 的例程质量非常高，而且带自检）。

1. 装 C2000Ware（以及你要用的 MotorControlWare / DigitalPowerWare），装完重开 CCS。
2. 确认 controlCARD 的拨码开关：这是 C2000 特有的步骤 —— controlCARD 背面有 SW1 / SW2 / SW3 一组拨码开关与跳线，它们决定目标芯片的启动模式（Flash / RAM / 仿真调试）与时钟源选择。装反了的现象是「能识别到芯片但下载失败」或「下载成功但跑的是 RAM 里的东西」。具体设置查该 controlCARD 的用户手册。
3. 导入例程：C2000Ware 里 driverlib/ 目录下按外设分了很多 *_ex 例程（如 gpio_ex_、epwm_ex_、adc_ex_），选 gpio_ex_ 最简单。
4. 编译：C2000 工程的编译产物是 Debug/<工程名>.out，同时会生成 .hex 与 map 文件。
5. 下载：用 XDS110 或 XDS200 接 controlCARD 的 JTAG 口。注意用 JTAG 口，不是 USB 口（controlCARD 的 USB 是虚拟串口与 XDS110 的 USB 通道，用它只能串口烧录不能 JTAG 调试）。
6. 验证：导入的例程会让某个 GPIO 翻转，用示波器或逻辑分析仪看，或者把引脚接到 LED。
7. 加一步：跑自检。C2000Ware 提供 Device Self-Test，能在上电时检查 RAM、Flash、ADC、CLA、TMU 等模块是否正常。把这个加进你的第一个工程，是排除「硅片本身有问题」最有效的手段。

C2000 最小主循环的骨架（结构示意，具体函数名以所用 SDK 版本为准）：

#include "board.h"          /* SysConfig 生成的 Board 定义 */
#include "driverlib.h"

int main(void)
{
    Device_Init();          /* 唯一且必须的初始化入口：时钟、GPIO、CLA、RAM 初始化全在里面 */

    SysCtl_delay(100);      /* 给外设留一点稳定时间，具体数值查本系列的 AC 指标 */

    /* 之后才是你的业务代码。注意别把耗时逻辑放进需要确定周期的位置 */
    for (;;)
    {
        GPIO_togglePin(GPIO_PIN_??);   /* 换成 board.h 里你的引脚宏 */
        SysCtl_delay(1000);
    }
}

5.4 CC26xx 路径：LaunchPad + SDK 例程

CC26xx 的 LaunchPad 体验是四个系列里最好的之一：板载 XDS110 + 板载天线 + 板载传感器 + 按钮直接连调试器，插一根 USB 线就完事。

1. 装 SimpleLink SDK（CC13x2/26x2 SDK）与 Sensor Controller Studio。
2. 确认 LaunchPad 的拨码 / 跳线：与 C2000 类似，LaunchPad 上也有拨码开关，决定是否用板载 XDS110 与目标电压档位。CC 系列 LaunchPad 上通常有「XDS110 选择」与「3V3 / 5V 供电」相关的跳线。
3. 导入例程：SDK 里 examples/rtos/<板子名>/ 目录下有大量例程。最简单的起点是 empty（空工程）或 pinstandby（引脚待机测试）。建议先跑 empty 确认工具链，再跑一个协议栈例程（如 ble5stack 下的例程）。
4. 编译：注意 如果你用了 SCE（传感器控制器），必须先在 Sensor Controller Studio 里生成并编译 SCE 侧代码，否则主工程链接会缺符号。TI 的做法是主工程的 pre-build 步骤里调用 SCE 的构建脚本。
5. 下载：CCS 里点 Debug，板载 XDS110 自动被识别。不需要外接探针。
6. 验证：CC26xx 的 LaunchPad 上有个特别的坑 —— 很多例程上电就进低功耗（这是它的正常行为），所以 LED 可能不亮、调试器看起来「连上了但跑不动」。

5.5 点不亮时的分层排查

「下载成功但现象不对」是最高频的问题。按下面的分层顺序查，每层只做一件事，不要跳：

最后一条经验：当 L1~L7 全部排除后，不要继续调代码，直接换硬件判断。 用一块确认过能工作的同型号板子（或者官方 LaunchPad）做 A/B 对比，能在十分钟内区分「是代码问题还是板子问题」， 比再读三小时代码有效得多。