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

как это делается красиво? Есть бутлоадер и основная программа. Обновляем основную программу через файл- если бутлоадер видит файл на диске, то программирует камень согласно содержимомму данного файла (кроме области бутлоадера).
Хочется точно так же обновлять сам загрузчик, из файла.
Конкретно нужно для STM32F4, но тут вряд ли что-то особенное, отличное от других.

Спасибо.

Добавьте еще один "нижний" загрузчик. Работать будет так:
1. "Верхний" загрузчик записывает свое обновление в отдельную страницу памяти и вызывает сброс
2. "Нижний" проверяет CRC и версии образов "верхнего", затем копирует новый образ в рабочую область и передает ему управление
"Нижний" загрузчик пишется один раз и никогда не обновляется.

Можно и без этого ограничения обойтись.
Очевидно имеется в виду, что в составе устройства имеется некое устройство хранения (УХ) (файловая система или просто например SPI-флешка).
Основной бутлоадер (ОБ) сканирует УХ:
1. Если обнаруживает новое рабочее ПО, записывает его в область рабочего ПО флешь программ.
2. Если обнаруживает новый ОБ, то ищет на этом же УХ вспомогательный бутлоадер (ВБ) (скомпилённый для выполнения в области рабочего ПО флешь программ). Записывает ВБ в область рабочего ПО флешь программ. Передаёт ему управление. ВБ сканирует УХ, обнаружив новый ОБ, записывает его в область ОБ флешь программ и передаёт ему управление.
Единственный минус здесь - такое обновление ОБ небезопасно.

Если не включать защиту от чтения. Потому что включение защиты от чтения включает и защиту от записи нескольких первых страниц, и снять ее можно только вместе с защитой от чтения, т.е. стерев весь кристалл напрочь.

Спасибо, буду думать. несрочно, так что еще и потестирую.

Да, в системе есть SD-карточка, на которую файл прошивки попадает разными путями. Файл уже содержит необходимые чексуммы, то есть его валидность проверяется.
И в системе есть резервное питание, то есть вероятность выключения питания во время такого обновления минимальна.

Но таки да, процесс небезопасный, и хочется уменьшить вероятность сбоя.

Я еще думал про второй (вспомогательный) бутлоадер, который просто является частью основной программы и используется только для обновления основного бутлоадера.

Задача защиты от чтения не стоит, это не ширпотреб (пока что

Загрузчик может и сам себя обновить. Правда, возрастает риск, ведь при неудачном обновлении загрузчик сам себя и поломает же. Однако, у нас обновление загрузчика это чисто технологическая задача, не для конечных пользователей, поэтому мы спокойно используем именно этот вариант. Если даже что-то пойдет не так - то рядом будут специалисты, которые все восстановят. Пока сбоев не было.

Сам себя - это как? перемещается, например, в RAM (или, как писали выше, в зарезервированную область флэш), и исполняется отсюда, ну и пишет все что хочет в област загрузчика ?

Сам себя обновить- несколько стремно, именно для удаленного обновления задумывается. Локально можно и программатор подключить (хотя и не так удабно).
И нужно еще посмотреть почему такое "самопереписывание" считается менее надежным- не совсем понятно, какие дополнительно факторы действуют, по сравнению с вариантом "два загрузчика".

Ну и, по-моему, абсолютно безопасного варианта не бывает, я за него и не борюсь.

Безопасный вариант уже был предложен - трёхуровневый(минимальный бутлоадер, полноценный, основная прошивка), но видимо всем лениво его делать ради фикса редкого шанса испортить загрузчиком сам загрузчик. Для себя я бы сделал, но вот лишней страницы во флеше уже нет.

"самопереписывание" ненадёжно, потому что при этом по любому есть момент времени когда во флеш нет исправного загрузчика. А МК всегда стартует с одного и того же адреса.
Абсолютно безопасный вариант - необновляемый загрузчик. При этом основное ПО будет обновляться абсолютно безопасно. Мы у себя в изделиях именно такой вариант и применяем, так как нам необходимо обновление ПО на объектах заказчика, без возможности демонтажа или подключения отладчика "на горячую".


Какой смысл в этой 3х-уровневости? Всё равно остаётся необновляемый загрузчик. Зачем нужна ещё одна прослойка между первоначальным загрузчиком и основным ПО? Чтобы создать себе дополнительную работу?
Достаточно одного необновляемого загрузчика и основного ПО.

Поскольку функция загрузчика очевидна и однозначна, то дистанционно обновлять его не вижу необходимости. Он уже сделан и работает. Можно сделать новую версию, расширить функционал, например. Значит, покупателям новых приборов повезет чуть больше. Насколько?
Сектор с загрузчиком, вообще, защищен от записи и чтения. Никто не доберется. Только стереть можно.

На самом деле иногда (очень редко) такая необходимость возникает. У меня было дважды - первый раз придумали улучшение и для совместимости уже проданной аппаратуры с новыми прошивками пришлось постепенно отзывать проданное оборудование, второй раз сам был жутко удивлен, когда мой написанный в 2006 году загрузчик вдруг начал падать после смены компилятора (IAR->GCC) приложения. Да, в нем нашлась ошибка (отсутствие заглушки на spurious interrupt в LPC22xx), которая почему-то за 9 лет ни разу не вылезла с приложением, написанным под ИАРом, а его было выпущено более 40 версий. Зато с приложением, написанным под GCC - вылет в 100% случаев.

Имхо довольно очевидный смысл. Копирование из флеша во флеш, проверка crc/sign, установка новых векторов прерываний и переход можно сделать без ошибок раз и навсегда. Обложить тестами с близким к 100% покрытию. И забыть, а части более подверженные ошибкам/обновлениям вынести уже во второй. Вам достаточно одного и вы считаете своё мнение единственно верным - я за вас рад. Для себя правильным считаю другое.

Какие такие части? Бутлоадеру достаточно тех функций, что в первой квоте. Имхо - больше он ничего не должен делать.

Способ загрузить прошивку откуда-то в мк остался и прочие удобства.

Загрузка новой прошивки у нас - это часть основного ПО. Так как прошивка должна выполняться не мешая функционированию основного ПО, по рабочему протоколу.