Вопросы по esptools.exe

[pvvx]

mingw32-make.exe -f E:/ESP8266/workspace/Web_base/Makefile FlashAll
c:/Espressif/utils/esptool.exe -p COM6 -b 230400 write_flash -ff 80m -fm qio -fs 4m 0x00000 ./bin/0x00000.bin 0x0A000 ./webbin/WEBFiles.bin 0x40000 bin/0x40000.bin 0x7c000 ./bin/esp_init_data_default.bin 0x7E000 ./bin/blank.bin
Entering bootloader...
Connecting...
Erasing flash...

Writing at 0x00000000... (3 %)
....
Writing at 0x00008000... (100 %)
Erasing flash...

Writing at 0x0000a000... (1 %)
....
Writing at 0x00019400... (100 %)
Erasing flash...

Writing at 0x00040000... (0 %)
...
Writing at 0x0006a400... (100 %)
Erasing flash...

Writing at 0x0007c000... (100 %)
Erasing flash...

Writing at 0x0007e000... (25 %)
...
Writing at 0x0007ec00... (100 %)

Leaving...

Disk init: 33 files, addr = 0x0000a000

mingw32-make.exe -f E:/ESP8266/workspace/Web_base/Makefile Test
c:/Espressif/utils/esptool.exe -p COM6 -b 230400 write_flash -ff 80m -fm qio -fs 4m -ff 80m -fm qio -fs 4m 0x00000 ./bin/0x00000.bin 0x79000 ./bin/clear_eep.bin 0x7c000 ./bin/esp_init_data_default.bin 0x7E000 ./bin/blank.bin
Entering bootloader...
Connecting...
Erasing flash...

Writing at 0x00000000... (3 %)
....
Writing at 0x00008000... (100 %)
Erasing flash...

Writing at 0x00079000... (8 %)
...
Writing at 0x0007bc00... (100 %)
Erasing flash...

Writing at 0x0007c000... (100 %)
Erasing flash...

Writing at 0x0007e000... (25 %)
...
Writing at 0x0007ec00... (100 %)

Leaving...

Disk init: 0 files, addr = 0x0000a000
И без разницы, где диск сидит в области между 0x00000 файлом и 0x40000 - при их записи его стрирает.
Если у вас не вышло - значит прикол ещё забавнее Он был ещё с прошлой версии. Мне писали, что прошивают, а диска нет....

 

[CHERTS]

И без разницы, где диск сидит в области между 0x00000 файлом и 0x40000 - при их записи его стрирает.
Если у вас не вышло - значит прикол ещё забавнее

Возможно раз на раз не приходится, чтобы не мучиться и избежать таких приколов нужно собирать единый файл прошивки и не бить её на части, это конечно не сильно удобно, но зато гарантирует, что некоторые области не будут стёрты.

Общий файл из разных частей можно собрать так, кусок из Makefile esphttpd (этот Makefile не входит в DevKit, см. вложение)

FW_BASE = firmware
XTENSA_TOOLS_ROOT ?= c:/Espressif/xtensa-lx106-elf/bin
SDK_TOOLS ?= c:/Espressif/utils
OBJCOPY := $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-objcopy
OBJDUMP := $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-objdump
...
flashonefile: all webpages.espfs
$(vecho) "Run objcopy, please wait..."
$(OBJCOPY) --only-section .text -O binary $(TARGET_OUT) eagle.app.v6.text.bin
$(OBJCOPY) --only-section .data -O binary $(TARGET_OUT) eagle.app.v6.data.bin
$(OBJCOPY) --only-section .rodata -O binary $(TARGET_OUT) eagle.app.v6.rodata.bin
$(OBJCOPY) --only-section .irom0.text -O binary $(TARGET_OUT) eagle.app.v6.irom0text.bin
$(vecho) "objcopy done"
$(SDK_TOOLS)/gen_appbin_old.exe $(TARGET_OUT) v6
$(SDK_TOOLS)/gen_flashbin.exe eagle.app.v6.flash.bin $(FW_BASE)/webpages.espfs 0x12000
rm -f eagle.app.v6.flash.bin
mv eagle.app.flash.bin eagle.app.v6.flash.bin
$(SDK_TOOLS)/gen_flashbin.exe eagle.app.v6.flash.bin eagle.app.v6.irom0text.bin 0x40000
rm -f eagle.app.v6.data.bin
rm -f eagle.app.v6.flash.bin
rm -f eagle.app.v6.irom0text.bin
rm -f eagle.app.v6.rodata.bin
rm -f eagle.app.v6.text.bin
rm -f eagle.app.sym
mv eagle.app.flash.bin $(FW_BASE)/
$(vecho) "Generate eagle.app.flash.bin successully in folder $(FW_BASE)."
$(vecho) "eagle.app.flash.bin-------->0x00000"

