One of the IoT platforms I’ve been playing with is the ESP8266, which is a pretty incredible little chip with dev boards available for under £4. Arduino and Micropython are both great development platforms for them, but the first board I bought (back in 2016) only had a 4Mbit flash chip. As a result I spent some time writing against the Espressif C SDK and trying to fit everything into less than 256KB so that the flash could hold 2 images and allow over the air updates. Annoyingly just as I was getting to the point of success with Richard Burton’s rBoot my device started misbehaving, even when I went back to the default boot loader:
ets Jan 8 2013,rst cause:1, boot mode:(3,6) load 0x40100000, len 816, room 16 tail 0 chksum 0x8d load 0x3ffe8000, len 788, room 8 tail 12 chksum 0xcf ho 0 tail 12 room 4 load 0x3ffe8314, len 288, room 12 tail 4 chksum 0xcf csum 0xcf 2nd boot version : 1.2 SPI Speed : 40MHz SPI Mode : DIO SPI Flash Size : 4Mbit jump to run user1 Fatal exception (0): epc1=0x402015a4, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000 Fatal exception (0): epc1=0x402015a4, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000 Fatal exception (0):
Various things suggested this was a bad flash. I tried a clean Micropython install, a restore of the original AT firmware backup I’d taken, and lots of different combinations of my own code/the blinkenlights demo and rBoot/Espressif’s bootloader. I made sure my 3.3v supply had enough oompf (I’d previously been cheating and using the built in FT232RL regulator, which doesn’t have quite enough when the device is fully operational, rather than in UART boot mode, such as doing an OTA flash). No joy. I gave up and moved on to one of the other ESP8266 modules I had, with a greater amount of flash. However I was curious about whether this was simply a case of the flash chip wearing out (various sites claim the cheap ones on some dev boards will die after a fairly small number of programming cycles). So I ordered some 16Mb devices - cheap enough to make it worth trying out, but also giving a useful bump in space.
They arrived this week and I set about removing the old chip and soldering on the new one (Andreas Spiess has a useful video of this, or there’s Pete Scargill’s write up). Powered it all up, ran
esptool.py flash_id to see that it was correctly detected as a 16Mb/2MB device and set about flashing my app onto it. Only to get:
ets Jan 8 2013,rst cause:2, boot mode:(3,3) load 0x40100000, len 612, room 16 tail 4 chksum 0xfd load 0x88380000, len 565951362, room 4 flash read err, ets_unpack_flash_code ets_main.c
Ooops. I had better luck with a complete flash erase (
esptool.py erase_flash) and then a full program of Micropython using
esptool.py --baud 460800 write_flash --flash_size=detect -fm dio 0 esp8266-20180511-v1.9.4.bin, which at least convinced me I’d managed to solder the new chip on correctly. Further experimention revealed I needed to pass all of the flash parameters to
esptool.py to get rBoot entirely happy, and include
esp_init_data_default.bin (FWIW I updated everything to v2.2.1 as part of the process):
esptool.py write_flash --flash_size=16m -fm dio 0x0 rboot.bin 0x2000 rom0.bin \ 0x120000 rom1.bin 0x1fc000 esp_init_data_default_v08.bin
Which gives (at the default 76200 of the bootloader bit):
ets Jan 8 2013,rst cause:1, boot mode:(3,7) load 0x40100000, len 1328, room 16 tail 0 chksum 0x12 load 0x3ffe8000, len 604, room 8 tail 4 chksum 0x34 csum 0x34 rBoot v1.4.2 - email@example.com Flash Size: 16 Mbit Flash Mode: DIO Flash Speed: 40 MHz Booting rom 0. rf cal sector: 507 freq trace enable 0 rf
Given the cost of the modules it wasn’t really worth my time and energy to actually fix the broken one rather than buying a new one, but it was rewarding to be sure of the root cause. Hopefully this post at least serves to help anyone seeing the same exception messages determine that there’s a good chance their flash has died, and that a replacement may sort the problem.