Свой OTA

[A-l-e-x]

Всем привет!

Пишу свою прошивку. Кстати, что такое «своя прошивка»? Это писать совсем свою с нуля или как я, используя SDK?
Пишу в Eclipse под win.
Подошел к вопросу реализации OTA и конкретно застрял. Стандартная процедура OTA мне не подошла по нескольким причинам. Решил написать свою.
Eclipse создает два файла 0x00000.bin и 0x40000.bin, которые нужно записать по соответствующим адресам во флеш.
На сейчас, моя прошивка умеет взять эти два файла с web сервера, записать их в свободное место флеш и проверить контрольную сумму.
Казалось бы, осталось самое простое – скопировать новые файлы прошивки из временного места на свое место по адресам 0x00000 и 0x40000.
Если копирование первого файла (он короткий) проблем не вызывает, то на втором происходит либо зависание либо срабатывает WDT.
Как я понимаю, во время копирования, происходят обращения к флеш, что и приводит к зависанию.
Может кто-то подсказать, как правильно реализовать перезапись прошивки?
Особенно, прошу совета у vad7 т.к. я просмотрел код Rapid_Loader_OTA и понял, что мне нужно реализовать нечто подобное. Но как заставить код копирования флеш выполниться при загрузке я не понимаю.

Всем заранее спасибо за советы.

 

[vad7]

Исходник загрузчика лежит здесь: GitHub - vad7/Rapid_Loader_OTA: Esp8266 Rapid loader with Over-The-Air (OTA) updating support

copy /b rapid_loader.bin + 0x00000.bin new0x00000.bin
move new0x00000.bin 0x00000.bin

Единый файл прошивки создается так (файлы 0x00000.bin и 0x07000.bin должны лежать в папке bin):
C:/Python27/python.exe make_firmware_image.py 512 bin/

make_firmware_image.py: PowerMeter/make_firmware_image.py at master · vad7/PowerMeter · GitHub

 

[A-l-e-x]

vad7 Спасибо, буду разбираться.
А основные файлы 0x00000.bin и 0x07000.bin при добавлении кода лоадера как-то видоизменяются? Возможно, необходимо в них изменить адреса? Или просто сливаем rapid_loader.bin + 0x00000.bin в один файл?

Если файлы меняются, то на каком этапе сборки? Здесь "C:/Python27/python.exe...." ?

Если создается единый файл прошивки, то по какому адресу он заливается? 0x00000 ?

 

[pvvx]

А основные файлы 0x00000.bin и 0x07000.bin при добавлении кода лоадера как-то видоизменяются?

Нет: "просто сливаем rapid_loader.bin + 0x00000.bin в один файл"

 

[lsm]

Всем привет!
Подошел к вопросу реализации OTA и конкретно застрял. Стандартная процедура OTA мне не подошла по нескольким причинам. Решил написать свою.

https://mongoose-iot.com/docs/#/quickstart/ - последним пунктом этого Quick Start является OTA.
Можете воспользоваться готовой прошивкой, или посмотреть как реализовано: mongoose-iot/fw at master · cesanta/mongoose-iot · GitHub

 

[A-l-e-x]

lsm спасибо! Я еже во всем разобрался. Использовал rboot для смены областей загрузки и свой код для загрузки и проверки прошивки.

 

[SergeyR]

Нет: "просто сливаем rapid_loader.bin + 0x00000.bin в один файл"

Добрый день, пробовал прикрутить к своему проекту загрузчик, но ничего кроме мусора в консоль не получаю, в чём может быть косяк?

 

[SergeyR]

Добрый день, пробовал прикрутить к своему проекту загрузчик, но ничего кроме мусора в консоль не получаю, в чём может быть косяк?

Отвечу сам себе: не потребовался загрузчик, прошивку можно сменить прямо в теле программы.

 

[lsm]

Без загрузчика, по-моему, нельзя восстановиться после ошибки.
Что случится если прошивка битая, или не битая но не работает, или во время апдейта что-то сбойнет - например питание выключится?

На embedded.com есть наша статья про OTA - там расписан подход как восстанавливаться после ошибок: Updating firmware reliably

 