webpages.espfs: firmware cleanwebpages
cd html; find | ../mkespfsimage/mkespfsimage.exe > ../$(FW_BASE)/webpages.espfs; cd ..

Строки помеченные красным выполняются нужное количество раз с указанием нужных файлов секций с нужными адресами, главное соблюдать порядок адресов друг за другом.
Итого на выходе получаем один eagle.app.flash.bin

 

[pvvx]

Фиксировано. При такой записи:

mingw32-make.exe -f E:/ESP8266/workspace/Web_base/Makefile FlashCode
c:/Espressif/utils/esptool.exe -p COM6 -b 230400 write_flash -ff 80m -fm qio -fs 4m 0x00000 ./bin/0x00000.bin 0x40000 bin/0x40000.bin
Entering bootloader...
Connecting...
Erasing flash...

Writing at 0x00000000... (3 %)
....
Writing at 0x00008000... (100 %)
Erasing flash...

Writing at 0x00040000... (0 %)
....
Writing at 0x0006a400... (100 %)

Leaving...

Стирает всё до 0x12000. (первый файл 0x00000.bin, имеет длину 0x82b0 байт)
Вы специально прикололись -> write_flash 0x12000 firmware/webpages.espfs ?
Сделал вывод hexdamp-а в web-е без диска:

 

[CHERTS]

Там ещё фича есть. Если дать опции -ff 80m -fm qio -fs 4m при создании бинарника (команда elf2image), то при загрузке (write_flash) по умолчанию все равно надо давать их опять. Иначе ff 40MHz и т.д.

Кстати, если использовать новую gen_appbin.exe то в ней тоже есть опции flash_mode, flash_freq и flash_size и соответственно она на выходе выдает eagle.flash.bin и eagle.irom0text.bin, прошиваются на 0x00000 и 0x40000, в новых DevKit я скорректировал все Makefile и в них появились опции SPI_SPEED, SPI_MODE и SPI_SIZE и в них же для сборки прошивок теперь НЕ ИСПОЛЬЗУЕТСЯ esptool.exe, а используется как раз новый gen_appbin.exe (цель all).
Так вот к чему я это, я конечно не могу проверить будут ли шиться и работать eagle.flash.bin и eagle.irom0text.bin на flash-памяти >512k при использовании esptool.exe без указания опций -ff -fm -fs, но мне кажется что все будет прошиваться и работать, ибо в esptool.py используется для сборки прошивки тот же принцип, что и в моих новых Makefile c с использованием gen_appbin.exe

 

[CHERTS]

Вы специально прикололись -> write_flash 0x12000 firmware/webpages.espfs ?

Нет, это не я, а разработчик esphttpd.

 

[pvvx]

Кстати, если использовать новую gen_appbin.exe

Он молчаливый и не отдает опций без IDA
Он может прошивать сразу 10-ть файлов подряд?
У FLASH_DOWNLOAD_TOOLS_v0.9.3.1 с большими flash была беда. Если начинать писать с адреса менее пару мегабайт и до конца 16Мег, то он работал. Если писать в конец большой Flash, то нет.
Запись малой flash тоже работает в круговую - она дублируется в выше адресах. (это к тому, что и вы можете проверить запись, к примеру, в 16-ый мегабайт)
В связи с C++ и "мало памяти" в ближайшее время для сборки потребуется модификация с выбором сегментов и их адресов. А gen_appbin.exe это не может.

 

[CHERTS]

Он молчаливый и не отдает опций без IDA
Он можетпрошивать сразу 10-ть файлов подряд?

