Суть вопроса такова. Понадобился бутлоадер. Ранее таким не занимался. Начитался форума и интернета по самое нехочу. Теперь в голове просто каша. Хочу все поставить на места и упорядочить. Изначально давайте сразу ориентироваться на STM32 чтоб уже применительно к ним. Задача следующая: устройство подключено по ethernet и другие интерфейсы недоступны. Нужно перепрошивать по имеющемуся. Размер кода программы примерно 30% от имеющейся флеши на борту. Представляет интерес получать файл прошивки, записывать его в свободную часть флеши, проверять и если все ОК то переписывать на место для собственно программы. Бутлоадер думал располагать в самом конце. Собственно вопрос как бы это все устроить? Наверно было бы удобно сделать бутлоадер отдельным проектом и при изменении размера флеши контроллера следить за его расположением. Можно ли сделать так чтоб потом шить программу (как новый проект) не стирая бутлоадер и чтоб он всеравно продолжал оставаться работоспособным?

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

при старте он проверяет
1. не нажата ли кнопка остаться в бутлоадере
2. нет ли специального флага остаться в бутлоадере (у нас через флешь, видел варианты в РАМ пихают флаг и делают софт ресет, то есть при старте с подачи питания флага нет, а так есть). Это для входа в режим бутлодера по команде езернет из боевой прошивки.
3.1 не пуст ли регион с прошивкой
3.2 сходиться ли контрольная сумма прошивки.

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

схема предложена коллегой и нахожу ее весьма разумной, многие на форуме по обсуждению в соседних темах делают так же

Можно и так, но не понятны два вопроса. 1) как программа будет бегать по кругу? 2) как будет обстоять с отладкой?

Я предполагал, что основная программа получив команду на обновление передаст управление бутлоадеру или пропишет новую прошивку на свободное место а затем передаст управление бутлоадеру. Хочется как-то чтоб попробовать обновлять с веб-странички без специальных средств. Тут еще и настройки некоторые замешаны. Думал просто в новый файл прошивки, когда он уже во флеши, дописывать в нужные места настройки. А бутлоадер чтоб уже копировал... ну или как-то так.

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

Это так. Смотрел. Но чтобы дальше разбираться надо понять хотя бы минимум. Как передать управление от бутлоадера программе и наоборот, как разместить в нужном месте... Как это в кейле делается? Про таблицы векторов тоже не все ясно. Как реализовать чтоб макисмально удобно в эксплуатации было ну и т.п. Вот и пытаюсь в голове все упорядочить.

Читайте руководство на процессор - там это есть.


Читайте руководство на кейл - там это есть.


Читайте этот форум - там это есть.

у вас должно быть 2 пути

сброс -> загрузчик -> основная программа - это путь для основной работы
и
сброс -> загрузчик - это путь для обновления прошивки

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

основной режим работы -> сброс -> загрузчик

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


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


отладка собственно отдельная тема, зачем отлаживать программу через загрузчик? МЫ отлаживаем программу, потом собираем ее для версии загрузчика и все. Не надо усложнять и делать отладку программы вместе с загрузчиком. Потому что по сути прошивку обновляют клиенты, зачем им отладка? А вы у себя можете программу и без загрузчика погонять, и если удачная копия залить.
Это если отладка с жетагом, а если отладка через порт, то разницы нет с загрузчиком или без, а если все же с жетагом, то нафига загрузчик%?

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

минусы такого подхода два.
1) адресация внутри модулей должна быть с учётом любого адреса загрузки.
2) отлаживать модули из среды - только азм.

Сложновато выходит. Да и нужды нет разбивать на модули.

В отношении сборки с загрузчиком не совсем понял. Загрузчик получается по сути добавляется в программу?

мы сделали такой прошиватель (на блекфине, но в принципе это не важно)
у нас большое количество приборов (~1000) и при изменении программы,
поиска и исправления багов подключать JTAG (в нашем случае ICE-100B)
это было бы критично.
При производстве плтаты с помошью JTAG мы прошиваем во flash
саму программу прошивальщика,
сама основная программа прошивается так:
на SD карте должно быть 2 файла, при
1) вклчении питания прошивальщик смотрит их наличие - если их нет
он передает управление
основной программе, если эти 2 файла там есть - он прошивает их на flash?
стирает эти 2 файла с SD и делает перезагрузку (1)
Вобщем все идеально работает около 2-х лет.
приборы у нас могут находиться за 1000 км от нас
мы просто меняем прошивку и те, кто с нашыми приборами
работает сами могут их перешить.
да. если прошика сбойная, битая или ошибочная
всегда можно заново перешить без всяких JTAG

подсказали нам сдесь: https://ez.analog.com/thread/35318

Он с толку сбивает. Загрузчик и основная программа собираются как раздельные проекты. Отлаживать можно и тот, и другой в "боевой" конфигурации: всё зависит от того, чья отладочная информация загружена в отладчик. Кейловский отладчик умеет загружать отладочную информацию одновременно двух и более программ, так что можно отлаживать всё вместе (то есть проследить переход из загрузчика в основную программу, к примеру).

А почему именно два?

это в принципе тока к блекфину относится -
там одни функции во flash лежат другие в RAM
только из за этого.
для ARM будет 1.

при отладке программа запускается со стандартного адреса как обычно, прошивается жетагом. После того как все отладили, перекомпиливаем для старта и работы с адреса 10000 (условно). Загрузчик в схемах заказчика есть всегда, он всегда ждет программу с адреса 10000 и туда передает управление, на отладочной плате загрузчика нет (если отладка жетагом), или если отладка в порт, то все равно можно и с загрузчиком, тогда программу сразу делаем для работы с адреса 10000

У меня на отладочной плате загрузчик всегда был. Кстати, часто бывает так, что загрузчик позволяет заливать новую отлаживаемую прошивку быстрее, чем жытаг.