YTM32的flash应用答疑-详解写保护功能

Introduction

客户提出了一种应用场景：在使用某些授权软件（算法）的场景中，软件（算法）供应商向MCU的一些预留的存储区中写入专用的授权凭证，该凭证一机一码，各不相同，从而确保软件（算法）不会被非法复制。但对于MCU的应用开发者来说，经常需要刷写片内存储空间，更新程序或者数据，此时希望小心保存位于MCU内部存储器上的凭证，在开发和后期正常使用的过程中，不要被意外擦除，否则重新授权需要又需要额外的费用、时间和流程等。

绝大多数MCU的片内flash存储器管理模块都提供了写保护功能，当对已经设置保护功能的存储区进行擦写操作时，擦写的实际效果将失效，被保护存储区中的数据得以幸免留存，已达到防止误擦除的效果。

Principle

以YTM32B1MD14微控制器为例，其中片内flash控制器模块EFM，对应有EFM_ADDR_PROT[0]和EFM_ADDR_PROT[1]寄存器，其中每个比特可以保护8KB的存储区，按序分布，覆盖全部的片内flash的地址区域。

EFM_ADDR_PROT寄存器位的值为0时，写保护发生作用，对应位的值为1时，写保护不起作用，可以正常擦写。

有两种方式可以配置EFM_ADDR_PROT寄存器的值：

• 向CUS_NVR中0x10和0x18地址写数，这里的配置值将作为EFM_ADDR_PROT寄存器的初值，在硬件复位后自动生效（由boot rom复制到EFM_ADDR_PROT寄存器中）。但写入每个寄存器初值时要注意，高32位数必须为0x5A5A5A5A ，然后才是32位的有效配置值。
• 向EFM_ADDR_PROT寄存器直接写数，写数之后在程序运行过程中生效，但复位后受CUS_NVR中的初值影响，在软件生效之前，需要保护的区域可能有被篡改的风险。
  • 在软件中，从1写0是可以的，但从0写1是无效的。在程序运行中，只能上锁不能解锁。如果想重新操作，只能复位重来。

需要特别注意的是，CUS_NVR也是位于flash存储器上，具体是在pflash1的尾端。如图x所示。

图x CUS_NVR的物理存储位置

这里的EFM_ADDR_PROT保护的是地址空间，而不是物理存储。对于YTM32B1MD14这种用两个pflash物理存储器集成在一起具有硬件AB面分区的内部存储设备，若交换了物理存储区，切换了地址空间和实际物理存储器的映射关系，则原有的配置下实际执行保护的区域也会发生变化。实际上，CUS_NVR和BOOT SWAP操作的初始化参数共用的一个 Sector，因此在执行 BOOT_SWAP命令（交换pflash0和pflash1的地址映射区域） 后，关闭调试接口和地址保护的配置会丢失，需要重新配置。同理，擦除CUS_NVR后SWAP BOOT信息也会丢失，如需要重映射后的地址空间，需要重新执行BOOT SWAP操作。

另外，如果在flash块上对任意一块存储区启用了写保护，则整块flash存储器的块擦除操作都不能生效。但如果通过在CUS_NVR中解除写保护配置后复位，就可以恢复对整块flash的擦除操作。

Operation & Demonstration

设计用例，演示flash写保护的起作用的情况。

Demo #1 验证基本的写保护功能

• 默认上电复位后，MCU未对任何地址启用写保护功能。
• 先向0x3E000 - 0x40000（pflash0的最后一个8KB存储块）擦除后再写一组数据。通过调试器观察flash存储区的数据已经生效。

• 然后执行EFM_ADDR_PROT |= (1u << 31u)，配置写保护。
• 再试着擦除0x3E000 - 0x40000内存区间的数据。执行擦除操作之后，通过调试器观察flash存储区的数据是否仍留存。

通过实验可以观察到，当配置写保护后，再次试图擦除指定内存区域的存储空间后，原来写入的数据仍然保留，未受擦除操作影响。

Demo #2 编程CUS_NVR设定EFM_ADDR_PROT初值

在之前的用例中，可以看到在默认情况下，EFM_ADDR_PROT[0]和EFM_ADDR_PROT[1]寄存器的值都是0xFFFFFFFF。如图x所示。

图x EFM_ADDR_PROT寄存器的默认值

通过向CUS_NVR中0x10和0x18地址写数，更改写保护的初值。但此时，因为尚未复位，芯片硬件也没有执行从CUS_NVR向EFM_ADDR_PROT导入配置的操作，因此，仍然可以擦写 flash。如图x所示。

图x 在CUS_NVR启用写保护后未复位

在调试环境中复位芯片，重新执行演示用例程序，从log和寄存器观察窗口中可以观察到，CUS_NVR中配置的初值已经载入到了EFM_ADDR_PROT寄存器。在执行后续的擦写操作时，可以看到实际的flash存储的值没有因为擦写操作而变化，说明写保护作用已经生效。如图x所示。

图x 在CUS_NVR启用写保护后复位生效

注意：在MD和ME的芯片里，NVR里的数据对于用户不是直接可见的，需要通过专门的读操作才能拿到其中存放的数据。

再继续试一下解除写保护的情况。重新复位芯片，在log交换中解除写保护。发现此时不需要复位，EFM_ADDR_PROT的寄存器的值就已经同步过来了， 对应当下就可以恢复对flash的擦写操作。如图x所示。

图x 在CUS_NVR解除写保护后立即生效

Demo #3 启用写保护后试试块擦除操作

在测试用例中：

• 先在未启用写保护的情况下，在flash中写好预设的数据，复位。
• 在CUS_NVR中启用写保护，复位，让写保护生效。
• 再试着执行块擦除操作。

图x 试图擦除启用写保护的flash块

从图x中可以看到，启用写保护之后，执行flash块擦除操作后，预先存入flash中的数据未受影响。

Conclusion

本文专门讲解和验证了YTM32的flash写保护的功能。

• EFM_ADDR_PROT寄存器中的每个bit可以控制启用对应一块区域（8KB for MD），但只能开启写保护不能解除。如需解除必须复位，重新导入CUS_NVR的值。
• 在运行软件时，可以直接写EFM_ADDR_PROT寄存器启用写保护。但只能1变0（启用写保护），不能0变1（解除写保护）。
• EFM_ADDR_PORT寄存器的初值是从CUS_NVR导入的，因此可以通过擦写CUS_NVR设定片内flash存储的上电复位默认状态。
• 在CUS_NVR中启用写保护需要复位后才能生效，但解除写保护是可以不等复位立即生效的。
• 如果在flash块上对任意一块存储区启用了写保护，则整块flash存储器的块擦除操作都不能生效。

本文中使用了两个测试工程如下，或者私信作者获取。

• https://gitee.com/suyong_yq/arm-mcu-sdk-release/blob/master/ytm32-evk/evb-ytm32b1md-q100_efm_flash_write_protect_mdk.zip
• https://gitee.com/suyong_yq/arm-mcu-sdk-release/blob/master/ytm32-evk/evb-ytm32b1md-q100_efm_flash_write_protect_cus_nvr_mdk.zip