Эмм, что бы это значило?
gen_appbin.exe это скомпиленый gen_appbin.py и у него открыты исходники, можно всегда подправить под свои нужды
В текущем виде gen_appbin.exe собирает 2-х файловую прошивку (одно-файловую для использования с boot_v1.2 или boot_v1.1 - я фиг знает что это за загрузчики от Espressif) из нескольких файлов, полученных с помощью objcopy.
Собственно esptool.exe делает по сути тоже самое с использованием того же objcopy и далее склейкой секций text, data, rodata и irom0.text в 2 файла

 

[CHERTS]

В связи с C++ и "мало памяти" в ближайшее время для сборки потребуется модификация с выбором сегментов и их адресов. А gen_appbin.exe это не может.

Ну gen_appbin.py это поделка от Espressif, поэтому ждать от неё много не приходится, а esptool.py мне не нравится потому, что написана на питоне и не сильно автономна в отличии от esptool-ck.exe, который написан на Си.

 

[pvvx]

Итого: esptool.py при записи затирает размер больше чем пишет. Это грозит такой бякой:

C:\Espressif\utils>esptool.exe -p COM6 write_flash 0x6A000 E:\ESP8266\workspace\Web_base\PVFS2.exe
Entering bootloader...
Connecting...
Erasing flash...
Writing at 0x0007a000... (100 %)

Leaving...

Размер PVFS2.exe = 66048 байт. Его запись кончилась, как видим и отображает программа на адресах "Writing at 0x0007a000..." 0x6a000 + 66048 = 0x7A200.
Вывод размеров и адресов в блоках стирания из кодов питона я делал (и esptool.py запускал тоже) - там всё совпадает с указанной длиной блока стирания в ESP_FLASH_BLOCK = 0x400.
Но, после этой записи стерто начало flash и Bios загрузчик, естественно, пишет user_main.c и ничего более.
Как и говорил - flash отображается в круговую и затерто начало до адреса 0x1000, т.е. оно, приведение, потерло всё до адреса 0x81000
Модуль ESP-12, крышку не открывал, а у открытых из той-же партии стандартная китай flash и ID совпадают. Походу, на вскидку, беда не в esptool.py и программа что на СИ, да хоть на перфокартах не поможет. Надо копать глубже. Чипы ESP8266 на модулях ESP-12 имеют новую маркировку (в более новой партии и краска другая) и отличаются от ESP-01. Так-же отличается уровень внутреннего напряжения у ADC к передатчику. Возможно новая Bios или ?...

 

[SpLab]

Итого: esptool.py при записи затирает размер больше чем пишет.
...
Вывод размеров и адресов в блоках стирания из кодов питона я делал (и esptool.py запускал тоже) - там всё совпадает с указанной длиной блока стирания в ESP_FLASH_BLOCK = 0x400.
Но, после этой записи стерто начало flash и Bios загрузчик, естественно, пишет user_main.c и ничего более.
Как и говорил - flash отображается в круговую и затерто начало до адреса 0x1000, т.е. оно, приведение, потерло всё до адреса 0x81000
Модуль ESP-12, крышку не открывал, а у открытых из той-же партии стандартная китай flash и ID совпадают. Походу, на вскидку, беда не в esptool.py и программа что на СИ, да хоть на перфокартах не поможет. Надо копать глубже. Чипы ESP8266 на модулях ESP-12 имеют новую маркировку (в более новой партии и краска другая) и отличаются от ESP-01. Так-же отличается уровень внутреннего напряжения у ADC к передатчику. Возможно новая Bios или ?...

