[参考译文] CC2340R5：CC2340 ROM 引导加载程序擦除范围

您好！

从技术参考手册(TRM)"8.5.3.5 BLDR_CMD_CHIP_ERASE"部分、似乎可以指定要在引导加载程序擦除中保留的某些闪存扇区：

然后、  可以使用 BLDR_CMD_DOWNLOAD 和 BLDR_CMD_SEND_DATA 来更新相关的闪存扇区。

由于  BLDR_CMD_CHIP_ERASE 一直 擦除 CCFG、因此该扇区应在每次 BLDR_CMD_CHIP_ERASE 之后更新、并确保指定下一次芯片擦除时应保护的闪存扇区。 通常、CCFG 始终与固件映像配对、因此不应视为额外成本。

Unknown 说：

可以先通过 UniFlash 导出重要参数、但这会非常麻烦。 如果该公司的产品目前需要更新数万个单元,那么不可能每个单元都先使用 UniFlash 导出重要参数,这将是非常低效的。

请注意、UniFlash 可能使用 SACI、在这种情况下、请参阅 TRM 中的"8.2.4.2对先前编程的器件进行重新编程"部分。

谢谢。
托比

(1)有否实际操作的例子？

(2)您的意思是设置哪些 Flash 块不允许从 SYSCFG->Device Configuration"(设备配置)->Flash Protection Settings 进行擦除？

如果是、假设我希望 ROM 引导加载程序不擦除0x3E800至0x7FFFF、我该如何设置它？

(3)更新完成后、CCFG 将具有新值。 是否仍需要 BLDR_CMD_DOWNLOAD 和 BLDR_CMD_SEND_DATA 来更新 CCFG？

您好、Ryan、

感谢您的进一步调查。

我会更深入地了解这一点、并在3个工作日内提供更新。

谢谢。
托比

Unknown 说：

(1)有否实际操作的例子？

[/报价]

它将类似于：

1. CC2340R5空白器件
2. 设计 FW、如果包含某些具有不应写入/擦除的信息的闪存段、请将其称为 FLASH_SECT_PROT
3. CC2340R5加载了 FW 和 CCFG、用于指定 FLASH_SECT_PROT
4. 从2修改可执行固件。
5. 输入 ROM SBL
6. 发送  BLDR_CMD_CHIP_ERASE (现在 CCFG 和非受保护闪存扇区已被擦除)
7. 发送 bldr_cmd_download_crc 以指定固件加载的启动位置、固件的大小(请注意、这一定不能触摸 FLASH_sect_PROT)以及其预期的 CRC
8.  将固件映像的实际字节发送到 BLDR_CMD_SEND_DATA
9. 准备具有与3中所使用的相同写入/擦除位的 CCFG
10. 发送 BLDR_CMD_DOWNLOAD_CRC 命令、作为输入来传递 startAddress=(0x4E020000)、length=(2048)、crc=(calc_crc (ccfg_contents))
11. 发送 BLDR_CMD_SEND_DATA 以发送 CCFG 的字节
12. 这些步骤成功完成后、复位将允许器件执行新的固件(从4开始)、同时保持最初以2加载的不变数据

Unknown 说：

(2)您是想设置哪些闪存块不允许从 SYSCFG->Device Configuration->Flash Protection Settings 擦除吗？

如果是、假设我想让 ROM 引导加载程序不擦除0x3E800至0x7FFFF、我该如何设置它？

是的。

要写入/擦除保护范围 0x3E800至0x7FFFF、首先确定与之相交的闪存扇区。 在本例中、它将是扇区125 - 256。

