6 关键陷阱

1. 引导顺序所有权：

   CPU1 始终是主核心，必须先启动。CPU1 控制 CPU2 的复位并负责所有系统初始化（PLL、时钟、看门狗）。不能直接将 CCS 连接到 CPU2 cold - CPU1 必须正在运行并已经将 CPU2 从复位状态释放。

2. CCS 中的加载顺序很重要：

   首先连接并加载 CPU1，运行足够远的位置以初始化系统和引导 CPU2（或至少将 CPU2 从复位中释放），然后连接并加载 CPU2。如果在 CPU1 初始化系统时钟之前加载 CPU2，则将获得不稳定的行为。

3. 单独的 CCS 项目：

   双核应用程序是两个完全独立的映像（输出文件）。它们仅通过共享存储器和 IPC 进行链接 — 没有单个“双核工程”。（除非使用第 5 节中的编译后处理步骤）

4. 内存所有权/访问权限：

   共享 RAM 块具有所有权分配 — 如果 CPU1 拥有 GS RAM 块，CPU2 将遇到尝试写入它的存储器访问违规。CPU1 和 CPU2 的链接器命令文件 (.cmd) 必须仔细协调，以免重叠，且共享部分必须使用专用的 IPC/MSG RAM 区域或正确拥有的 GS RAM。

5. 停止一个内核会影响另外一个内核：

   当您将 CPU1 暂停在断点处时，CPU2 会继续运行，除非您也明确停止它（或在 CCS 中使用同步组）。如果暂停的内核是预期响应的内核，则正在运行的内核上的 IPC 标志轮询循环可能会无限期旋转。这是双核调试期间令人困惑的行为的最常见来源。

6. 全局断点/同步组：

   CCS 支持对内核进行分组，因此一个断点同时停止两个内核。对于 IPC 重代码，这几乎总是您想要的 — 否则，正在运行的核心竞争将会消耗 IPC 消息，并且状态将在您查看时变得不一致。

7. 看门狗：

   每个内核都有自己的看门狗。如果您暂停 CPU1 以进行调试，但 CPU2 仍在运行并为共享外设提供服务，或者相反，未监视内核的看门狗可能会触发并使器件复位。在调试构建的早期禁用看门狗。

8. 闪存与 RAM：

   在闪存构建中，两个内核共享闪存控制器，并且在同一流水线阶段从两个内核进行并发闪存读取可能会导致停滞。在调试期间，大多数团队都从 RAM 中工作以避免这种情况，并能够在没有擦除周期的情况下快速重新加载。闪存编程需要协调两个内核（CPU1 通常会初始化所有闪存）。

9. IPC 竞态条件：

   基于 IPC 标志的协议本质上为异步。常见错误：CPU1 设置标志，然后立即将数据写入共享缓冲区，但 CPU2 在 CPU1 完成写入之前读取缓冲区。仅在数据写入完成后使用 IPC 标志来指示信号，并在需要时使用存储器屏障（C28x 上的 __asm(" RPT #7 || NOP")）。

10. CLA 是第三个可调试内核：

    在存在 CLA 的器件上，该 CLA 在 CCS 中显示为单独的调试目标。从 CPU2 .out 加载 CLA 符号（它们是一起编译的）。CLA 没有 RTOS，没有栈，并且调试可见性非常有限 — 您可分步查看寄存器，但没有调用栈。

11. 异构调试（F2838x CM 内核）：

ARM CM 内核使用完全不同的工具链。在 CCS 中，它显示为单独的 ARM Cortex-M4 目标。您需要一个 ARM 编译器工程与 C28x 工程一起使用。CM 内核无法直接访问 C28x 本地 RAM — 所有数据交换都要通过 MSG RAM 进行。