Чтобы не страдать ерундой, а заняться полезным делом, pvvx предложил мне принять участие в анализе затирания области flash большей чем записываемый бинарник. В общем проанализировал: все плохо Проблема кроется в резидентной прошивке ESP8266. Там закралась ошибка в функции SPIEraseArea. Я отреверсил: результат во вложении. Ошибка в том, что переменная var_r_13 должна была быть сохранена после строки 37 для ее использования в строке 42, но это сделать забыли и теперь мы имеем:
стирание идет кратно сектору (по умолчанию 4096 байт);
если бинарник занимает менее 2-х блоков (1-й блок частично или полностью, 2-й только частично), то затирается
2*x секторов,
где x = (размер биарника/размер сектора) с округлением в большую сторону;
если более 2-х блоков, стирается
x + размер_блока*( целая_часть(x/размер_блока)) + остаток_от_деления(x/размер_блока)
кажется так ...
т.о. даже если писать по одному сектору, стираться будет как минимум два
На мой взгляд выход из данной ситуации очевиден - нужно использовать отдельный загрузчик, который esptool будет кидать в RAM и стартовать его оттуда. Думаю для уважаемого pvvx не составит труда написать такой загрузчик т.к. он уже разобрался с тонкостями чтения/записи SPIFlash. Вот только кто допишет esptool, а лучше еще и закоммитит эти изменения в основной репозиторий программы?

 

[pvvx]

Всё проще - забывается сколько секторов (сектор = 4096 байт) стерто c начала до кратности адреса блокам стирания (блок = 65536 байт). После стирания блоков, если они вошли или нет в размер стирания, всегда еще раз стирается то начальное кол-во секторов. Лечиться в питоне разбивкой вызова этой "стиралки" на несколько вызовов, с учетом кратности до адреса блока стирания и подстановкой кривых параметров. Ничего писать в IRAM не требуется. Но ограничение в минимальную область стирания в 2 сектора остается.

 

[SpLab]

...всегда еще раз стирается то начальное кол-во секторов.

Я неудачно назвал переменную firs_sec_erase, нужно было ее назвать current_sec_erase. Т.к. эта переменна инкрементируется в каждом из циклов, то стирание продолжается с последнего стертого сектора. Т.о. стирается не то начальное кол-во секторов, а столько же секторов вконце - это если бинарник не занимает полный блок. Если бинарник занимает полный блок, то стирается гораздо больше. Сейчас набросаю консольку для визуализации.

 

[pvvx]

Я неудачно назвал переменную firs_sec_erase, нужно было ее назвать current_sec_erase.

Описать словами сложно. Я проверил с реальностью по стертым областям и в дизасме, с учетом как это было написано в СИ в предполагаемом исходнике. Не ту переменную использовал программист BIOS в хвосте посекторного стирания, от этого и вся беда.
Появится CHERTS - пусть выдумывает как исправлять эту "фичу". Без него мы не можем вставить в UDK ничего...
SpLab - сообщите о найденной баге на http://www.esp8266.com/ - пусть правят esptool.py

 

[SpLab]

У меня есть сомнение что все ревизии чипа идут с этим багом. Возможно его исправили или исправят в будущих ревизиях и тогда внесение изменений в прошивальщик сломают функцию стирания в будущем. Нужн0 как-то строго идентифицировать наличие этого бага в чипе. К сожалению в IROM кажется нет версии по которой можно было бы идентифицировать наличие этого бага.

Описать словами сложно. Я проверил с реальностью по стертым областям и в дизасме, с учетом как это было написано в СИ в предполагаемом исходнике. Не ту переменную использовал программист BIOS в хвосте посекторного стирания, от этого и вся беда.

Кажется придумал более правильную формулировку:
если стираемая область выходит за пределы одного блока:
стирается заданная длинна округленная до сектора + количество секторов до конца первого блока;
если стираемая область не выходит за пределы одного блока:
стираются две заданные длины округленные до сектора.
Визуализация во вложении. Если раскомментировать #define bug_patch, то будет считать правильно.

SpLab - сообщите о найденной баге на http://www.esp8266.com/ - пусть правят esptool.py

К сожалению не дружу с английским: читать запросто, а вот что-то связанно написать - увы, боюсь меня просто не поймут.
Вроде у CHERTS есть право коммитить в репозиторий esptool.py Впринципе если функция 0x02 Flash Download Start только стирает область и потом не влияет на функцию 0x03 Flash Download Data, то достаточно подставить рассчитанные особым образом параметры в первую функцию и выполнять ее кусками чтобы не выходить за размер блока тогда область затрется правильно. Ограничение только на нечетное количество секторов - получится только округлять до старшего четного. Если же первая функция задает область для второй, то ничего не выйдет.

 

[pvvx]

