安全存储和访问EEPROM [英] Safely storing and accessing EEPROM

问题描述

我最近建立了在微控制器的EEPROM中存储不经常更新的配置变量的需要。将状态添加到程序中，立即强制人们担心在EEPROM中检测未初始化的数据（即第一次启动）

• 转换或使旧固件版本的数据变为无效，以及


• 寻址多个结构，每个结构可能在固件更新中增长。

广泛的Google搜索只发了一篇解决通过固件更新保持EEPROM数据有效。有没有人使用那篇文章讨论的方法？有没有更好的替代方法？

解决方案

个人而言，我更喜欢tagged表格式。

以这种格式，您的数据被分成一系列表。每个表格都有一个标题，它遵循可预测的格式，一个可以根据需要改变的主体。

下面是一个表的样例：

 字节0：表长度（16位字）
字节1：表格ID确定这些数据是什么）
字节2：格式版本（每次此表的格式更改时都会增加）
字节3：校验和（简单的和到零校验和）
字节4：身体开始
 ... 
字节N：身体结束
  

我没有存储大量的数据，所以我为标题中的每个字段使用了一个字节。只要你永远不会改变，你可以使用任何需要的尺寸。数据表一个接一个地写入EEPROM中。

当您的固件需要从EEPROM读取数据时，它将从第一个表开始读取。如果固件识别表ID并支持列出的表版本，则会将数据从表的正文中加载（当然，验证校验和后）。如果ID，版本或校验和没有签出，表格将被简单地跳过。长度字段用于定位链中的下一个表。当固件看到长度为零的表时，它知道已经到达数据的末尾，并且没有更多的表要处理。

我发现这个格式灵活（我可以将任何类型的数据添加到表的主体中）和鲁棒性（保持标题格式不变，数据表将向前兼向后兼容）。

有几个注意事项，虽然它们不是太繁重。首先，您需要确保您的固件可以处理重要数据不在表中或正在使用不受支持的格式版本的情况。您还需要将EEPROM存储区域的第一个字节初始化为零（这样在第一次引导时，您不会开始加载垃圾，认为它是数据）。由于每个表都知道其长度，因此可以扩展或缩小表;但是，您必须移动桌面存储区域的其余部分，以确保没有孔（如果整个表的链表不能放在设备的内存中，则此过程可能会令人讨厌）。就个人而言，我并没有发现任何这些问题，这是非常值得我使用其他数据存储方法保存的麻烦。

I've recently established the need to store infrequently-updated configuration variables in the EEPROM of a microcontroller. Adding state to the program immediately forces one to worry about

• detection of uninitialized data in EEPROM (i.e. first boot),
• converting or invalidating data from old firmware versions, and
• addressing of multiple structures, each of which which may grow in firmware updates.

Extensive Googling has only turned up one article that addresses keeping your EEPROM data valid through firmware updates. Has anyone used the approach discussed in that article? Is there a better alternative approach?

解决方案

Personally, I prefer a "tagged table" format.

In this format, your data is split up into a series of "tables". Each table has a header that follows a predictable format and a body that can change as you need it to.

Here's an example of what one of the tables would look like:

Byte 0: Table Length   (in 16-bit words)
Byte 1: Table ID       (used by firmware to determine what this data is)
Byte 2: Format Version (incremented every time the format of this table changes)
Byte 3: Checksum       (simple sum-to-zero checksum)
Byte 4: Start of body
...
Byte N: End of body

I wasn't storing a lot of data, so I used a single byte for each field in the header. You can use whatever size you need, so long as you never change it. The data tables are written one after another into the EEPROM.

When your firmware needs to read the data out of the EEPROM, it starts reading at the first table. If the firmware recognizes the table ID and supports the listed table version, it loads the data out of the body of the table (after validating the checksum, of course). If the ID, version, or checksum don't check out, the table is simply skipped. The length field is used to locate the next table in the chain. When firmware sees a table with a length of zero, it knows that it has reached the end of the data and that there are no more tables to process.

I find this format flexible (I can add any type of data into the body of a table) and robust (keep the header format constant and the data tables will be both forward- and backwards-compatible).

There are a couple of caveats, though they are not too burdensome. First, you need to ensure that your firmware can handle the case where important data either isn't in the table or is using an unsupported format version. You will also need to initialize the first byte of the EEPROM storage area to zero (so that on the first boot, you don't start loading in garbage thinking that it's data). Since each table knows its length it is possible to expand or shrink a table; however, you have to move the rest of the table storage area around in order to ensure that there are no "holes" (if the entire chain of tables can't fit in your device's memory, then this process can be annoying). Personally, I don't find any of these to be that big of a problem, and it is well worth the trouble I save over using some other methods of data storage.

这篇关于安全存储和访问EEPROM的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！