众所周知，Flash 存储器的写入耐久性有限，因此读取也可能有上限，例如此 Flash 耐久性测试的结论（第 3 点）中提到的。
在微控制器上，代码通常存储在 Flash 中，并通过直接从 Flash 单元中获取代码字来执行。
（至少这在 8 位微控制器上最常见，一些 32 位微控制器可能有一些小缓冲区）。
根据特定的代码，可能会非常频繁地访问某个位置，例如如果在主执行路径上存在一些繁忙的循环，例如等待中断
（例如来自计时器，将执行同步到固定间隔）。
这可以平均每秒对单个 Flash 单元产生 100K 甚至更多（读取）访问（取决于时钟和特定代码）。
这样的代码真的会破坏它下面的 Flash 单元吗？
（在为微控制器设计代码时，是否有必要关注这个特殊问题？例如要运行多年的系统的一部分？当然 Flash 可以通过 CRC 定期验证，但这并不妨碍如果发生系统故障，只是故障更有可能以受控方式发生）
只有擦除/写入会影响存储单元，而不是读取。设计程序时不需要考虑读取次数。
不过，编程闪存确实会老化，这意味着在一定年限后，单元的值可能不可靠。这称为数据保留，主要取决于温度。假设部件保持在最高指定环境温度下，MCU 制造商通常会在几年内指定更坏的情况。
对于预期寿命较长（> 10 年）的产品，尤其是在可能出现高温的环境中，这是需要考虑的问题。CRC 和/或 ECC 是防止数据保留的一种很好的对策，尽管如果您确实发现某个单元已损坏，这通常意味着应用程序应该关闭到不可恢复的安全状态。
我知道解决这个问题的两种技术：
1) 一种技术是在系统代码中留出一个 const 32 位整数变量。然后计算编译后的二进制图像的 CRC32 校验和，并使用 ELF 编辑器将校验和插入到保留变量中。然后，系统软件中的一个模块将计算应用程序占用的闪存区域的 CRC32，并与“存储”值进行比较。如果您使用 GCC，链接器可以定义一个符号来告诉您段停止的位置。此方法可以检测错误但无法纠正错误。
2) 另一种技术是使用支持 Flash ECC 的微控制器。TI 销售支持 Flash ECC（Hercules 系列）的 Cortex-R4 MCU。
我怀疑这是一个实际问题。您引用的文章含糊地断言这可能发生，但没有支持证据或量化效果。引言中有一个模糊的、没有依据的、没有量化的参考：
[...] 随着时间的推移，闪存会因擦除/写入（甚至只是读取，尽管衰减较慢）而退化 [...]
然后在结论中：
- 我们没有检查读取的闪存衰减，但读取也会导致长期衰减。看看我们是否能读到足够多的时间来导致失败会很有趣。
作者可能指的是 NAND 闪存中的读取干扰，但微控制器不使用 NAND 闪存进行代码存储/执行，因为它不是随机访问。读取干扰不是永久效果，擦除和重写受影响的块可以恢复耐力。NAND 控制器维护块的读取计数，并根据需要自动复制和擦除块。他们还使用 ECC 来检测和纠正错误，并识别“写入磨损”区域。
存在长期“位腐烂”的可能性，但我怀疑它是专门由阅读引起的，而不仅仅是老化。
大多数 RTOS 系统将大部分处理时间花在无所事事的空闲循环中，并且一年 24/7 365 天愉快地运行。一些处理器支持在空闲循环中停止 CPU 的等待中断指令，但绝不是全部，不使用这样的指令并不少见。具有闪存加速器或缓存的处理器也可能会阻止从单个位置连续快速获取，但这绝不是所有微控制器。