[参考译文] CC2340R5：如何在 CCFG 中为 MCUBoot 区域启用闪存保护

您好 Yao、

感谢您的联系。

如果您正在保护 MCUBoot 空间、那么设置为 0 的前 12 个扇区（从 0 到 11）应该能满足您的预期 — 在启用写入/擦除保护、CCFG ...

注意事项：

1. 您是否正在重新编译（清理并重新构建）并刷写 MCU？ 以确认编译后发生的更改。
2. 确保刷写后重启器件。
3. 还可能发生的情况是、当您刷写器件时、刷写过程会首先运行芯片擦除（包括 CCFG）、然后返回到原始状态。
4. 使用 JFlash 时、您是否还会计算 CCFG 的 CRC？ 查看： https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/latest/exports/docs/proprietary-rf/proprietary-rf-users-guide/memory/memory_management-cc23xx.html?highlight=flash#crc-tool。 如果忽略 CRC、则刷写时会忽略 CCFG 值。

修改 CCFG 设置时要格外小心、您可以做到 永久性砖砌 最大电流量。 确保这一点 允许芯片擦除 启用、从而允许器件在必要时进行擦除和重新编程、同时仍保护 MCUBoot 区域免受未经授权的部分写入。 参考链接： https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/latest/exports/docs/proprietary-rf/proprietary-rf-users-guide/sysconfig/device-configuration-cc23xx.html#flash-configurations-for-debug-and-production 

BR、

David

您好、David：

实际上、在我看来、这些 CCFG 设置有点棘手。
我们的要求是
1.protecting MCUBoot 区域不可写、用作信任根。
2.CCFG 应被锁定、否则保护功能毫无意义。
SWD 接口应在出厂时禁用。

首先、正如您所说的“前 12 个扇区（从 0 到 11）设置为 0“、即之前突出显示的“0xFFFFF000"。“。 正确吗？
如何通过 CCFG 设置满足 2 和 3 项要求？ 您能帮助给出具体的设置和测试方法吗？

此外、如果可能、我们还需要使用 2 级测试方法、
1.为了进行调试、可以验证 MCUBoot 保护、并且 CCFG 能够恢复为默认设置
2、对于生产测试、验证 MCUBoot 是否受保护、CCFG 是否被锁定、SWD 是否被锁定。 我们对最终产品进行了渗透测试,以满足 Cypber 安全性要求。

在下面回答您的问题。

您是否正在重新编译（清理并重新构建）并刷写 MCU？ 以确认编译后发生的更改。
--我用 SYSCFG 工具更改 CCFG ,重新编译 MCUBoot 示例并刷写 MCU。
我检查了 CCFG 二进制文件、位发生了变化。

确保刷写后重启器件。
——是的

还可能发生的情况是、当您刷写器件时、刷写过程会首先运行芯片擦除（包括 CCFG）、然后返回到原始状态。
如何避免这种情况? 如何验证保护是否正常工作？

使用 JFlash 时、您是否还会计算 CCFG 的 CRC？ 查看： software-dl.ti.com/.../memory_management-cc23xx.html。 如果忽略 CRC、则刷写时会忽略 CCFG 值
“我不知道 CRC 的内容。

谢谢
Yao

您好 Yao、

1. 0xFFFFF000 对于前 12 个扇区是正确的。
2. 我假设您已在 SYSCONFIG 部分中检查了 Write/Erase CCFG 是否正确？ 但它在图像中看起来未启用。
3. 也可以在 SysConfig 中禁用调试授权、请参阅 https://dev.ti.com/tirex/content/simplelink_lowpower_f3_sdk_9_14_01_16/docs/ble5stack/ble_user_guide/html/sysconfig/device-configuration-cc23xx.html?highlight=flash#flash-configurations-for-debug-and-production

在刷写过程中、探头可能会在刷写映像之前执行芯片擦除、例如： https://kb.segger.com/Program_without_erase

BR、

David