ESP8266 Community Forum

- Sun Nov 16, 2014 1:16 pm #2748

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

That's rather strange. I uploaded stuff to the chip many hundreds of times by now. Large as well as small stuff, and never had any problem. Check that you use the proper addresses and linker script. That is, the addresses/regions in the linker script must match where you upload it later on. There are several linker scripts, two of them for the OTA update which use different memory layouts and require an additional bootloader as well.

Not sure how the ESP handles it, but on many micros an "empty" memory word will be interpreted as a NOP, so it may be that you have linked the code in a way that it ends up at the wrong address, the bootloader jumping into one of the empty regions, doing a lot of NOP's before hitting the actual code?

Greetings,

Chris

- Sun Nov 16, 2014 11:46 pm #2773 @Chris
Did you use the compile and link method here?
viewtopic.php?f=5&t=9&p=889#p889

Snippet from a compile.sh script to workaround esptool, random util scripts, and python scripts with missing parts...
#recover ELF bin, and parse out the resources
ELFNAME=$(ls $CWD/build/*.out)
ELFFILE=$ELFNAME

XTOBJDUMP="/opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf/xtensa-lx106-elf/bin/objdump"
XTOBJCOPY="/opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf/xtensa-lx106-elf/bin/objcopy"
XTNM="/opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf/xtensa-lx106-elf/bin/nm"

$XTOBJDUMP -x -s $ELFFILE > $CWD/firmware/eagle.app.v6.dump
$XTOBJDUMP -S $ELFFILE > $CWD/firmware/eagle.app.v6.S

$XTOBJCOPY --only-section .text -O binary $ELFFILE $CWD/firmware/eagle.app.v6.text.bin
$XTOBJCOPY --only-section .data -O binary $ELFFILE $CWD/firmware/eagle.app.v6.data.bin
$XTOBJCOPY --only-section .rodata -O binary $ELFFILE $CWD/firmware/eagle.app.v6.rodata.bin
$XTOBJCOPY --only-section .irom0.text -O binary $ELFFILE $CWD/firmware/eagle.app.v6.irom0text.bin

#TODO: port/debug the python scripts that seem to be currently running Windows Only .exe
#these build scripts are missing resources with the wiki tar ball
/opt/Espressif/ESP8266_SDK/tools/gen_appbin.py $ELFFILE v6
#genflashbinv6 does not exist
#/opt/Espressif/ESP8266_SDK/tools/gen_flashbin.py

Perhaps someone has a better solution?

- Mon Nov 17, 2014 1:01 am #2775

@Chris
Did you use the compile and link method here?
[...snip...]

What you linked to is one of the reasons why i wrote my esptool. The method in your link basically just extracts the segments needed and then passes them to an extra script, hoping that all the addresses match. That is, the addresses of the extracted segment and the ones that the script assembles them into. My esptool uses the addresses that are given in the linked ELF file, so there can be no messing up. Of course that applies only to the final binaries/firmware-file. For now the user is still to take care that the files are uploaded to the proper addresses in the flash (something that will be fixed in the next version). However, as far as the main firmware file is concerned, my tool creates it with the addresses as they appear in thhe ELF file.

But still, assuming that you use the proper linker script, that is, the one that creates the irom0 segment at 0x40000, the python esptool as well as my tool should work just fine.

As long as you need to add "blank" data areas to the uploaded file, you are doing something wrong. It simply is not needed. Again: The bootloader takes the start address and size, then erases the given space, gives an OK, and then writes the uploaded data there. That is: it does not erase all the flash, only the space needed for the binary files.

Greetings,

Chris

- Mon Nov 17, 2014 1:43 am #2776

As long as you need to add "blank" data areas to the uploaded file, you are doing something wrong. It simply is not needed.

There is a use case for creating a single flashable binary - some people use espflasher.exe which apparently doesn't handle offsets correctly. They need something that starts at zero offset and contains everything.

Side note: Chris, is it possible to flash two parts of the image in a single go, without resetting the chip, with your tool?