这是通过  writeEraseProt.mainSectors32_255 = 0x0FFFF800 (位11 - 27设置的、根据 TRM、这将保护扇区120-255或地址范围0x3C000 - 0x80000。 这是因为每个位保护8个连续扇区(位11 保护扇区120 - 127、位27 保护扇区248 - 255 ->位11-27保护扇区120 - 255)。 在 SysConfig 中、这指的是"主要扇区32-255"。

Unknown 说：

(3)更新完成后，CCFG 将具有新值。 是否仍需要 BLDR_CMD_DOWNLOAD 和 BLDR_CMD_SEND_DATA 来更新 CCFG？

是的、由于 CCFG 一直被擦除、它必须由 ROM SBL 重新载入(使用适当的保护位被设定)。

[/quote]

我按您所说的方式对其进行了设置、但当我使用 ROM 引导加载程序对其进行更新时、未保留任何数据。
这意味着第120个扇区之后的所有数据都已在更新后擦除。

我将其更改为0xF0000FFF 并进行测试、发现它确实实现了保护效果。 但是、这也会导致一个问题、即 CC2340无法在执行期间擦除和写入此块。 我需要的是 CC2340正在执行。 将数据写入闪存、但使用 ROM 引导加载程序进行更新时、执行期间存储在 CC2340中的数据无法擦除。

这意味着在开始时在 SYSCFG 中设置受保护扇区后,我无法擦除/写入,甚至无法擦除 NVS_WRITE ()/ NVS_ERASE ()。

或者它应该被设置为"擦除/保留、主扇区32-255 "？ 因为我看过了它的描述，所以它使用 SC_FLASH_ERASE_CHIP 来擦除

但我在 TRM 文件中找不到任何有关 SC_FLASH_ERASE_CHIP 的相关信息。

Unknown 说：

我将其更改为0xF0000FFF 并进行了测试，发现它确实实现了保护效果。

是的，你在这里是正确的--我错了。 一个"0"位启用写入/擦除保护。

Unknown 说：

然而，这也引起了一个问题，即 CC2340无法在执行期间擦除和写入此块。 我需要的是 CC2340正在执行。 将把数据写入闪存、但使用 ROM 引导加载程序进行更新时、执行期间存储在 CC2340中的数据无法擦除。

是的、这是预期效果。  

Unknown 说：

或者它实际上应该被设置为"Erase/retain, Main Sectors 32-255"? 因为我看过了它的描述，所以它使用 SC_FLASH_ERASE_CHIP 来擦除

但我在 TRM 文件中找不到有关 SC_FLASH_ERASE_CHIP 的任何相关信息。

我认为他们把"SC"器件简单交给了... 全部应为"SACI 命令"(安全 AP 命令接口)。
这是指支持的 SACI 命令(在 TRM 的"8.3器件管理命令接口"一节中)。

对于 SACI_CMD_FLASH_ ERASE_CHIP、可以使用"擦除/保留、主扇区32-255"。 如果 SACI_CMD_FLASH_ ERASE_CHIP 命令也传递了可选参数"retainSelMainSectors"、则这将生效。

感谢您的回复

这意味着可以保留 CC2340在执行期间写入的数据、并且可以通过使用 SACI_CMD_FLASH_ERASE_CHIP 来保护写入数据的扇区范围吗？ 如果是、在 SYSCFG 设置完成后、进入 ROM 引导加载程序模式并在 CC2340上执行 SACI_CMD_FLASH_ERASE_CHIP 命令？

是的、如果使用 SACI、则应起作用(在允许应用程序修改内容的同时保留闪存扇区)。

在这种情况下、它不是 ROM 引导加载程序、而是 SACI (与 ROM 引导加载程序在加载/擦除闪存内容方面类似、但不同的是它使用 SWD 引脚而不是串行 UART/SPI 引脚)。

那么、SACI 的操作过程是否与 ROM 引导加载程序的操作过程相同？ 首先、在 SYSCFG 中设置触发引脚、然后复位以让 CC2340进入 ROM 引导加载程序模式、然后将 SACI_CMD_FLASH_ERASE_CHIP 设置为擦除 CC2340。

希望有详细的步骤、谢谢

在 TRM 中、请参阅"8.3器件管理命令接口"部分。

我已检查 TRM 8.3、SACI 似乎无法下载更新文件、因此无法满足我的预期目标。

 "8.2.4.2对先前编程的器件进行重新编程"一节显示了使用 SACI 更新固件的顺序。

这是否达到了您的预期目标？

SACI 似乎是我当前正在使用的刻录模式、通过 SWCLK、SWDIO、Vcc、GND、 复位
我希望能够通过 ROM 引导加载程序等 UART 引脚进行更新、因为该产品将来只能通过 UART 进行通信。

我尝试了一种方法、在 SYSCFG 中设置保护扇区范围、然后在代码中使用 NVS_UNLOCK ()在必要的时间解除对闪存的保护、以便 CC2340可以在执行期间向闪存写入数据、但当前的测试似乎不成功、这是一种可能的方法吗？

如果没有办法,我希望我的建议可以传达给发展部门

我将对此进行深入探讨、并 在3个工作日内与您联系。

好，谢谢

Unknown 说：

我尝试了一种方法，在 SYSCFG 中设置保护扇区范围，然后使用代码中的 NVS_UNLOCK ()在必要的时间取消保护闪存，以便 CC2340可以在执行期间向闪存写入数据，但当前测试似乎不成功，这是一种可能的方法吗？

NVS_UNLOCK (和 NVS_LOCK)为闪存写入实施互斥量、因此这不会防止它被芯片擦除。

Unknown 说：

并且我希望能够通过 UART 引脚(如 ROM 引导加载程序)进行更新，因为该产品将来只能通过 UART 进行通信

如果最终产品仅提供 UART、则说明操作正确、不能使用 SACI。 此外、无法使用 ROM 引导加载程序、因为任何闪存保护也会阻止将来写入闪存(例如应用数据)。

还有另一个选项用于创建自定义引导加载程序、TRM 部分"8.4.3用户定义引导加载程序指南"中详细介绍了相关指南。

这样、在器件启动时可以进入自定义引导加载程序、并且该引导加载程序可以使用闪存 API 来保留想要执行擦除的特定扇区(例如 NVSLPF3_ERASE -> doErase)。

对于 CC2340R5、SACI 和 ROM 引导加载程序均不支持扇区擦除、但仅支持前文所述的写/擦除保护。

(1)谢谢、我理解

(2)除了 TRM "8.4.3用户定义的引导加载程序指南"部分中的说明外、是否有任何用户定义的引导加载程序示例项目？

您好、Ryan、

您是否知道 mcuboot 项目？  它与 OAD 项目一起使用、并可作为自定义引导加载程序开发的起点。

此致、
瑞安

(1)我以前曾尝试使用此项目、但无法成功跳转到应用程序地址。 您能否提供有关如何使该过程成功跳转到应用地址并正常运行的指导？

(2) mcuboot 只能与 OAD 项目一起开发吗？ 因为我只想使用 UART 进行更新、所以不需要使用无线方法。 如果我使用 basic_ble、可以使用 mcuboot 来开发此项目吗？

据我所知、TI 并未公开其 ROM 串行引导加载程序源解决方案。  尽管您的最终目标不是利用 OAD、但使用可用 TI 资源的最佳开发路径是评估 based_ble_oad_onchip 项目。  这样、您就可以进一步利用 CCS 调试器 ( 也提供了 BLE5-Stack 调试指南)来了解 mcuboot 项目如何在器件上电时启动、然后跳转到 based_ble 应用程序。  之后、您可以从 BLE 项目中删除 OAD 部分并将 UART 功能添加到 mcuboot 中。  作为一个开源项目、您也许能够从在线搜索中找到其他启用了 mcuboot UART 的资源、这些资源有可能被移植到 CC2340R5器件。

此致、
瑞安

TI 是否会考虑在将来向 CC2340 ROM 引导加载程序添加一个命令、以便用户确定擦除范围？