This content originally appeared on DEV Community and was authored by zhuyue
1. Background
Because of the concern about the reliability of ESP8266 chipset, learning from the SpaceX rocket redundancy design ideas, ready to use two ESP8266 on the controller to work together to improve reliability.
Not yet a few months, this is an accident.
The customer feedback a few months after the installation, the Wi-Fi hotspot of the controller can not be found, and it can't be restored by rebooting.
And the fault device was sent back for root cause analysis.
2. Flash content comparison
After receiving it, I first connected the serial cable to the Wi-Fi module and monitored the output logo when it was powered on.
I found that compared with the normal module, the fault product could not fetch the correct firmware from the flash address of address 0x1000, and guessed that the flash data might have been damaged abnormally.
So, I downloaded the esptool.py tool and read the firmware to the computer through the read_flash command, and I could read the whole flash content normally, and compared it with the downloaded content, and I didn't find any difference.
3. EFUSE error analysis
I downloaded the firmware with the flash download tool again, but found that it prompted an eFuse detection error.
Use the serial port debugging to capture the interaction data of the downloaded firmware and compare it with the download protocol defined by the manufacturer.
It was found that in addition to synchronization messages, the download tool also reads eFuse data content from the module.
The normal module (MAC address BC:FF:4D:07:C8:8A) returns the data as:
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 00 b0 00 31 00 00 00 c0
c0 01 0a 02 00 4d ff bc 00 00 00 00 c0
According to the protocol comparison, the corresponding efuse data are:
00 00 DA 8A, C8 07 00 02, 00 B0 00 31, 4D FF BC 00
The faulty module (MAC address C4:5B:BE:59:80:34) returns the data as:
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 00 b0 00 b7 00 00 c0
c0 01 0a 02 00 be 5b c4 00 00 00 00 c0
According to the protocol comparison, the corresponding efuse data is:
01 01 ef 34, 80 59 00 02, 00 b0 00 b7, be 5b c4 00
According to the eFuse description in the table below, the
Among them, flag3, the value of normal module is 0 indicates that it is non-ESP8285 chip, while the value of fault module is 1 indicates that it is ESP8285 chip, which is actually ESP8266, resulting in the download tool judging that the eFuse inspection is wrong.
4. Failure Analysis
eFuse is a special piece of storage space in the chip, which is internally connected to each other by fuses.
When the current flowing through it reaches a certain level, the fuse will be burnt and the value of the bit will change.
Fuse burning is non-recoverable.
Therefore, the value of eFuse can only be written once and can only be changed from 0 to 1.
When writing eFuse, you must be very careful and avoid static electricity and high temperature to prevent the eFuse from being broken.
According to the above analysis, it should be because of static electricity, high temperature or even space electromagnetic interference, which causes the data of eFuse to be destroyed, and ultimately leads to the program not being able to start normally.
Next, I am going to replace ESP-01S with ESP-07S.
ESP-07S has the following advantages:
1) External antenna can be connected to increase the range of wireless signal.
2) Passed CE, FCC certification, electromagnetic compatibility is guaranteed.
3) With metal shell, it can screen the interference signal.
This content originally appeared on DEV Community and was authored by zhuyue
zhuyue | Sciencx (2024-10-28T03:04:24+00:00) Why I use ESP8266-07s not ESP8266-01S for simple programmable controller. Retrieved from https://www.scien.cx/2024/10/28/why-i-use-esp8266-07s-not-esp8266-01s-for-simple-programmable-controller/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.