У меня есть сомнение что все ревизии чипа идут с этим багом.

Первые ESP-01 и последняя партия чипов, устанавливаемых на ESP-12 имеют идентичную BIOS. До новых чипов надо ждать, когда распродадут старые. Это долго.

 

[CHERTS]

Появится CHERTS - пусть выдумывает как исправлять эту "фичу". Без него мы не можем вставить в UDK ничего...

Можете, присылайте исправления, я протестирую их и обновлю DevKit. Ковыряться в питоновском esptool.py к сожалению нет времени и желания, доступа в репозитарий esptool у меня нет, а последний pull request от меня они не приняли, так что ну его в баню.

 

[pvvx]

Можете, присылайте исправления, я протестирую их и обновлю DevKit. Ковыряться в питоновском esptool.py к сожалению нет времени и желания, доступа в репозитарий esptool у меня нет, а последний pull request от меня они не приняли, так что ну его в баню.

Espressif на эту ошибку опять ответил типа "про это известно и исправлено в http://bbs.espressif.com/viewtopic.php?f=7&t=25." Ну и типа "Thanks for your interest in ESP8266 !". Но с этого release_v0.9.3.1_141118 всё и начиналось у меня (лишнее стирание)... Там какая-то кривая "коррекция" есть.

 

[SpLab]

Espressif на эту ошибку опять ответил типа "про это известно и исправлено в http://bbs.espressif.com/viewtopic.php?f=7&t=25." Ну и типа "Thanks for your interest in ESP8266 !". Но с этого release_v0.9.3.1_141118 всё и начиналось у меня (лишнее стирание)... Там какая-то кривая "коррекция" есть.

Теоретически подтверждаю (практически не проверял) что по указанной Вами ссылке в питоновских исходниках, конкретно в esptool.py стр.476 и далее, внесены изменения, корректирующие баг со стиранием ровно по тому алгоритму что я описывал последним, а именно:
- если общее кол-во секторов для записи меньше количества секторов от начала записи до конца блока (т.е. не выходит за границы первого блока), то параметр size равен половине от необходимого кол-ва секторов для стирания;
- если общее кол-во секторов для записи больше количества секторов от начала записи до конца блока (т.е. выходит за границы первого блока), то параметр size равен разности общего количества секторов для записи и количества секторов до конца первого блока.
Таким образом остается ограничение на нечетное количество секторов для записи, т.е. округляться будет до ближайшего четного кол-ва секторов.
Вообще я не понимаю, если esptool.py того же автора, что и esptool.py на гитхабе (автор Fredrik Ahlberg), а в версии от espressif внесено много изменений/дополнений/багфиксов, то почему Fredrik Ahlberg не внесет эти изменения в версию на гитхабе?! Для меня ответ только один - Fredrik Ahlberg забил на свое детище и теперь его форкнула espressif прикрутивк нему GUI-обертку и назвав все это Flash download tool. Т.о. в будущем о выявленных багах теперь нужно писать на bbs.espressif.com. А в Expressif DevKIT нужно включить esptool.py в версии от Expressif.

P.S. pvvx, если у Вас действительно криво стирает именно эта версия, то может быть Вы счастливый обладатель чипа с пофиксиным BootROM Хотя в этом случае у Вас бы стиралось гораздо меньше чем нужно

 

[CHERTS]

Т.о. в будущем о выявленных багах теперь нужно писать на bbs.espressif.com. А в Expressif DevKIT нужно включить esptool.py в версии от Expressif.

Терзают меня смутные сомнения, что Espressif чихала с высокой колокольни на все наши рапорты о багах, чем они думают вообще не понятно. Со своей стороны я посмотрю исходники Flash download tool, хоть я и не силен в python, но вдруг что пойму и подправлю.

 

[CHERTS]

pvvx а можешь проверить запись прошивок утилитой esptool-ck.exe, она как затирает память.
Пример использования:
c:\Espressif\utils\esptool-ck.exe -cp COM2 -cd ck -ca 0x00000 -cf eagle.flash.bin -v
c:\Espressif\utils\esptool-ck.exe -cp COM2 -cd ck -ca 0x40000 -cf eagle.irom0text.bin -v