上回說到，因為擔心國産芯片的可靠性問題，準備借鑒SpaceX火箭的冗餘設計思想，準備在控制器上用兩個ESP8266協同工作提高可靠性。

還沒過幾個月，這就出事了。

客戶反饋使用了幾個月的控制器出現了找不到WiFi熱點的故障，反複斷電重啟也無法恢複。

讓客戶把故障品寄回到分析。

收到之後，我首先把串口線連接到WiFi模塊上，監控其上電時輸出的logo，

發現與正常模塊相比，故障品無法從地址為0x1000的flash地址取到正确的固件，猜想可能是flash的數據被異常損壞。

于是，下載了esptool.py工具，通過read_flash命令将固件讀到電腦，可以正常讀取整個flash的内容，并與下載的内容進行對比，并沒發現明顯差别。

esptool.py工具介紹

準備再用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

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!