1. 项目概述：深入理解TMS320F28003x的DCSM安全模块

在嵌入式系统开发，尤其是工业控制、汽车电子和高端消费电子领域，代码和数据的保护已经从一个“加分项”变成了“必选项”。想象一下，你投入数月甚至数年心血研发的电机控制算法、电池管理逻辑或通信协议，如果因为一颗芯片被轻易破解而泄露，那将是毁灭性的。德州仪器（TI）的C2000系列微控制器，特别是TMS320F28003x，其内置的双代码安全模块，正是为了解决这类核心痛点而生。

DCSM不是一个简单的“开关”，而是一套精密、分层的硬件安全体系。它的核心思想是分区隔离和密码学保护。简单来说，它允许你将芯片的Flash和RAM资源划分为两个独立的安全区域（Zone1和Zone2），并为每个区域设置独立的128位密码。代码在某个区域内运行时，只能访问本区域或被授权访问的资源，无法越界读取或修改另一个安全区域的内容。这就像在一栋大楼里设置了两个独立的保险库，各自有独立的密码和门禁，A库的管理员无法进入B库。

对于开发者而言，理解DCSM不仅仅是知道如何设置一个密码。它关乎整个产品生命周期的安全策略：在开发阶段，如何安全地进行仿真调试而不触发保护？在生产阶段，如何烧录密码并锁定芯片，防止密码泄露？在现场应用中，如何确保核心算法不被提取，同时又能进行必要的固件更新？本次分享，我将结合手册内容和实际项目经验，为你拆解DCSM的密码保护、仿真调试安全（ECSL）、安全启动等关键机制，并提供从理论到实操的完整指南，帮你避开那些手册里没写但实际开发中一定会遇到的“坑”。

2. DCSM核心安全机制深度解析

DCSM的安全并非铁板一块，而是由多个相互协作的逻辑单元构成，针对不同的攻击面提供了针对性的防护。理解这些机制是进行有效安全配置的前提。

2.1 代码安全模块与密码匹配流程

CSM是DCSM的基石，它通过一个128位的密码来保护一个安全区域（Zone）内的所有存储器资源（Flash和RAM）。其工作流程，即密码匹配流程，是理解一切安全操作的关键。

PMF的本质是一个“挑战-响应”过程，但完全由硬件自动完成验证。当你尝试通过调试器（如JTAG）或运行在非安全内存中的代码去访问一个安全区域时，硬件会拦截该访问并要求验证。验证过程不是简单的“输入密码-比较”，而是必须遵循一个严格的序列：

1. 四次虚读：首先，必须对存储在OTP中的四个32位密码位置（ZxOTP_CSMPSWD0-ZxOTP_CSMPSWD3）进行一次连续的读取操作。注意，这里的“读”是“虚读”（Dummy Read），意思是你的代码需要发起这个读操作，但读回的数据会被硬件内部捕获用于比较，你的程序可能并不关心读回的值。这个步骤的目的是将OTP中正确的密码加载到硬件内部的比较电路中。
2. 四次密钥写入：紧接着，必须向对应的四个CSMKEY寄存器（Zx_CSMKEY0-Zx_CSMKEY3）依次写入你希望验证的128位密码。
3. 硬件比对与状态切换：硬件自动比较写入CSMKEY的值与之前从OTP中加载的值。如果完全匹配，则该安全区域被解锁（Zx_CR.UNSECURE位被置1），后续对该区域内存的访问将被允许。如果不匹配，区域保持锁定状态，任何非法访问尝试都会导致总线错误或调试连接断开。

这里有一个至关重要的细节：密码的锁定。在开发初期，OTP中的密码位置是可读的（默认PSWDLOCK字段为0xF）。这意味着任何人（包括调试器）都能直接读出密码明文，此时CSM形同虚设。因此，在产品发布前，必须编程PSWDLOCK字段为非0xF值（如0x0），将密码位置本身也保护起来。一旦锁定，即使你知道密码，也无法再从任何地方读取密码原文，只能通过上述PMF流程来验证密码，安全性大大增强。

实操心得：很多团队在开发后期才想起设置密码和锁定，这非常危险。我的建议是，在项目早期就确定好密码管理策略（例如，使用真随机数生成器生成，并安全存储），并在第一次向样机烧录完整固件时，就一并完成密码的OTP编程和PSWDLOCK的锁定。永远不要在PSWDLOCK未锁定的状态下将产品交付给客户或进行现场测试。

