[参考译文] RTOS/TM4C1294NCPDT：未发生电源故障时的 EEPROM 写入。

这就是读取和写入 EEPROM 数据的方式。

////// 数据写入和读取的结构//////////////
typedef struct vol_vars_flowmeter_struct_prototype
｛
uint64_t digin_counter_value；

｝struct_VOL_VARS_FL_meter；

//易失性变量结构

typedef struct volatile_vars_prototype
｛
char start；//虚拟变量


STRUCT_VOL_VARS_FL_METER fl_meter[6]；

uint8_t dummy[8]；//这是为了使 EEPROM 映像复制和检索例程正常工作，使以4字节倍数读取和写入 EEPROM 存储器
}struct_VOL_VARS；

extern struct_VOL_VARS vol_vars；


//// 用于写入////////
EEPROMProgram ((uint32_t *)(&(vol_vars.start))、E2P_LOCATE_for_VOL_VARS、sizeof (vol_vars)& 0xfffffffffffc)；


//// 用于读取//////////////
if (sys_state.EEPROM_ERROR =(char) EEPROMInit（))
｛
System_printf ("EEPROM 初始化错误！！！！\n")；
｝

EEPROMRead (((uint32_t *)(&(vol_vars.start))、E2P_LOCATE_for_VOL_VARS、sizeof (vol_vars)))；

