So I’ve finally been getting some time into using the ESP8266 chips I bought (variously, and many of) over the past month. I had some serious trouble getting them to work initially, due to a problem which I’ll be explaining in depth on another blog post. Hint: The problem wasn’t what I thought it was (or most people think it is, for that matter.)
This post is about what happens when you try to write a program (larger than 256kB) designed for the 1024kB version of the ESP-01 module to a 512kB version of the ESP-01 module.
This is what happens:
ets Jan 8 2013,rst cause:1, boot mode:(3,6) load 0x4010f000, len 1264, room 16 tail 0 chksum 0x42 csum 0x42 ~ld "@ªrjrA(!‹SËq‹Ðšv›X%.ù+Ðyêeh©."8át.ÍɪNøêI*A¬1‚-...)DЪ.B!ûþA¬!.þNé*E"HHIîA.T[MºöA,T[ͯQá"@ªRjRA(!‹SËu‹ÐšÖ›X%(ý«ÐYêeH).".át.íͪNøêÉ*E¬1‚-.1.©ÄЪ.Â!ûþA¬!.þNé*A"HhiîA.T[MºöA,T[ͯQá
This is what is supposed to happen:
. ets Jan 8 2013,rst cause:1, boot mode:(3,7) load 0x4010f000, len 1264, room 16 tail 0 chksum 0x42 csum 0x42 ~ld Reset reason: REASON_DEFAULT_RST Normal, first power-on bootup. Flash real id: 001340C8 Flash real size: 524288 Flash IDE size: 524288 Flash IDE speed: 40000000 Flash IDE mode: QIO Flash Chip configuration ok. Mounting SPIFFS. (Attempt: 00) Configuration file exists. Config file size: 118 Created buffer. Read the config file. Created DynamicJsonBuffer. JSON parsed correctly. gps 1351824120 48.76 2.30
The problem, as far as I can understand it, is that the EEPROM chip is programmed incorrectly. I suspect maybe the addresses are wrapping around somehow, or the SPIFFS area is marked as being too large. In the 1024kB memory map, the 256kB SPIFFS image gets written starting at 0xbb000, which is at the 748kB boundary. But if you try to burn this same image to a 512kB EEPROM chip, I think the addresses wrap around, and overwrite the code you are trying to run, which starts at 0x00000.
Either way, garbage input = garbage output.
The problem is that the problem behaves inconsistently as well, and for novice programmers, it may not be apparent that the cause is not software-based, but hardware-based. Keep in mind, as well, that a minimal firmware that pulls in all of the Arduino code starts at nearly 240kB code size. The only reason I thought more heavily about EEPROM size as a potential source of problems, was that by adding the ArduinoJson library, the final code size started crossing over the 256kB boundary, which was when the garbage output and chip hangs started to happen.
One other note, there’s an example called CheckFlashConfig, located in the esp8266 library examples for Arduino. I would highly recommend people to use this code to check whether you have a flash size mismatch at runtime. The ESP8266 modules don’t have consistent specs, so two ESP-01 modules could have different EEPROM chip sizes, and cause identical code to potentially error out on one of them.
Final note, there seem to be some potential problems with the SPIFFS implementation hanging if it is unable to finish running the SPIFFS.begin() call. I tried using the .begin() in a loop, generating Attempt: xx strings along the way, but the implementation would always hang if it failed to mount the SPIFFS block the first time.