ESP8266 4MB with relay from "AI-cloud inside" : issues

[picpic020960]

Bonjour
micropython firmware in loaded but no REPL.
in dump memory i see micropython is started , some data writed after the firmware .
verify-flash

esptool verify-flash --diff 0 Téléchargements/ESP8266_GENERIC-20251209-v1.27.0.bin
esptool v5.1.0
Connected to ESP8266 on /dev/ttyUSB0:
Chip type:          ESP8266EX
Features:           Wi-Fi, 160MHz
Crystal frequency:  26MHz
MAC:                b4:e6:2d:67:82:52

Stub flasher is already running. No upload is necessary.

Configuring flash size...
Verifying 0x9c740 (640832) bytes at 0x00000000 in flash against 'Téléchargements/ESP8266_GENERIC-20251209-v1.27.0.bin'...

Verification failed: 1 differences, first at 0x00000003:
   0x00000003 40 20

Hard resetting via RTS pin...

A fatal error occurred: Verification failed.

is it possible to patch memory ?
what is this info in first bytes of memory ?

thanks for help
Regards

[Josverl]

Hello,
Can you explain what you are trying to accomplish ?
Is it that the esp8266 does not run as expected ?
If so did you erase the flash , what command(s) did you use to flash the device ?

The below may be relevant to the difference - but I did not directly verify this on hardware myself:
The first few bytes of an ESP8266 firmware image contain the Image Header, which tells the bootloader how to load the firmware and configure the hardware.

• https://docs.espressif.com/projects/esptool/en/latest/esp8266/advanced-topics/firmware-image-format.html

Here is the breakdown of the first 4 bytes:

• Byte 0 (0x00): Magic Byte (Always 0xE9)
• Byte 1 (0x01): Number of memory segments
• Byte 2 (0x02): SPI Flash Interface Mode (e.g., QIO, DIO, DOUT)
• Byte 3 (0x03): SPI Flash Size and Speed

The difference is specifically at Byte 3. When you flash a .bin file to an ESP8266 using esptool.py write_flash, esptool typically auto-detects your physical flash memory size and speed and dynamically modifies Byte 2 and Byte 3 on the fly to match your hardware. However, when you run verify-flash, it compares the raw .bin file (which still has the generic defaults compiled into it, like 0x40 or 0x20) with the customized header now sitting on the chip. Because esptool patched the header during flashing, the verification fails at byte 3.

[picpic020960]

OK so the verify is 'good'
After the firmware loaded and the REPL not started, with esptool read-flash i see some data after the end of the firmware, for example MicrophyhonN (the password of the wifi AP) and the right of the mac address. So i think that micropython initialisation is started but not the REPL.
One time partial "reset message" was display
Any ideas ?

[Josverl]

The esp8266 "remembers" the AP and password - in plain text in flash - possibly
that is what you are seeing.

1. did you erase the flash ?

if you did not - MicroPython could be trying to load a block of <garbage/white noise/corrupted filesystem>
It should recover from that - but that is no guaranteel
the safe way is to erase: esptool.py --port /dev/ttyXXX erase_flash , then re-flash

2. what command(s) did you use to flash the device ?

[picpic020960]

I have erased then write the memory.

Maybe the esp8266 is slow for initialize the flash user memory, the global size is 4MB.

I will more test.

[Josverl]

hmm - just understanding that you may have a board with less flash than I assumed

To see how much flash memory your board has run: esptool flash-id
It should give you something like :

esptool v5.2.0
Connected to ESP8266 on COM17:
Chip type:          ESP8266EX
Features:           Wi-Fi, 160MHz
Crystal frequency:  26MHz
MAC:                84:cc:a8:b0:81:53

Stub flasher running.

Flash Memory Information:
=========================
Manufacturer: 0b
Device: 4016
Detected flash size: 4MB

Hard resetting via RTS pin...

if it is less than 2MB you will need a different firmware image.

from the download page

For boards with 1MiB or 512kiB of flash, two variants are provided with reduced functionality. The 1MiB variant removes asyncio and FAT-filesystem support as well as some modules from micropython-lib. The 512kiB variant further removes all filesystem support, as well as framebuffer support, some Python language features, and has less detailed error messages.

---

based on the diff you shared earlier :

0x00000003 40 20

• 0x20
  • 2 = 1 MB flash size
  • 0 = 40 MHz speed

Meaning: When esptool flashed your board, it auto-detected that your specific ESP8266 actually only has a 1 MB flash chip.

So you will need the Firmware (1MiB flash) firmware variant.

[picpic020960]

my 'esptool flash-id' is same as your.

esptool flash-id
esptool v5.1.0
Connected to ESP8266 on /dev/ttyUSB0:
Chip type:          ESP8266EX
Features:           Wi-Fi, 160MHz
Crystal frequency:  26MHz
MAC:                b4:e6:2d:67:82:52

Stub flasher running.

Flash Memory Information:
=========================
Manufacturer: 5e
Device: 4016
Detected flash size: 4MB

Hard resetting via RTS pin...

i will test with smaller firmware
my board maybe bad clone ...

[picpic020960]

with the first firmware , i dump this :

003fd0a0  ff ff ff ff ff ff ff ff  ff 00 ff ff ff ff ff ff  |................|
003fd0b0  12 00 00 00 4d 69 63 72  6f 50 79 74 68 6f 6e 2d  |....MicroPython-|
003fd0c0  36 37 38 32 35 32 00 00  00 00 00 00 00 00 00 00  |678252..........|
003fd0d0  00 00 00 00 6d 69 63 72  6f 70 79 74 68 6f 4e 00  |....micropythoN.|
003fd0e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

so the memory size is 4MB.
with the smaller firmware (512k), no REPL.
NB : firmware end address 7a6f0 , memory end address 80000 : short

[Josverl]

you have still not shared what the command or tool is that you are flashing with
so sorry - im out of suggestions

[robert-hh]

I did not follow the tracks, and _ do not know if you connect the ESP8266's TX directly to a dumb terminal or through an IDE. But it might be useful to try all flash mode options. For some low cost devices, using DOUT as flash mode worked, which otherwise would not boot. The sign of the wrong flash moder was usually, that after power on the device is in a reboot loop and spits out junk, at it's boot UART speed of 74880 baud. Normally. you would just see a short boot message at that speed.

[picpic020960]

all is good. wire issue at REPL. the chip has 4MB flash memory. the verify is KO/OK.
Thank's for help

question : why Micropython-xx.xx.xx AP (xx:xx:xx the right of mac address) and when is it started ?

[Josverl]

why Micropython-xx.xx.xx AP

So you can distinguish multiple devices