ESP8266 rare hang

Hi again,

well, I have been trying with the lates ESP8266 1.3.0 SDK but the problem still persists. Sometimes, when the WIFI connection is lost (switching off the router for example), and the WIFI network comes back, the ESP8266 module does not recover, and from that moment on, it will NEVER recover. A network scan does not show the network. And even if you reset the system, the ESP8266 does not recover.

However, if you ERASE the full flash and you flash your program again with esptool.py, the system recovers.

The reason is that the internal firmware stores something in the flash that is not correct, and the system cannot recover from that situation without cleaning the sector where this wrong information has been written.

We have done an experiment. We place this at the begining of the user_main function (after UART initialization):

 

uint16_t s,res;

os_printf(“Erasing sectors\n”);
for (s=0x70;s<=0x7F; s++)
{
res = spi_flash_erase_sector(s);
os_printf(“Sector erased 0x%02X. Res %d\n”,s,res);
}

And when the system hangs, it recovers after reset always!!!

Now, we inspect:

python esptool.py erase_flash

python esptool.py read_flash 0x00000 0x80000 erased.bin

python esptool.py write_flash 0x00000 firmware\0x00000.bin 0x40000 firmware\0x40000.bin

python esptool.py read_flash 0x00000 0x80000 written.bin

then we corrupt the system by switching on and off the wifi, and we read back the result:

python esptool.py read_flash 0x00000 0x80000 corrupted.bin

And wow!! It is there! We have changes in 0x7D000 0x7E000 and 0x7F000

0x7D000esp8266_corrupted_wifi_params_0x7D000

0x7E000

esp8266_corrupted_wifi_params_0x7E000

0x7F000

esp8266_corrupted_wifi_params_0x7F000

This is not a real surprise:

config ADDR_BLOBSETTING1
hex "Adress of blob settings in flash (copy 1)"
default 0x7d000

config ADDR_BLOBSETTING2
hex "Adress of blob settings in flash (copy 2)"
default 0x7e000

But 0x7F000 ???? What is this doing there??

Exception, reset and watchdog in ESP8266

If you have experienced that the system does NOT reboot when the watchdog comes after an exception, don’t get fooled. It might be caused by the GPIO configuration of your chip. If you are using GPIO0 and GPIO2 (for example, in an ESP12 module) in your application, remember that this pins are also used for choosing the boot mode of your ESP8266

MTDO GPIO0 GPIO2 Mode Description
L L H UART Download code from UART
L H H Flash Boot from SPI Flash
H x x SDIO Boot from SD-card

The guys from Espressif shoud have some precautions when the exception handler is called. Before sending the chip to reset, all the GPIOs should be placed into HiZ with internal pull-ups, then wait a little bit, and finally go to reset.

However they don’t do it, and when the WDT reset comes, if your GPIO0 is down because you own application is forcing it, the system won’t recover, and will stay in flash update forever!!!

(by the way, flash update should also have a timeout to jump into normal boot mode, but I guess this is silicon issue)

Downloading problems with esptool

Many people around have this problem: http://www.esp8266.com/viewtopic.php?f=6&t=2791

Well. Read carefully if you develop under windows:

If you have experienced problems while flashing with esptool and other tools (ESP8266Flasher.exe, flash_download_tool_v1.2_150512.exe, etc), this might give you a clue.

If you are trying to flash the ESP8266 (ESP12 module for example) and your flashing operation hangs in the middle of the procedure, pay attention to this. It can save you a lot of time…

Depending on which USB to TTL converter you are using, the system might not work correctly. There must be something about buffering or drivers or something in Windows that makes a strong difference whether you are using one converter or another.

Validated USB to TTL (these are known to work)
– TTL-232R-3V3-PCB from FTDI
– Silicon Labs CP210x USB to UART bridges

Known that does not work:
– Prolific based USB to TTL converters

If you have a Prolific USB to UART bridge, you might try to make it work by changing the esptool.py by reducing the packet size of the flash transmission
ESP_RAM_BLOCK = 0x180
ESP_FLASH_BLOCK = 0x40

Kind regards,

Juan Ramón Vadillo

ESP8266 Fatal exception

Ok, so you have this…

Fatal exception (28):

epc1=0x40245f15, epc2=0x00000000, epc3=0x401012b6, excvaddr=0x00000004, depc=0x00000000

 ets Jan  8 2013,rst cause:1, boot mode:(1,3)

 ets Jan  8 2013,rst cause:4, boot mode:(1,3)

wdt reset

  If you want to find the origin of your problem, you can disassemble the .out elf file that has been produced during compilation. To do it, just type:

 

C:\ESP8266\ESP8266windev\xtensa-lx106-elf\bin\xtensa-lx106-elf-objdump.exe -d esp8266_at.out >disassemble.txt

 

Now find 40245f15 and you will see where the error appears.