0

I flashed the ESP-12E from AT firmware 2.0 (running ok) to NodeMCU (running ok). When I reflashed it back to the AT 2.0 it is stuck in endless loop on boot:

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

load 0x40100000, len 2408, room 16 
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0 
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0 
tail 8
chksum 0xd8
csum 0xd8

2nd boot version : 1.6
  SPI Speed      : 40MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 8Mbit(512KB+512KB)
no GPIO select!
jump to run user1 @ 1000

rf_cal[0] !=0x05,is 0xFF

I am sure I flashed it correctly, it was not my first flashing of AT firmware. Just to be sure:

esp_init_data_default.bin -> 0x3fc000
blank.bin -> 0x3fe000
boot_v1.6.bin -> 0x0000
user1.1024.new.2.bin -> 0x1000
blank.bin -> 0x7e000

I can even reflash it to the NodeMCU firmware and it works, but reflashing to the AT firmware ends in the same endless loop again.

I suspect the problem is in initialization data, but I'm at my wit's end with it.

migrated from stackoverflow.com Jan 20 '17 at 9:52

This question came from our site for professional and enthusiast programmers.

  • 1
    rf_cal is radio-frontend calibration data. The bootloader sees that this is erased flash data (after erasing a flash sector, the data in it becomes 0xff 0xff 0xff ...). Can you do a esptool.py erase_flash and reflash? It may be that you're flashing esp_init_data_default.bin to the wrong address thus only reading erased flash contents. The 8 mbit (1 MByte) message seems like it's not using your flash fully. This value is set by esptool.py during flashing (--flash_size). What exactly is your flash command? Can you flash default data to 0xfc000? – Maximilian Gerhardt Jan 19 '17 at 14:27
  • Maximilian, thanks for you reply. I did erasing of the flash in past. I made some new tests, read the whole 4M flash and compared it with one in a functional module and finally got it working. The critical is your last sentence. The solution: I had to flash esp_init_data_default.bin to the address 0xfc000. I found nothing about it in the documentation but this is the way I got the ESP12 to work again. Thanks! – JiriB Jan 19 '17 at 19:04
7

Full answer and writeup to the comments:

The error message is due to the bootloader trying to read the contents of its radio-frontend calibration data (hence the name rf_cal). It compares it with a magic number, 0x05, but fails because it reads 0xFF at that point. 0xff is an indication that you read data from flash which was erased. After erasing a flash-sector, the data in it becomes 0xff 0xff 0xff... Hence it seems as if the bootloader is trying to access the data from the wrong address, thus only reading erased flash data. The RF-calibration data is stored in the file esp_init_data_default.bin and must be flashed to the correct address in order for the bootloader to be able to read it.

The NodeMCU documentation tells us the needed address for esp_init_data_default.bin given the size of the flash of our ESP module:

flash addresses

The bootloader messages

2nd boot version : 1.6
SPI Speed      : 40MHz
SPI Mode       : QIO
SPI Flash Size & Map: 8Mbit(512KB+512KB)

indicate that the flashed firmware (or that what is overriden by esptool.py) uses the 8 MBit flash size. There should be two ways to fix this:

  • Put esp_init_data_default.bin to the address the 8Mbit (1 MByte) bootloader expects, which is 0xfc000
  • Force the usage of the 32 MBit (4 MByte) Flash map by giving esptool.py the parameter --flash_size 32m. This makes esptool.py overwrite a few bytes in the firmware (at 0x000000) to adapt the firmware.

By your comments, method one worked. If there are problems however with the flash or the firmware, consider also trying method 2.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.