[pvvx]

Без загрузчика, по-моему, нельзя восстановиться после ошибки.
Что случится если прошивка битая, или не битая но не работает, или во время апдейта что-то сбойнет - например питание выключится?

На embedded.com есть наша статья про OTA - там расписан подход как восстанавливаться после ошибок: Updating firmware reliably

Не описана и не предусмотрена возможность переключения вариантов загружаемых приложений. У Realtek это устанавливается в конфигурации при программировании - загрузка другого образа по состоянию пинов при старте, так-же есть возможность закрытия части boot-лоадера через efuse. У ESP есть выбор по пинам при старте и он не изменяем - старт из RAM, старт с интерфейсом SDIO, старт с Flash, старт в UART загрузчик...

 

[lsm]

Не описана и не предусмотрена возможность переключения вариантов загружаемых приложений.

Все верно. Но такой задачи - выбор вариантов загрузки, и не стояло. Задача стояла так: апдейт прошивки по сети, так чтобы устройство не залипло. И если все-таки залипнет, неважно по какой причине - откатывалось на предыдущую прошивку.

 

[pvvx]

Для ESP8266 существуют необратимые состояния при использовании выводов, отвечающих за тип загрузки при сбоях. Часть из них решается программно, но требуется первоначальный запуск с правильно установленными пинами (и этих пинов 7 штук!). В вашей реализации это не поддерживается и система наглухо виснет, в случае сбоя и перезагрузки с ещё не установившимися состояниями на пинах из-за их использования.
Исправьте хотя-бы варианты перезагрузки в RAM. Для этого достаточно предварительно указать всего адрес загрузки кода в RAM процедуре в ROM-BIOS... Это уже исключит более половины вариантов неверных стартов при сбоях, т.к. за это отвечает часто используемый пин (GPIO0 вроде - сейчас не помню)...
-------
Примерно это:
ets_set_user_start(jump_boot); // установить адрес для возможной перезагрузки по доп. веткам ROM-BIOS

 

[karpikorn]

Здравствуйте!



Пытаюсь к своему проекту добавить возможность обновления прошивки через wifi, по средствам ОТА. Все работы произвожу в Eclipseпод Linux. Для написания прошивки использовал стандартный пример IO_demo и премер ОТА предоставленный CHERTS . ОТА в плате шьется по адресам 0х00000 и 0х40000. Получается успешно скачать прошивку с мини веб сервера, только тогда, когда размер прошивки меньше 256kb, иначе скачивается только часть прошивки-те самые 256kb- и происходит сброс по wdt. Я пришел к выводу, что допустимый размер прошивки ограничен, но где он ограничен, мне не ясно, так как esp это 12e со встроенной флеш размером 32Mbit, то по умолчанию для user1 и user2 должна быть выделена память либо 512+512, либо 1024+1024, в обоих случаях прошивка размером больше 256kb должна помещаться, чего не происходит. Так же меня посещают сомнения в правильности метода, выбранного для собирания единого файла прошивки, передаваемого для обновления через ОТА. Я использую простой скрипт на питоне, который работает для обычной загрузки прошивки через сом-порт. Скрипт заполняет ‘FF’все место от конца файла, который будет шиться по адресу 0х00000 до 0х40000, после таких манипуляций размер файла прошивки заметно возрастает, с 180-200kbв среднем, до ~400, что критично. Можно ли изменить ограничение на загрузку только 256kb, если да, то где? Или всё-таки существует другой способ создания единого файла прошивки?

Также обнаружилась интересная особенность: адреса, куда шьются user1 и user2, это 0х01000 и 0х81000 соответственно- если со вторым проблем нет (пока что), то при записи user1 затирается часть ОТА, которая установлена в эту же область памяти. После чего происходит сброс по wdt. Можно ли исправить это и как, или это стандарт SDK?

P.S.

Извините за стену текста! Если эти вопросы уже поднимались на форуме и на них были даны ответы, то прошу ткнуть меня носом, ибо сам я их не нашел. Если также существует рабочий пример ОТА, то буду благодарен за ссылочку.