串口线连接正常(串口线连接正常,但是没数据)串口线连接正常(串口线连接正常,但是没数据)
背景上回说到，因为担心国产芯片的可靠性问题，准备借鉴SpaceX火箭的冗余设计思想，准备在控制器上用两个ESP8266协同工作提高可靠性。
还没过几个月，这就出事了。
客户反馈使用了几个月的控制器出现了找不到WiFi热点的故障，反复断电重启也无法恢复。
让客户把故障品寄回到分析。
Flash内容比对收到之后，我首先把串口线连接到WiFi模块上，监控其上电时输出的logo，
发现与正常模块相比，故障品无法从地址为0x1000的flash地址取到正确的固件，猜想可能是flash的数据被异常损坏。
于是，下载了esptool.py工具，通过read_flash命令将固件读到电脑，可以正常读取整个flash的内容，并与下载的内容进行对比，并没发现明显差别。
esptool.py工具介绍
EFUSE错误分析准备再用flash下载工具下载固件，却发现提示 eFuse检验错误。
下载工具提示的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说明，
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) 有金属外壳，可以屏幕干扰信号
ESP-01 VS ESP-07S
