背景

上回说到，因为担心国产芯片的可靠性问题，准备借鉴SpaceX火箭的冗余设计思想，准备在控制器上用两个ESP8266协同工作提高可靠性。

还没过几个月，这就出事了。

客户反馈使用了几个月的控制器出现了找不到WiFi热点的故障，反复断电重启也无法恢复。

让客户把故障品寄回到分析。

Flash内容比对

收到之后，我首先把串口线连接到WiFi模块上，监控其上电时输出的logo，

发现与正常模块相比，故障品无法从地址为0x1000的flash地址取到正确的固件，猜想可能是flash的数据被异常损坏。

于是，下载了esptool.py工具，通过read_flash命令将固件读到电脑，可以正常读取整个flash的内容，并与下载的内容进行对比，并没发现明显差别。

EFUSE错误分析

准备再用flash下载工具下载固件，却发现提示 eFuse检验错误。

用串口调试助手抓取下载固件的交互数据，并与厂家定义的下载协议做比较。

发现除了同步消息之外，下载工具还从模块读取 eFuse的数据内容。

正常模块(MAC地址为BC:FF:4D:07:C8:8A）返回的数据为：

C0 01 0A 02 00 00 00 DA 8A 00 00 C0

C0 01 0A 02 00 C8 07 00 02 00 00 C0 /

C0 01 0A 02 00 00 B0 00 31 00 00 C0

C0 01 0A 02 00 4D FF BC 00 00 00 C0

根据协议对比，对应的efuse数据为：

00 00 DA 8A, C8 07 00 02, 00 B0 00 31, 4D FF BC 00

故障模块(MAC地址为C4:5B:BE:59:80:34) 返回的数据为：

C0 01 0A 02 00 01 01 EF 34 00 00 C0

C0 01 0A 02 00 80 59 00 02 00 00 C0

C0 01 0A 02 00 00 B0 00 B7 00 00 C0

C0 01 0A 02 00 BE 5B C4 00 00 00 C0

根据协议对比，对应的efuse数据为：

01 01 EF 34, 80 59 00 02, 00 B0 00 B7, BE 5B C4 00

根据下表中的 eFuse说明，

其中的flag3，正常模块的数值为0表示为非ESP8285芯片，而故障模块的数值为1，表示为ESP8285芯片，而该芯片实际为ESP8266，导致下载工具判断为 eFuse检验错误。

故障分析

eFuse是芯片中一块特殊的存储空间，它内部由熔丝相互连接。

当流经的电流达到一定程度时，熔丝会被烧断，该位的值会改变。

熔丝熔断是单向的、不可恢复的。

因此 eFuse 的值只能被烧写一次，只能由 0 变到 1。

在烧写 eFuse 的时候，一定要十分小心，也要注意避免静电、高温等情况，以防 eFuse 被打坏。

根据以上的分析，应该是因为静电、高温甚至空间电磁干扰的原因，导致eFuse的数据被破坏，最终导致程序不能正常启动。

接下来，准备将ESP-01S换成ESP-07S，

ESP-07S有以下优点：

1) 可以外接天线，增加无线信号的范围

2) 通过了CE,FCC认证，电磁兼容有保证

3) 有金属外壳，可以屏幕干扰信号