ESP8266 Community Forum

- Sun Nov 16, 2014 6:40 am #2722

Since the esptool wipes the entire flash before flashing (not only the region for specific file) it's better to flash one big file instead.

Where do you get the idea from that the tool erases the whole flash? I assume you speak about either the esptool.py or my esptool, right? None of which erase the whole flash when uploading data. They send a "start flash" command to the bootloader, including the size of the data to be uploaded. The bootloader then erases that amount of flash at the given address, gives a response to the tool once done, and then the tool uploads the data.

Greetings,

Chris

- Sun Nov 16, 2014 7:10 am #2726 This is what I use to combine binaries in my makefile.
Difference is that empty part is filled with ff's instead of zeros. And it takes just 3 lines

Code: Select all   dd if=/dev/zero ibs=4k count=124 | LC_ALL=C tr "\000" "\377" >$(FULL_FW)
   dd if=$(APP_FW_1) of=$(FULL_FW) bs=4k seek=0 conv=notrunc
   dd if=$(APP_FW_2) of=$(FULL_FW) bs=4k seek=64 conv=notrunc


edit: to add other bin's, increase count in the first line to match total size (4k blocks), and add another dd command to paste contents where appropriate.

- Sun Nov 16, 2014 7:56 am #2729 I tried a similar method to igrr,
still no brick'n joy... =(

I have posted the bin image for someone to try on other hardware.
Also, the Makefile and compile.sh flash image patch script is included....

esp_sources.zip

Note, it does not work...

I did get some activity when I put a bogus offset of negative 1 for the image patching, at least the garbage output let me know it is trying to process the memory regions on this unit.

EDIT:
Ok, at least I can unbrick this device now by using the single image write script and these pre-built bins...

flash_to_esp.bin.zip

=)

However, I still can't load a working bin image after checking the output of both the wiki install method and the newest posted GCC compiler

build.sh.zip

This means that the flash write tools work with the threads build script output, and can be verified with legacy binaries. However, either both GCC compilers are corrupting the output, or the common repo version of esptool is incorrectly parsing the output on this platform.`
I also tried the 32bit deb pkg for esptool 0.0.2 , and still no magic:
https://github.com/esp8266/esp8266-wiki ... rig.tar.gz
https://github.com/esp8266/esp8266-wiki ... 1_i386.deb

You do not have the required permissions to view the files attached to this post.

- Sun Nov 16, 2014 11:00 am #2739

Since the esptool wipes the entire flash before flashing (not only the region for specific file) it's better to flash one big file instead.

Where do you get the idea from that the tool erases the whole flash? I assume you speak about either the esptool.py or my esptool, right? None of which erase the whole flash when uploading data. They send a "start flash" command to the bootloader, including the size of the data to be uploaded. The bootloader then erases that amount of flash at the given address, gives a response to the tool once done, and then the tool uploads the data.

Greetings,

Chris

Well, that might have been a wrong preassumption about wiping entire flash (by esptool.py), but since flashing just 0x00000.bin and 0x400000.bin did not work as opposed to adding blank areas and esp_init_data_default.bin to appropriate flash areas it needs to be noted that there is something wrong with flashing process when the files are separated. Maybe it is related with erase page size padded to some size like 1K,4K, etc. that causes unwanted memory area erasure.

Greetings,
McGr3g0r