STM32: загрузка загрузчика, как обновить сам бутлоадер без программатора Опции

[Ruslan1]

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

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

Спасибо.

[menzoda]

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

[Ruslan1]

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

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

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

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

[jcxz]

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

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

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

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

[Kabdim]

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

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