2.2 仿真代码安全逻辑：调试时的“安全沙箱”

ECSL是CSM的一个延伸，专门针对仿真调试场景。它的存在解决了一个矛盾：我们既希望保护代码，又需要在开发时能进行单步调试、设置断点。如果没有ECSL，一旦程序指针（PC）停在安全代码区域，调试器试图读取CPU寄存器或内存内容时，就会触发CSM保护，导致调试会话强制断开，体验极差。

ECSL的机制很巧妙：它为每个区域额外设置了一个64位密码（取自CSM 128位密码的低64位或高64位，具体取决于实现）。当你需要调试安全代码时，可以先通过一个简化的PMF（针对ECSL）来解锁ECSL。解锁后，CSM的保护依然生效，即你仍然无法通过调试器读取安全内存的内容，但ECSL被禁用，允许调试器在安全代码中安全地暂停、查看寄存器（除PC外的大部分寄存器访问仍受CPUSL限制，见下文）、继续执行，而不会断开连接。

这相当于在调试器和安全代码之间建立了一个“安全通道”。调试器可以控制程序流，但“看”不到安全区域内的具体数据。要完全“看到”内容，仍需通过完整的CSM PMF解锁整个区域。在实际开发中，特别是与第三方协作时，你可以只提供ECSL密码，让合作伙伴能够联调他们的模块，而无需暴露核心算法的机器码。

2.3 CPU安全逻辑：寄存器级的最后防线

CPUSL是更深一层的保护，它直接作用于CPU内核。当PC指向安全内存地址时，CPUSL会阻止通过调试器（如CCS的Watch窗口）读取大多数CPU寄存器的值。这是为了防止攻击者通过观察寄存器中的数据变化来推断算法细节或密钥信息。

手册中特别提到一个例外：程序计数器PC本身是可以读取的。这是为了维持基本的调试功能。但同时手册也给出了强烈警告：不要在PC指向安全区域时，尝试向CPU寄存器写入数据。因为这种写入操作可能会干扰CPU的正常执行流水线或状态，导致不可预知的程序行为甚至崩溃。当CSM通过PMF被解锁后，CPUSL也会随之被禁用。

2.4 JTAGLOCK：彻底关闭物理调试接口

如果说CSM/ECSL是“软件锁”，那么JTAGLOCK就是“物理焊死”。对于最终产品，我们可能希望完全杜绝通过JTAG接口进行调试或读取的可能性，以应对物理攻击。JTAGLOCK功能一旦启用，JTAG端口将完全失效，直到输入正确的128位JTAG密码。

启用JTAGLOCK是一个不可逆或需极端谨慎的操作，因为它分为两步：

1. 编程JTAG密码：将128位密码写入Z1 OTP的特定位置（JTAGPSWDH在OTP头，JTAGPSWDL在Z1区域选择块）。JTAGPSWDH通常只烧写一次，而JTAGPSWDL可以多次更改，这提供了密码轮换的灵活性。
2. 使能JLM模块：通过编程Z1OTP_JLM_ENABLE寄存器的低4位为非0xF值（推荐写0x0）来激活JTAG锁。

启用后，任何通过JTAG的连接尝试都会要求输入密码。TI的Code Composer Studio内置了工具来处理JTAG解锁流程。务必在启用前，确保密码已安全备份，并且你拥有可靠的、不依赖JTAG的固件更新��案，例如通过引导加载程序进行串口或CAN更新。

2.5 链接指针与区域选择块：安全配置的“导航图”

这是DCSM架构中非常精妙且容易出错的部分。每个安全区域（Zone1和Zone2）的详细安全配置（如密码、内存分配、EXEONLY设置等）并不直接存放在固定的OTP地址，而是存储在一个叫做区域选择块的数据结构中。那么，CPU如何知道这个块在哪里呢？答案就是链接指针。

每个区域有三个14位的链接指针（ZxOTP_LINKPOINTER1/2/3），它们被编程在OTP的固定位置。硬件在上电初始化时，会读取这三个指针的值，通过一个“位投票”逻辑来解析出一个最终的链接指针值。这个解析逻辑的关键在于OTP的特性：位只能从1编程为0，不能从0擦除回1。硬件会从最高位开始扫描解析后的指针值，找到第一个为0的位，这个位的位置决定了区域选择块的基地址。

