Data written to EEPROM gets randomly wiped out (rewritten as 0xff) after reset, wake from sleep, or power off/on
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 25/100
- Issue 类型
- 缺陷
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- cpp
- 领域
- embedded-iot
调研方向
该 payload 没有指出源文件或测试。首先，将解释 EEPROM.begin/read/write/commit 的 sketch 在使用 core 3.1.2 的 SparkFun ESP8266 Thing Dev 上转换为经过测试的复现，然后将其在 reset、sleep 和 power cycle 下的行为与较旧的 core 进行比较。完成的标准是确定一个可复现的原因，并验证已 commit 的 EEPROM 数据不会被 0xff 替换。
由索引模型根据 Issue 内容生成。
描述
Basic Infos
- This issue complies with the issue POLICY doc.
- I have read the documentation at readthedocs and the issue is not addressed there.
- I have tested that the issue is present in current master branch (aka latest git).
- I have searched the issue tracker for a similar issue.
- If there is a stack dump, I have decoded it.
- I have filled out all fields below.
Platform
- Hardware: ESP8266
- Core Version: 3.1.2
- Development Env: [Arduino IDE|]
- Operating System: [Manjaro Linux]
Settings in IDE
- Module: Sparkfun ESP8266 Thing Dev
- Flash Mode: [qio|dio|other] I don't know
- Flash Size: 512 kB
- lwip Variant: v2 Lower Memory
- Reset Method: I don't know
- Flash Frequency: [40Mhz] I don't know
- CPU Frequency: [80Mhz|160MHz] I don't know
- Upload Using: [SERIAL]
- Upload Speed: [115200] (serial upload only)
Problem Description
My code writes to the (fake?) EEPROM with EEPROM.write() and EEPROM.commit() and reads with EEPROM.read() the data that has been written in previous "sessions".
Sometimes, utterly randomly, after waking up from sleep, when my sketch reads a byte from a given position, instead of the value that it had previously written, it finds a 0xff.
My code had been running for literally years without issues on a dozen identical boards.
Recently I re-compiled and re-uploaded with the last version of the Arduino core on a new unit of the same identical board. I made no changes to the relevant part of the code, but the version compiled with the latest core has this issue.
Note that I'm observing the issue on a brand new chip, so this is not the Flash memory getting damaged by too many write cycles. Also, the old boards that are still running the code that was compiled with the old core, are still having no issue (they haven't got anywhere near 10k write cycles).
MCVE Sketch
NOTE: I cannot share the original sketch. I haven't written and tested a minimal sketch. The issue is hard to reproduce at will because it occurs randomly, but it happens often. I'm writing a minimal code example just to explain the issue, but I have not run and tested the code below; consider it as explanatory pseudo-code, it may very well contain mistakes.
#include <Arduino.h>
void setup() {
EEPROM.begin(512);
char x = EEPROM.read(0);
if (x != 'X') Serial.printf("!!! Unexpected value found in EEPROM: %d\n", x);
else Serial.println("Found expected value in EEPROM");
EEPROM.write(0, 'X');
EEPROM.commit();
}
void loop() {
}
Debug Messages
Debug messages go here
- 主要语言
- C++
- 星标
- 16.7k
- 派生
- 13.1k
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
esp8266/Arduino 的其他 Issue
-
Typo in Scan Class Documentation可能已有人在做 @MukundaKatta 于 186 天前认领。 未关闭
难度 1/5 1 小时以内 新手友好度 70/100
-
难度 2/5 1-3 小时 新手友好度 62/100
-
lwip2 time-wait.patch: TCP_TW_LIMIT can abort the pcb that tcp_process() is still handling -> double free, heap corruption可能已有人在做 @scardus 于 19 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 52/100
-
难度 3/5 1-2 天 新手友好度 65/100
-
难度 4/5 3-5 天 新手友好度 42/100
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
content good first issue
难度 1/5 1 小时以内 新手友好度 95/100
cpinitiative/usaco-guide#6699 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
codepointerapp/codepointer#231 ·
-
enhancement source/qq
难度 2/5 1-3 小时 新手友好度 72/100
metasequoiaime/msime-windows#1054 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
amnezia-vpn/amnezia-client#3297 · 1 条评论 ·
维护者通常 1 天内回复