[引用 user="Nimesh Modi]1. 在固定位置写入100字节数据需要多长时间？[/引述]

如果100个字节构成25个字、则为25 x (110us 至600us)。 如果字节全部用单独的字、则为100 x (110us 至600us)

[引用用户="Nimesh Modi]2. 在 TM4C129ENCPDT 控制器数据表中、"Space Available (可用存储空间)"一词中提到"32位数据的编程时间通常为110us、最大为600us "、这意味着什么？ 我们是否应该在写入前擦除数据？

EEPROM 数据存储在块中。 在存储块的第8个副本之前、必须先擦除块、然后才能存储数据的7个副本。 这是由状态机为您完成的、但确实会显著增加时间、因为您现在必须包含擦除块的时间。

[引用用户="Nimesh Modi]3. 在"复制到复制缓冲区"中、另一行是"需要复制到复制缓冲区的32位数据的编程时间、复制缓冲区有空间且使用的 EEPROM 耐久度不足10%"。 它是否将数据从一个 EEPROM 位置复制到另一个位置？

是的、基本上、数据被编程到一个特殊的"复制块"中、原始块被擦除、然后数据被编回原始块中。 如果复制块此时已满、则必须先将其擦除、这会使所需时间加倍。

返回到您的初始问题。 编程100字节数据所需的时间取决于字节在96个块之间的分布方式。 如果必须擦除多个块、则总时间会增加。 擦除时间随使用次数的增加而增加、因此在 EEPROM 寿命的前10%和后90%中有不同的值。

[引用用户="Nimesh Modi]4. 我使用"if (sys_state.EEPROM_ERROR =(char) EEPROMInit（))"来验证 EEPROM 写入、但它始终会成功。 任何解决方案？[/报价]

这不是获取编程操作状态的正确函数。 该函数应在启用 EEPROM 模块后立即运行、以查看在先前擦除块时是否发生功率损耗或复位。

获取编程操作状态的函数是 EEPROMStatusGet ()。

[引用 user="Nimesh Modi">我们有定制设计板。 在我们的项目中、我们将在进行电源故障检测时将数据保存到 EEPROM 中。[/quot]

即使具有快速的外部存储器、这种存储器也有点脆弱、容易出现故障。 您不仅需要保护您立即编写的内容、而且还需要保护 EE 中的所有其他内容免受损坏。

[引用用户="Nimesh Modi]3. 在"复制到复制缓冲区"中、另一行是"需要复制到复制缓冲区的32位数据的编程时间、复制缓冲区有空间且使用的 EEPROM 耐久度不足10%"。 它是否将数据从一个 EEPROM 位置复制到另一个位置？

请注意、这仍然是最乐观的情况。 悲观的情况下的幅度要长得多。

最后、这非常重要。 全面阅读勘误表。

Robert

[引用 user="Bob Crosby"]

如果100个字节构成25个字、则为25 x (110us 至600us)。 如果字节全部用单独的字、则为100 x (110us 至600us)

[/报价]

尊敬的 Bob：

感谢您的回复。

因此、对于100字节、EEPROM 写入最多需要60ms。 我们能够在检测到电源故障后生成400ms 的时间。 因此、写入的原因是失败的。 我已经发布了我的代码。

谢谢、
Nimesh

[引用 USER="Nimesh Modi"]因此 EEPROM 写入最多需要60ms、100个字节[/引用]

我实际上会测量它。

[引用 user="Nimesh Modi">我们能够在检测到电源故障后生成400ms 的时间。 [/报价]

还有这种情况。

设置  电源故障检测的输出位。

开始写入时、设置输出位(另一个位)。

写入完成时清除该位。

使用示波器或逻辑分析仪测量所有4个点、需要3条线路

• 电源故障输入
• 微控制器的电源故障检测
• 写入的开始
• 写入结束。

请看一下最坏情况下的数据表时序、而不仅仅是您现在所做的最佳情况。

Robert

还有勘误表。

[引用用户="Robert Adsett"]

即使具有快速的外部存储器、这种存储器也有点脆弱、容易出现故障。 您不仅需要保护您立即编写的内容、而且还需要保护 EE 中的所有其他内容免受损坏。

[/报价]

您好、Robert、

感谢您的回复。

是的、在测试时、我还面临着一种情况、即我得到了垃圾值、每次该值为"21474836475"。

是否有任何其他方法可以在发生电源故障时存储数据。

Nimesh

您好、Bruno、

感谢您的建议。

它需要在我们的定制板中进行更改。 我要试一下。

同时、您能否查看我的代码。 它有什么问题吗？  

此致、

Nimesh

正如在座的其他人所建议的-您的 MCU、"在这样的"快速数据保存角色"中不会特别"闪耀"(表现良好)！    ("表现不佳"是严重的低估...)

您坚持引导他人"查看您的代码"-即使您被引导至"非 MCU"、也意味着更好地实现 "快速、稳健、快速的数据存储！"的目标。    您知道这一事实-您不知道吗？    虽然您已经注意到(部分)与此处的其他人达成协议-此类"代码审核"表明您尚未"确信"。   (即使是在您第一次报告之后、您发现重复但总是错误的数据！)    原谅-但"看一下代码"是什么意思？

MCU 可能"提供功能"这一事实并不能确保"此类功能"得到有效管理、也不能确保它与其他功能"合理竞争"-更长的现有时间和更出色的(外部设备)意味着！

坚持使用"定制板"可以确保对您可能保存的数据量和(更重要的)数据的稳健性都有限制！     这种情况是否可以-无论如何-证明是好的？

将此类数据保存到速度更快、更可靠的外部(设计用于任务)器件将非常有利于您。    (和-如果您曾预见到"推出"SPI 总线-这可能使您能够"保留"您的电路板-只添加一个小型外部 EEPROM、或者可能添加一个 Fram "插件板"。)

[报价用户="Nimesh Modi"]是否有任何其他方法可以在发生电源故障时存储数据。

是的、请使用外部存储器。 EEPROM 或 FRAM。 FRAM 是目前为止最快的。 MRAM 将与其速度相匹配、但我尚未看到任何用于简单 SPI 或 IIC 连接的设计。

但是、这一点很重要、我会严重质疑您是否需要在断电时节省电力。 特别是对于 FRAM、每当值发生变化时、您都将保存下来。 使用 EE 时、您需要在尝试之前进行一些检查、但 FRAM 基本上具有不受限制的读取和写入。 您仍有电源故障、但其目的是防止在电源即将发生故障时写入、因此您不会因断电而中断写入。

Robert

回复："伪装成亲吻。"    伪装-这里-可能证明不必要-因为费用是-并且仍然是-全速前进...

当您将海报(远离)从"断电时保存"(而不是)定向到"重要价值更改时保存"需要"重复和回忆"( 此处显示的少数情况是"荣誉/遵循"这样的"明智实践！"    而有缺陷的厨房盥洗盆(MCU 的艰难尝试) EEPROM 工作证明了这一关键方面的"灾难"(灾难)...

Robert、
像往常一样，你从塔上观察，用显而易见的东西把我的脸打了一个耳光！
当您可以在每次更改数据时保存数据时、为什么需要监控功率损耗(使用 FRAM)？
太棒了！
借助 FRAM、他的系统甚至可以每秒保存一次状态、包括"上次看到活动状态"的时间戳...
布鲁诺

说到这一点、我们做的第一个项目之一是一个基于低功耗 MSP430的引擎运行时间计数器... 当然、整个目的是为了节省总的系统时间"就在它关闭时"... 至少十年过去了、但我只能说、当时使用的技术一点也不优雅！

作为"小 BIZ 所有者"的同事、"优雅"可能存在于"付费票据之眼"中？ 定期返回加热/照明/解锁的工作空间需要(一些)成就-有时可能会进入"优雅"状态。

[引用用户="Bruno Saraiva">Robert、
您通常从塔中观察到[/引用]

这是"毫无疑问的"的-罗伯特应该得到定期的赞扬。

那话——经过一段思考——“也许有某些弱点——给圣职的布上污点？”

如果是、"仅在更改时保存："

• 您是否不容易受到"初始值选择和加载"的影响？   (假设最初加载了"0" 、并且所有后续数据(断开电缆)重复"0" 、因此"无法检测！")
• 并且-(假定的)数据采集过程是否会出现缺陷、锁定、或者以某种方式"不让它成为负责此类"变化检测"的处理代码-那又是什么？

我确信 Robert 的想法是这样的-但似乎是这样的、"在变化时节省"的要求(进一步/补充：测试和验证)、以便任何此类变化都有"公平的机会"被检测到-然后正确"通过/处理"-最后(如果/当有效-记录！)

此外，在检测"最后时刻值"方面也有价值，特别是在可以"完全/正确"捕获这些值的情况下，因为它们(单独)可能提供关键的"最终数据"，因此在特殊情况下通常是必要的。 通常很不愉快！

没有通用的解决方案、但为了尽可能简单、我只需将 FRAM 保存函数注册为一个每秒一次的周期性任务、其中相关数据的完整结构将是 CRC、镜像并存储到存储器、天气或不发生变化。

如果在最后一个"半秒"发生更改、并且需要在可能发生电源故障之前保存、则需要更具体的"更改后呼叫节省程序"。

[引用 USER="CB1_MOBILE"]

Bruno Saraiva

Robert、
您通常从塔中观察到

那话——经过一段思考——“也许有某些弱点——给圣职的布上污点？”

[/报价]

如果我在塔中、它会延伸到我的上方。 我可以听到上面那些辛勤工作的人的声音。

[报价 USER="CB1_MOBILE]您是否不容易受到"初始值选择和加载"的影响？   (假设最初加载了"0" 、并且所有以下数据(电缆断开)重复"0" 、因此"无法检测！")[/quot]

这会是一个问题，因为...？ 任何一种方式都将被存储。

[引用 user="CB1_MOBILE"]我确信 Robert 曾考虑过这一点-但似乎是这样、"在变化时节省"要求(进一步/补充：测试和验证)、以便任何此类变化都有"公平的机会"被检测到-然后正确地"通过/处理"-最后(如果/何时有效-记录！)[/QUERPLEG]

任何基于通信的参数都将在作为参数写入之前进行验证、因此应该已经注意到。

记录运行/故障条件略有不同、但情况并非如此。 可以定期保存条件(例如每10ms 一次)。 向其添加更改检测是一种优化、而不是其基本操作的一部分、因为它是针对参数的。

[报价 USER="CB1_MOBIST"]此外，在检测“最后时刻值”时有价值[/QUERPLET]

但是、损坏存储的值会产生负值。 因此、检测异常和操作并写入存储器、但在断电时停止写入。 请注意、您仍然需要保持写入周期、但您的时序要求会发生显著变化、从而简化生成的软件。 请注意、断电时、您还应停止控制、因为它不再被视为可信。

 这里实际上并不是一种大小的适配器。 我当前的方法是这样的

• 固定参数
  • 通过 const (可能是#define)定义。 无法在运行时更新
• 工厂校准和配置。 这些参数至关重要、必须正确保留。 由于这种情况仅在受控条件下发生一次、因此 TI EE 在此是可以接受的。
  • 存储在块中
  • 块受到 CRC 未检测到的损坏保护
  • 块使用其他副本镜像、因此如果一个块发生故障、则有备份
  • ROM 中初始值的默认块、并作为最终回退。 请注意、如果参数丢失足够关键、此默认设置可能会禁用器件的全部或部分功能。
• 用户关键配置 对于操作至关重要、更改不频繁 、必须保留。 同样、如果不经常更改并且在受控条件下、TI 内部 EE 可能是可接受的。 但必须考虑到这一点。
  • 存储在块中
  • 块受到 CRC 未检测到的损坏保护
  • 块使用其他副本镜像、因此如果一个块发生故障、则有备份
  • ROM 中初始值的默认块、并作为最终回退
• 用户非关键配置 虽然重要、但恢复默认并不重要。 与关键配置相比、这种变化的最大优势是所需的存储空间减少。
  • 存储在块中
  • 块受到 CRC 未检测到的损坏保护
  • ROM 中初始值的默认块、用作回退
• 操作和错误日志。 虽然您不需要错误、但它们并不重要。 您可能会失去一些诊断功能、但如果未检测到错误、操作将不受影响。 此外、这些可能还需要频繁、快速的更新、因此降低开销是一个显著的优势。
  • 存储在块中

此更新频繁且在断电时停止写入、而不是仅在断电方法上更新、并不会真正影响 NV 存储的最终结果。 不过、它的写入更简单、更容易确定的电源故障条件。 这两种解决方案将带来更强大的解决方案*。 它确实要求 NV 存储能够承受更多的写入和更频繁的写入。

Robert

*我记得一个硬件(IC)解决方案、因为它应该更新断电时遇到故障批次的 EE。 必须添加功能测试以验证在某种程度上延长断电时间后是否成功保留了存储。

OP 来到这里、要求某人查看他的代码...
他收到了一篇关于微控制器最佳实践的完整文章！
希望这次讨论的价值和这里的出色建议得到应有的重视！

然而-这是预期的-(再次)海报将指示"查看我的代码！"
"保存"(可能)未完全规划/实施的董事会是并且仍然是"首要目标..."

您是否已经(尚未)从马德里的这家店获得了"免费牛排优惠券(通过 PM)"？    (他们有一种特殊的方法来"积累"风味元素、围绕纽带...)

您好！

提出"查看我的代码"的原因是、我们在不同的项目中使用此逻辑已有一年多、我们在任何项目中都不会遇到此类问题、因为我们能够在电源故障检测后生成400ms 的时间。 我们已经将设备交付给客户端的另一件事。 因此不能使用外部"FRAM"。   

但是、我们可能不应该信任内部 EEPROM 在该控制器中存储电源故障情况下的数据。 因此、它在我们的项目中是无用的。

目前、我很乐意使用"小型备用电池"。  

非常感谢您的建议。

Nimesh  

"小型备用电池"可能会受到挑战、具体取决于"此类使用的程度"。   正如您所知、"写入 EEPROM 功能"会大量消耗您的电源、在您的场景中、每次断电(或可能是"欠压")也会消耗电池电量。

通常需要使用电池管理电路(未提及该电路)、以便在需要时(仅限)使用电池。   "固件"如此之快-并非总是证明-是最好的解决方案...

"MCU 的 EEPROM-lite "方法的内在复杂性和弱点继续存在-"保存的数据稳健性"可能没有"高证据"。

[引用用户="Nimesh Modi"]提出"查看我的代码"的原因是、我们在不同的项目中使用此逻辑已有一年以上、并且我们在任何项目中都不会遇到此类问题

那么、为什么输入代码而不是 H/W 呢？

[报价用户="Nimesh Modi"]我们能够在检测到电源故障后生成400ms 的时间。

您是否测量过它？ 然后是寿命下降的原因吗？ 您是否测量了 EE 写入所需的时间？ 您是否测量了对电源故障信号做出反应所需的时间？

根据数据表中的数字、我预计最坏情况下的小幅数据写入时间会超过1/2秒。 长期而言、最坏情况的持续时间要长得多。

[引用 user="Nimesh Modi">我们已将设备交付给客户端的另一件事。 因此不能使用外部"FRAM"。   

Nimesh Modi 说：

目前我很乐意使用"小型备用电池"。  [/报价]

这些说法是矛盾的。 在任何一种情况下都需要修改。 电池使用需要进行相当大的修改、包括某种关断电路。

Robert

我同意在断电期间写入非易失性存储器是棘手的问题、但在前10%的耐久性(前50K 周期)中、您尝试做的基本上是正确的。 在这种情况下、您应该能够在400ms 之内对连续位置的100个字节进行编程。 Bruno 建议使用输出引脚和示波器来计时事件、这是一个很好的建议。

我已经查看过您的代码、因此很难为您提供特定的答案。 您询问了编程100个字节的最长时间、但代码显示了对包含57个字节的结构的56个字节进行编程。 差异很大、因为 EEPROM 被划分为64字节块。 如果我在一个块内对56个字节进行编程、那么我的最大时间基本上就是较短的编程时间和两个擦除时间。 (额外的擦除是在复制缓冲区也必须被擦除时进行的。) 如果56个字节跨越一个块边界、那么最大时间必须包括四个擦除时间。 编程100个字节、如果它跨越两个页边界、则必须包括五个擦除时间。 数据对齐会影响编程时间。

我设置了一个实验、写入在单个块内对齐的56个字节。 我测量了顺序写入的编程时间。
周期1-6：1.7mS
周期7：16.3mS
周期8-13：1.7mS
周期14：16.3mS
周期15-20 1.7mS
周期21：16.3mS
周期22-27：1.7mS
周期28：16.3mS
周期29-34：1.7mS
周期35：16.3mS
周期36-41：1.7mS
周期42：24.7mS

请注意、模式6个周期花费1.7mS、不会发生擦除。 第7个周期添加单次擦除、所需时间为16.3mS。 由于复制缓冲区也被擦除、第六个擦除周期需要额外的擦除。

我的时间可能略小于您测量的时间、因为我每次实际上只更改了结构中的一个64位变量、而该实验是在室温下完成的。 更改更多变量将增加编程时间、但擦除时间将相同。 擦除时间会随着循环和低温而增加、但通常直到进入闪存的耐久性寿命。

简而言之、如果您无法在400ms 内对相对较新的器件上的100字节 EEPROM 进行编程、则其他问题是错误的、应进行调查。