为什么需要三个指针？因为链接指针所在的OTP位置没有ECC保护。为了防止因OTP位翻转导致安全配置完全丢失或错乱，采用了三模冗余的“投票”机制，只要三个值中有两个相同，就能得出正确值，极大提高了可靠性。

如果解析出的位模式不合法，或者三个指针全为1（未编程状态），硬件会使用一个默认的区域选择块地址。这个设计给了开发者灵活性：你可以在产品生命周期后期，通过编程新的区域选择块并更新链接指针来修改安全配置（例如调整内存分配），而旧的配置块由于OTP的“0”位无法变回“1”，依然存在但会被新指针指向的新块所覆盖。

注意事项：编程链接指针和区域选择块是OTP操作，一旦写入无法更改。务必在开发后期，所有安全策略都经过充分测试和评审后再进行。错误的指针值可能导致整个区域的安全配置无法被正确加载，从而“锁死”该区域。强烈建议在编程前，先在RAM中仿真整个安全初始化流程，验证链接指针计算逻辑是否正确。

3. 安全初始化与资源访问控制实战

理解了核心机制后，我们来看DCSM如何在上电时建立安全环境，以及如何管理安全资源的访问。

3.1 上电复位后的安全初始化序列

芯片每次复位（除某些特定类型外）后，在用户代码运行前，BootROM会执行一个至关重要的安全初始化序列。这个序列本质上是一系列对OTP中关键地址的“虚读”操作。其目的有两个：一是将OTP中的安全配置（密码、内存分配位、EXEONLY位等）加载到对应的影子寄存器中；二是根据链接指针计算出区域选择块的实际地址。

手册中列出了详细的读取序列，从读取TI OTP的SECDEC寄存器，到读取两个区域各自的链接指针、通用寄存器、密码锁、CRC锁、JTAG密码高位等。这个序列的顺序是固定的，且必须由硬件（BootROM）完成。用户应用程序不应也不能尝试重复或修改此序列。

这里有一个极其重要的陷阱：如果你在调试时，在CCS中打开了一个指向USER OTP地址范围的内存观察窗口，然后进行了复位操作，BootROM的安全初始化可能会因为这个调试器的“窥探”而被打乱顺序，导致安全配置加载错误，最坏的情况是永久锁定芯片。因此，在进行任何涉及安全配置的调试时，务必关闭所有对OTP地址空间的直接内存观察窗口。

3.2 Flash与OTP的安全编程与擦除

Flash和OTP本身也是受保护的安全资源。对它们进行编程或擦除操作，必须满足以下条件之一：

1. 你已通过PMF解锁了该资源所属的安全区域。
2. 你正在从同一安全区域内的安全内存中执行Flash编程/擦除代码。

这意味着，你不能从Zone1去擦写属于Zone2的Flash扇区，除非Zone2已被解锁。这强化了分区隔离。

对于OTP，有一个更严格的限制：OTP内容不可擦除。每个位只能从1写成0一次。这要求你对安全配置的编程必须一步到位，或者采用“从后往前”的策略，即先使用默认区域选择块，后期再编程新的选择块和链接指针来覆盖旧配置。

此外，DCSM提供了一个信号量机制（FLSEM寄存器）来协调两个区域对共享Flash资源的操作。当一个区域要执行Flash擦写时，它需要“获取”这个信号量。这防止了Zone1和Zone2同时尝试编程同一个物理Flash bank可能导致的冲突或数据损坏。

3.3 安全复制与安全CRC：针对EXEONLY内存的特殊操作

EXEONLY（仅执行）是最高级别的保护模式。被标记为EXEONLY的内存，只能被CPU取指执行，任何数据读取操作（包括DMA）都会被禁止。这有效防止了通过内存转储来提取代码。

但这带来了两个实际需求：

1. 性能优化：我们可能希望将关键代码从较慢的Flash复制到更快的RAM中执行。
2. 完整性校验：在功能安全或高可靠性应用中，我们需要对EXEONLY区域的代码计算CRC，以确保其没有被篡改。

由于EXEONLY区域禁止读取，普通的memcpy或CRC计算引擎都无法工作。为此，TI在BootROM中提供了安全复制和安全CRC的库函数。这些函数运行在一个高度特权的安全上下文中，能够绕过EXEONLY限制，但仅在严格条件下工作：源和目标必须属于同一个安全区域，且都必须启用EXEONLY保护。调用这些函数前，必须禁用所有中断，因为如果在安全函数执行期间发生中断向量获取，CPU会立即复位。

3.4 将安全机制集成到用户应用中的策略

安全不是事后添加的功能，而应贯穿开发始终。一个典型的集成流程如下：

1. 开发与调试阶段：初期不设置密码，或使用一个已知的调试密码，并保持PSWDLOCK为解锁状态（0xF）。利用ECSL功能来调试安全区域的代码。此时重点验证功能逻辑。
2. 内部测试与验证阶段：生成正式的128位密码，并将其编程到OTP的密码位置。此时先不要锁定PSWDLOCK。使用这个密码进行CSM解锁，测试所有需要访问安全资源的场景（如Flash编程工具、引导加载程序等）。确保密码匹配流程工作正常。
3. 预发布/量产阶段：在所有功能和安全测试通过后，进行最终的OTP编程。这包括：
   • 编程最终的、正式的区域选择块（包含内存分配、EXEONLY设置等）。
   • 编程链接指针，指向新的区域选择块。
   • 编程PSWDLOCK字段为非0xF值，锁定密码。
   • （可选）如果需要，编程并启用JTAGLOCK。
   • 务必确保同时编程正确的ECC值。OTP受ECC保护，编程时遗漏ECC或ECC错误会导致该OTP位置读取失败，可能使设备永久锁定。
4. 现场部署：设备以安全状态出厂。用户正常使用无需密码。如需现场更新，可通过安全的引导加载程序（其本身可能运行在安全内存中）来验证新固件签名并执行更新，或者通过调试接口在提供正确密码后进行更新。

4. 核心安全操作代码示例与避坑指南

理论需要实践来巩固。下面结合代码示例，讲解关键操作和常见陷阱。

4.1 解锁与重新锁定安全区域

解锁Zone1的CSM，即执行完整的PMF。注意密码在OTP和代码中的存储顺序��可能涉及大小端）。

// 假设使用默认区域选择块地址，密码为 0x11112222333344445555666677778888 volatile unsigned long *CSM_KEY_REG = (volatile unsigned long *)0x5F090; // Z1_CSMKEY0 地址 volatile unsigned long *CSM_PWL_LOC = (volatile unsigned long *)0x78020; // 默认Zone1密码位置起始地址 volatile unsigned long dummy_read; // 1. 四次虚读，激活硬件比较器 for(int i=0; i<4; i++) { dummy_read = *CSM_PWL_LOC++; } // 2. 四次写入，提供密钥。注意32位写入顺序和密码的字节序。 *CSM_KEY_REG++ = 0x22221111; // 写入 CSMPSWD0 (假设OTP中存储为 0x11112222) *CSM_KEY_REG++ = 0x44443333; // 写入 CSMPSWD1 *CSM_KEY_REG++ = 0x66665555; // 写入 CSMPSWD2 *CSM_KEY_REG++ = 0x88887777; // 写入 CSMPSWD3 // 写入后，硬件自动比较。可通过读取 Z1_CR.UNSECURE 位来确认是否解锁成功。

重新锁定Zone1则简单得多，只需设置控制寄存器中的FORCESEC位。

volatile unsigned int *Z1_CR = (volatile unsigned int *)0x5F019; // Z1_CR 地址 *Z1_CR |= 0x80000000; // 设置 FORCESEC 位 (bit 31)

避坑指南：

• 顺序绝对重要：必须先虚读，再写入。反序或中间插入其他操作会导致失败。
• 地址对齐：确保对CSMKEY寄存器的写入是32位对齐的访问。
• 验证状态：在关键的安全操作后，总是读取Zx_CR寄存器中的UNSECURE、ALLZERO、ALLONE等状态位来确认操作结果。ALLZERO为1表示密码全0，设备永久锁定（灾难状态，需避免）。ALLONE为1表示密码全1，等同于未设置密码。
• 中断与上下文：执行PMF的代码最好在关闭中断的环境下进行，并且确保这段代码本身不会位于即将被解锁的安全区域内（否则会先触发访问违规）。

4.2 禁用ECSL以允许安全代码调试

如果你只需要调试而不需要读取安全代码，禁用ECSL即可。它使用CSM密码的低64位。

