Можно ли проверить правильность архитектуры в обновлении OTA (ESP32 или ESP8266)?

esp ota

Наличие skech, работающего на ESP8266, а также на ESP32 с возможностью обновления через OTA, загрузка неправильного двоичного файла (загрузка в ESP8266, скомпилированного для ESP32, и наоборот) приводит к сбою MCU и невозможности больше обновлять OTA.

Обновление выполняется обычным простым способом: загрузите двоичный файл и вызовите методы из класса Update (begin(), write () и end ()).

Есть ли какой-либо способ проверить, соответствует ли загруженный файл архитектуре MCU, прежде чем запускать обновление?

Правка:

Как класс ESP8266, так и класс обновления ESP32 проверяют значение "IMAGE_MAGIC" в заголовке загрузки; но это определяется как "ESP_IMAGE_MAGIC = 0xe9" в обоих ядрах. Поэтому никто из них не откажется обновить неправильный.

Правка 2:

Мы нашли простой обходной путь, который удовлетворяет нашим потребностям на данный момент: Поскольку среда IDE arduino сохраняет двоичные файлы с именем, таким как <имя скетча>.<имя скетча><имя платы>.bin, мы просто сравниваем имя платы как часть загруженного имени файла: <имя платы>если (загрузка.имя файла.Индекс(СОВПАДЕНИЕ) > 0) ...>, где СОВПАДЕНИЕ-соответствующее имя платы. Поскольку они совместимы с pin, мы используем "d1_mini.bin" и "d1_mini32.bin".

Правка 3:

Когда веб-сервер пытается прервать загрузку с запретом 403 (из-за неправильного файла), браузер продолжает отправлять данные до тех пор, пока загрузка не будет завершена. После этого на экране отобразится сообщение об ошибке. Таким образом, даже если имя файла не совпадает, это пустая трата времени и пропускной способности. Единственная возможность избежать этого-выполнить server.client().stop(), но тогда браузер не отобразит отправленное сообщение, просто что-то вроде "соединение разорвано". Это не подтверждается соответствующими RFC.

На самом деле это не окончательное решение, так что я был бы признателен за любую лучшую идею.

Ричард

, 👍3

Обсуждение

Вы можете просто попробовать, что произойдет, если вы выполните такое "незаконное" обновление. Я предполагаю, что загрузка образа, предназначенного для другого MCU, завершится неудачно и будет помечена как поврежденный образ прошивки. Если esp8266 и esp32 имеют разные размеры флэш-памяти, я бы ожидал, что загрузчик распознает неисправные образы прошивки, @Sim Son

По крайней мере, я один раз отаэтировал 4 МБ-ESP32 с образом, предназначенным для 8 МБ-ESP32, который вышел из строя (esp отказался от загрузки этого образа и остался на fw-версии, которая была установлена ранее), @Sim Son

Используемые нами борды имеют одинаковый размер прошивки (4 МБ), и класс обновления ESPS, похоже, принимает любой файл, если "волшебный байт" равен 0xE9, но это то же самое для ESP32 и ESP8266. Протестировал это с помощью небольшого текстового файла с именем "fake.d1_mini.bin" с 0xE9 в качестве первого байта - не сообщил об ошибке при обновлении, но разбился при перезагрузке., @ridgy


1 ответ

1

Я предполагаю, что вы создаете обновление OTA. Если это так, то почему бы вам просто не включить "подпись" в код, который является архитектурой, т. Е. ESP8266 против ESP32, а затем проверить это в своем коде обновления, чтобы он не установил обновление для неправильного процессора.

,

Спасибо вам за ваш ответ. Это также была моя первая идея, но найти подпись где-то в загруженном файле-это большая работа, так как вы не знаете, где компоновщик ставит подпись. Я придумал более простой метод..., @ridgy

Вы можете заставить компоновщика разместить подпись в определенном месте. Или вы можете "злоупотреблять" неиспользуемым вектором прерывания., @the busybee

Смотрите также: