Algorithm 基于STM32L1x的闪存ECC算法

在STM32L1x上实现的闪存ECC算法（闪存纠错码）是如何工作的

背景： 我想对STM32L151 MCU的程序闪存中的单个字执行多个增量写入，而不在其间执行页面擦除。如果没有ECC，可以增量设置位，例如，先设置0x00，然后设置0x01，然后设置0x03（STM32L1将位擦除为0而不是1），等等。由于STM32L1每个字有8位ECC，因此此方法不起作用。然而，如果我们知道ECC算法，我们可以很容易地找到一个短的值序列，它可以在不违反ECC的情况下以增量方式写入

我们可以简单地尝试不同的值序列，看看哪个序列有效（其中一个序列是0x0000001、0x0000001、0x00030101、0x03030101），但如果我们不知道ECC算法，我们就无法检查序列是否违反ECC，在这种情况下，如果位被破坏，纠错就不起作用

---

[编辑]该功能应用于使用STM32L1的内部程序内存实现简单的文件系统。数据块用包含状态的头标记。多个块可以驻留在一个页面上。状态可以随时间而改变（先是“新建”，然后是“已使用”，然后是“已删除”，等等）。状态的数量很小，但是如果我们可以覆盖以前的状态而不必先擦除整个页面，那么事情就会变得非常简单。

谢谢您的评论！由于到目前为止还没有答案，我将总结我到目前为止所发现的（根据经验和对这个答案的评论）：

• 根据STM32L1数据表“整个非易失性存储器嵌入了纠错码（ECC）功能”，但参考手册并未说明程序存储器中的ECC
• 数据表与我们在随后将多个单词写入同一个程序mem位置而不删除中间的页面时所能发现的经验一致。在这种情况下，某些值序列起作用，而其他值序列则不起作用

以下是我个人的结论，基于实证研究结果、有限的研究和本文的评论。这不是基于官方文件。不要在上面做任何严肃的工作（我也不会）

• 似乎ECC是按每个32位字计算和持久化的。如果是，ECC的长度必须至少为7位
• 每个单词的ECC可能与单词本身写入相同的非易失性mem。因此，同样的限制也适用。即，在擦除之间，只能设置附加位。正如斯塔克指出的，我们只能用以下值覆盖程序mem中的单词：
  • 仅设置附加位，但不清除任何位
  • 与以前的ECC相比，ECC只设置额外的位
• 如果我们写入一个仅设置额外位的值，但ECC需要清除位（因此无法正确写入），则：
  • 如果ECC错误一位，则通过ECC算法纠正错误，并且可以正确读取写入的值。然而，如果另一位失败，ECC将不再工作，因为ECC只能纠正单位错误
  • 如果ECC错误超过一位，ECC算法无法纠正错误，读取值将错误
• 我们无法（轻易）从经验上找出哪些价值序列可以正确书写，哪些不能。如果一系列值可以被正确地写入和读取，我们就不知道这是否是由于单位错误的自动纠正。这就是这个问题需要实际算法的全部原因

• ECC算法本身似乎没有文档记录。汉明码似乎是ECC的一种常用算法，他们写道，汉明码实际上用于SRAM中的纠错。该算法可能用于也可能不用于STM32L1的程序内存

• 似乎并没有明确禁止在没有擦除的情况下对程序内存进行多次写入，但也没有任何文档说明相反的情况。为了不使用未记录的功能，我们将避免在产品中使用此类功能，并找到解决办法

---

谢谢您的评论！由于到目前为止还没有答案，我将总结我到目前为止所发现的（根据经验和对这个答案的评论）：
• 根据STM32L1数据表“整个非易失性存储器嵌入了纠错码（ECC）功能”，但参考手册并未说明程序存储器中的ECC
• 数据表与我们在随后将多个单词写入同一个程序mem位置而不删除中间的页面时所能发现的经验一致。在这种情况下，某些值序列起作用，而其他值序列则不起作用
以下是我个人的结论，基于实证研究结果、有限的研究和本文的评论。这不是基于官方文件。不要在上面做任何严肃的工作（我也不会）
• 似乎ECC是按每个32位字计算和持久化的。如果是，ECC的长度必须至少为7位
• 每个单词的ECC可能与单词本身写入相同的非易失性mem。因此，同样的限制也适用。即，在擦除之间，只能设置附加位。正如斯塔克指出的，我们只能用以下值覆盖程序mem中的单词：
  • 仅设置附加位，但不清除任何位
  • 与以前的ECC相比，ECC只设置额外的位
• 如果我们写入一个仅设置额外位的值，但ECC需要清除位（因此无法正确写入），则：
  • 如果ECC错误一位，则通过ECC算法纠正错误，写入的值可以读取

    for <bitIdx>=0 to 31
      earse cell
      write start value, like 0xFFFFFFFF & ~(1<<testBit)
      clear bit <bitIdx> in the cell
      read the cell
    next