ESP12F: No longer able to run Arduino Sketches - How is flash organized?

I stared using ESP12 (both -E and -F) early in February 2017. After many weeks of pain needed to understand the specifics of this chip (power, capacitors, pins, brand of the USB-Serial adapter, etc.) I finally managed to upload some sketches made in Arduino IDE and I developed some applications for my personal use. I remember all those chips, out-of-the box presented the so-called AT firmware. In addition, after a while, I managed to successfully update the basic firmware from 1.5.0 to 2.0.0 and my Arduino-like sketches continue to work. To upload, I used both the Espressif GUI tool that the esptool.py on Windows or Linux. I think I also learned the meaning of NONOS/OS and OTA/no OTA and I can say I need NONOS and no OTA!

Those 4 chips of my first lots (2 ESP12E and 2 ESP12F), had a small, round, AI logo on top as well as the "Vendor: Ai-Thinker" statement:

Now I bought 4 ESP12-F. There is no AI logo or Vendor: Ai-Thinker statement on them, just: "WiFi ESP-12F / ESP8266MOD / FC / ISM 2.4Ghz / PA +25 dBm / 802.11 b/g/n":

At power on, on the serial port I see some messages at 74880 (normal):

oad 0x3ffe8000, len 776, room 8
tail 0
chksum 0x02
load 0x3ffe8310, len 552, room 8
tail 0
chksum 0x79
csum 0x79

2nd boot version : 1.5
  SPI Speed      : 40MHz
  SPI Mode       : DIO
  SPI Flash Size & Map: 32Mbit(512KB+512KB)
jump to run user1 @ 1000

rf cal sector: 1017
rf[112] : 00
rf[113] : 00
rf[114] : 01

SDK ver: 1.5.4.1(39cb9a32) compiled @ Jul  1 2016 20:04:35
phy ver: 972, pp ver: 10.1

Followed by some lines at 115200 (normal too):

Ai-Thinker Technology Co. Ltd.

ready

At this point, I tried to enter "AT", not only at 115200 but also 9600, 56400, 74880 with no result. Ok, I assumed the AT firmware is not present, no problem. I uploaded a simple and working Arduino-like sketch and I started to get all sort of errors, some at 74880 and some at 115200: huge pages of dump and messages:

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)
-------
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v3de0c112
~ld
   system param error

--- dump follows ---

and:

Exception (0):
epc1=0x4022cc40 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

ctx: sys
sp: 3ffff7d0 end: 3fffffb0 offset: 01a0

>>>stack>>>
3ffff970:  4022cc40 00000138 00000177 4022cc29

--- dump follows ---

Of course, my firts approach was to upload the 4 firmware files I used in the former chips: no success! Even if upload works fine and verify_flash reports OK, they look "incompatible" for these new chips.

Here starts my real confusion: I don't really know what the 4 (well ... 3) modules are. Save for blank.bin that, I assume, is used to clear some locations, eagle.flash.bin, eagle.irom0text.bin and esp_init_data_default.bin are totally mysterious to me!

After days, I concluded that:
blank.bin: used to clear locations.
esp_init_data_default.bin: reported as "optional", basic configuration?
eagle.flash.bin: the location to upload is 0x000, i.e. the same location where user sketches are loaded, so have I to assume this is the AT firmware?
And, at that point, can I replace it with MY sketch binary?
eagle.irom0text.bin: total mystery! Is that the basic ESP formware, i.e. what handles WiFi, IP, TCP, ect?

I also thoroughly read Pieter P's "A Beginner's Guide to the ESP8266" but I didn't find anything about ESP firmware.

Can someone clarify:
-What are the rules of the 4 modules?
-What is linked together with my sketch and uploaded to the chip?
In other words, in a NONOS/no OTA environment, is there anyway a sort of "resident" firmware or - in theory - is the product of the compile/link of my sketch enoght to handle a totally empty ESP?

My last attemt was to fill 4M with FF and then upload my sketch's .bin file. After each upload, I verify_flash and I see it is ok. But the messge on serial is:

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

load 0x4010f000, len 1384, room 16
tail 8
chksum 0xef
csum 0xef
csum err
ets_main.c

It is also confusing "chksum" and "csum" (I assume stored checksum and computed checksum) are the same but "csum err" is shown!

use the Espressif Flash Download Tool to detect parameters. perhaps the new modules have a 40 MHz crystal

Of course, that was one of the first actions I performed, but I couldn't write 5+ days testing log! I can just add that all the 4 chips behave in the same way.

flash vendor:
E0h : N/A
flash devID:
4016h
QUAD;32Mbit
crystal:
26 Mhz

In addition, some info from esptool:

read_flash_status:
Status value: 0x0000

read_mac
MAC: 18:fe:34:9e:f3:0a

chip_id
Chip ID: 0x009ef30a

flash_id
Manufacturer: e0
Device: 4016
Detected flash size: 4MB

By the way, my questions were a little bit more complex, basically: is an Arduino-IDE created .bin enough to run on an "empty" ESP? If this is not the case, what are the Espressif modules that have to be loaded in order to have an ESP running? And, finally, what is the rule of the 4 Espressif supplied binaries?

I think all the above is quite obscure to most of the ESP users!

the Arduino IDE created bin is everything. try to erase the flash with esptool. there is something in the new SDK used by the esp8266 Arduino package that is not compatible with sdk settings stored on the flash by AT firmware or older Arduino sketch

the Arduino IDE created bin is everything

Once I learned this, I saved lot of time in useless uploads and I managed to find my problem! The main problem was that I need to use DIO (or DOUT) instead of QIO. I assume this is due to a cheap Flash! In addition, I noticed a 10K resistor on GPIO0, in this last batch of ESPs I received is not enough to always enter Boot Mode. Replaced with a 3.3K seems working ok.

By the way, I discovered that, through "--flash_mode dio" modifier, the .bin can be modified during the upload phase.

I am not very convinced every ESP hobby developer knows the Espressif firmware is totally useless!

Thanks for your help - problem(s) solved.

in the detected settings you have QUAD 32Mbit. QUAD is QIO

in the detected settings you have QUAD 32Mbit. QUAD is QIO

Yes, that is the reason I never tried before DIO. I tried with 3 chips and all of them didn't work at all using QIO but work "normally" with DIO.

I don't know how detection works, do you? Where is that information gathered from? Is it related to the Flash:manufacturer? Is it written inside the resident code? For sure something is wrong here. By the way, the original flash code, dumped out, reveals it was set for DIO, so the manufacturer did know of the problem!