// 禁用Zone1的ECSL volatile unsigned long *ECSL_KEY_REG = (volatile unsigned long *)0x5F090; // 同样指向Z1_CSMKEY0 volatile unsigned long *ECSL_PWL_LOC = (volatile unsigned long *)0x78028; // 假设ECSL密码在PWL+2起始 volatile unsigned long dummy_read; // 读取64位ECSL密码（两次虚读） for(int i=0; i<2; i++) { dummy_read = *ECSL_PWL_LOC++; } // 写入低64位密码到CSMKEY0和CSMKEY1 *ECSL_KEY_REG++ = 0x22221111; // 对应密码低32位 *ECSL_KEY_REG++ = 0x44443333; // 对应密码高32位 // CSMKEY2和CSMKEY3 对于ECSL解锁无关，可以不写

4.3 链接指针解析与区域选择块定位

下面的C代码示例演示了如何根据Z1_LINKPOINTER寄存器的值，计算出当前生效的区域选择块地址。这个过程模拟了硬件在安全初始化时的行为。

unsigned long LinkPointer; unsigned long *Zone1SelBlockPtr; int Bitpos = 13; // 链接指针是14位，从bit13开始检查 int ZeroFound = 0; // 读取解析后的链接指针值 LinkPointer = *(volatile unsigned long *)0x5F000; // Z1_LINKPOINTER 寄存器地址 // 指针值在寄存器的[13:0]位，将其左移到最高位方便检测 LinkPointer = LinkPointer << 18; // 32-14=18 while ((ZeroFound == 0) && (Bitpos >= 0)) { if ((LinkPointer & 0x80000000) == 0) { // 检查当前最高位是否为0 ZeroFound = 1; // 找到第一个0位，根据公式计算区域选择块地址 // 基址0x78000 + (Bitpos + 2) * 32 Zone1SelBlockPtr = (unsigned long *)(0x78000 + ((Bitpos + 2) * 32)); } else { Bitpos--; LinkPointer = LinkPointer << 1; // 左移检查下一位 } } if (ZeroFound == 0) { // 如果14位全为1（即0x3FFF），则使用默认块 Zone1SelBlockPtr = (unsigned long *)0x78020; // 默认Zone1选择块地址 } // 现在 Zone1SelBlockPtr 指向了有效的区域选择块 // 你可以通过这个指针访问 CSMPSWD0, GRABSECT1 等配置字段

关键点解析：

• 这个算法本质上是寻找14位链接指针值中从最高位开始的第一个0。
• (Bitpos + 2) * 32这个计算公式来源于硬件设计。每个区域选择块的大小是固定的，并且链接指针的位位置直接映射到OTP地址空间的偏移。
• 如果链接指针全为1（未编程或错误），则回退到默认地址0x78020。

4.4 常见问题与故障排查实录

在实际项目中，与DCSM相关的问题往往令人头疼。下面是我总结的一些典型场景和解决思路：

问题1：调试器连接后，一复位或运行程序就断开连接。

• 可能原因A：程序PC进入了安全代码区域，且ECSL未解锁。触发ECSL保护，调试连接被强制断开。
• 解决方案：使用Wait Boot Mode。在这种启动模式下，CPU核心会在BootROM中循环等待，不跳转到用户应用。此时你可以连接CCS，在main()入口处设置断点，然后再让程序运行。这样就能在程序进入安全区域前，有机会执行ECSL或CSM的解锁脚本。
• 可能原因B：安全初始化时，有调试器的内存窗口打开了OTP地址，导致初始化顺序错乱。
• 解决方案：关闭所有OTP地址范围（例如0x78000-0x783FF）的内存观察窗口，再进行复位。

问题2：使用Uniflash或CCS Flash编程器烧录失败，提示安全错误。

• 可能原因：目标Flash扇区属于某个安全区域，且该区域未被解锁。编程工具没有提供或未正确提供密码。
• 解决方案：在编程工具的配置中，找到安全设置（Security Setup）或密码输入栏，正确输入对应区域的128位密码。确保密码格式（如十六进制字符串、字节序）与工具要求一致。有些工具需要你先连接芯片，在脚本中执行PMF后才能编程。

问题3：产品批量烧录后，个别芯片无法连接或验证失败。

• 可能原因A：OTP编程时ECC错误。这是最严重的情况，可能导致安全配置无法加载，芯片变砖。
• 排查：检查烧录器是否支持并正确配置了OTP编程的ECC生成与烧写。TI的编程工具通常会自动处理。手动编程时需要格外小心。
• 可能原因B：链接指针编程错误，指向了无效或未编程的区域选择块地址。
• 排查：读取Zx_LINKPOINTER寄存器和Zx_LINKPOINTERERR寄存器。LINKPOINTERERR寄存器会指示在解析三个原始链接指针时哪些位出错了。如果错误太多，可能意味着OTP物理损坏。
• 可能原因C：密码不一致。生产过程中，烧录到OTP的密码与烧录工具/后续验证工具使用的密码不匹配。
• 解决方案：建立严格的密码管理流程。使用经认证的真随机数发生器生成密码，并安全地存储在离线环境中。烧录程序应直接从该安全存储中读取密码进行OTP编程，同时生成一个包含该密码哈希值的生产记录，供后续追溯，但绝不存储明文密码。

问题4：使能JTAGLOCK后，忘记了密码，如何恢复？

• 残酷的现实：如果JTAGLOCK被启用且密码丢失，没有任何官方方法可以恢复。JTAG端口将被永久锁定。这就是为什么启用JTAGLOCK必须极其慎重，且密码必须安全归档。
• 预防措施：
  1. 在启用JTAGLOCK前，务必在多个安全位置备份JTAG密码。
  2. 考虑使用“密码分片”策略，例如将密码分成几部分，由不同人员保管。
  3. 保留一小部分不启用JTAGLOCK的工程样机，用于极端情况下的故障分析。
  4. 确保产品具备不依赖JTAG的固件更新能力（如Bootloader）。

5. 安全开发流程建议与最佳实践

基于多年的项目经验，我总结了一套针对C2000 DCSM的安全开发流程，希望能帮助你系统性地规避风险。

第一阶段：架构设计与策略制定

• 划分安全区域：根据软件模块的敏感度和供应商来源，合理划分Zone1和Zone2。例如，将自研的核心控制算法放在Zone1，将第三方提供的通信栈放在Zone2。
• 制定内存分配方案：使用GRABSECTx和GRABRAMx配置位，明确每个Flash扇区和RAM块属于哪个区域。规划EXEONLY区域，将最核心的算法和密钥处理代码置于其中。
• 确定密码管理方案：如何生成、存储、传递和销毁CSM密码、JTAG密码。明确在开发、测试、量产各阶段使用的密码策略。

第二阶段：开发与模拟测试

• 使用仿真器：在早期，完全不编程OTP。利用CCS仿真功能测试代码逻辑。DCSM寄存器在仿真环境下是可读写的，可以模拟各种安全状态。
• 编写安全操作封装函数：将PMF、ECSL解锁、链接指针解析等操作封装成可靠的函数，并加入充分的状态检查和错误处理。
• 在RAM中测试OTP编程流程：虽然不能真正写OTP，但可以编写测试代码，模拟读取“虚拟”的OTP配置（存放在RAM的特定区域），并执行完整的安全初始化和资源访问测试。这能极大验证你的配置逻辑是否正确。

第三阶段：硬件调试与验证

• 逐步启用安全：先在芯片上不设密码运行，然后仅设置密码但不锁定PSWDLOCK，测试解锁功能。接着锁定PSWDLOCK，再次测试。最后再考虑启用EXEONLY和JTAGLOCK。
• 善用Wait Boot Mode：这是安全调试的“安全屋”。在任何不确定的情况下，先进入此模式连接调试器。
• 制作调试脚本：在CCS中编写GEL或JavaScript脚本，自动化执行ECSL/CSM解锁、读取安全状态等操作，提高调试效率。

第四阶段：量产与部署

• 生成生产烧录镜像：此镜像应包含最终的安全配置数据（链接指针、区域选择块内容）。确保烧录工具链能正确处理OTP和ECC。
• 首次烧录验证：对第一批次芯片进行烧录后，进行全面的功能和安全测试。包括：正常启动、调试接口连接（如需）、安全区域访问控制、JTAGLOCK功能（如启用）等。
• 建立废品处理流程：对于测试失败或返修的芯片，如果其已锁定，应有明确的流程进行识别和物理销毁，防止敏感信息泄露。

一个重要的提醒：DCSM是强大的硬件安全工具，但它不能解决所有安全问题。它主要防止通过调试接口和软件攻击进行的代码提取和篡改。对于旁路攻击、功耗分析等物理攻击，需要结合其他硬件安全特性（如时钟毛刺检测、内存加密等）和系统级设计来共同防御。务必仔细阅读TI官方文档中的安全免责声明，理解其安全边界，并在产品设计中建立纵深防御体系。