stm32 bootloader, разьясните новичку Опции

[batisto4ka]

Помогите, пожалуйста, поставить точки над i. Насколько мне понятно, в stm32 bootloader может быть использован вместо программатора. Для того, чтоб залить прошивку в контроллер, необходимо подсоединить плату с МК к компу через ком порт( по USART1 МК), подать на вход бут0 1, на бут 1 -0, загрузить бинарник, используя специальную утилиту Flash Loader Demonstrator.Это весь алгоритм?
Второй вопрос. Часто встречается в сети такое выражение, как "написать загрузчик". Что имеется в виду под этим? В каком случае нужно писать свой загрузчик и как это сделать?

Сообщение отредактировал batisto4ka - Apr 18 2012, 11:41

[lead_seller]

Вектора прерываний переносятся потому, что и бутлоадеру и основной прошивке как правило требуется работа с прерываниями, и необходимо выбирать какой код обработчика прерывания мы выполняем - код бутлоадера или код основной прошивки. Для этой цели у STMовского контроллера прерываний есть функция переноса таблицы векторов прерываний. При этом появляется возможность иметь отдельные наборы обработчиков прерываний для бутлоадера и для основной прошивки.
Конечно возможен вариант с одной таблицей векторов, и программным выбором какой обработчик использовать (устанавливаем флаг работает бутлоадер или основная прошивка, и по этому флагу делаем if в ветках которого расположены разные обработчики) - бутлоадера или основной прошивки (в зависимости от того что активно), но такой вариант замедляет реакцию системы на прерывания.
Вариант с переносом таблицы векторов удобней тем, что в памяти программ мы можем хранить несколько разных прошивок (естественно скомпилированных и линкованных для использования разных стартовых адресов), и на старте системы можем выбирать какой из прошивок отдавать управление. Сейчас как раз занимаюсь такой развлекухой)). Требуется шиться по CAN с оооочень низкой скоростью (порядок байтов в секунду), причем с огромной вероятностью разрывов на линии. При этом вероятность того, что устройство продолжит функционировать после неудачной перепрошивки, должна стремится к 100%.

[jcxz]

Вектора прерываний переносятся потому, что и бутлоадеру и основной прошивке как правило требуется работа с прерываниями, и необходимо выбирать какой код обработчика прерывания мы выполняем - код бутлоадера или код основной прошивки. Для этой цели у STMовского контроллера прерываний есть функция переноса таблицы векторов прерываний. При этом появляется возможность иметь отдельные наборы обработчиков прерываний для бутлоадера и для основной прошивки.
Конечно возможен вариант с одной таблицей векторов, и программным выбором какой обработчик использовать (устанавливаем флаг работает бутлоадер или основная прошивка, и по этому флагу делаем if в ветках которого расположены разные обработчики) - бутлоадера или основной прошивки (в зависимости от того что активно), но такой вариант замедляет реакцию системы на прерывания.
Вариант с переносом таблицы векторов удобней тем, что в памяти программ мы можем хранить несколько разных прошивок (естественно скомпилированных и линкованных для использования разных стартовых адресов), и на старте системы можем выбирать какой из прошивок отдавать управление. Сейчас как раз занимаюсь такой развлекухой)). Требуется шиться по CAN с оооочень низкой скоростью (порядок байтов в секунду), причем с огромной вероятностью разрывов на линии. При этом вероятность того, что устройство продолжит функционировать после неудачной перепрошивки, должна стремится к 100%.

У нас работают тысячи устройств имеющих загрузчик (правда на LPC). Обновление прошивки - по любому интерфейсу по рабочему протоколу, при внезапной перезагрузке ничего не слетит 100%, загрузка нового ПО может быть продолжена с точки разрыва. Сбой питания возможен в любой момент хоть при загрузке прошивки хоть при обновлении её во флеш. Никакие таблицы векторов переносить не надо - на время работы загрузчика прерывания запрещены, рабочее ПО при старте само настраивает таблицу прерываний.
ПО состоит из:
1. неизменяемой части (загрузчика) в первом секторе флеш, который прошивается изначально на заводе и при удалённой прошивке не может быть перешит;
2. собственно рабочего ПО (во флеш после загрузчика).
Вся флеш (за исключением первого сектора) делится на две половины: первая - область исполняемого рабочего ПО; вторая - область хранения нового ПО, которое надо прошить.
Рабочее ПО по любому интерфейсу (или по всем включая CAN и беспроводные) принимает прошивку по рабочему протоколу устройства среди прочего обмена данными не мешая основной работе устройства.
Приём идёт в ОЗУ (так как если шить сразу во вторую половину флеши контроллера, то надо запрещать прерывания надолго, а это помешает работе основной программы).
По завершении приёма и проверки валидности прошивки, новая прошивка переписывается во вторую половину флеш контроллера и во флеш выставляется флаг требования обновления прошивки,
после чего делается RESET процу.
Стартует загрузчик, который обнаружив флаг и проверив CRC прошивки во второй половине, перешивает прошивку из второй половины флеш в первую, далее - удаляет флаг и стартует рабочее ПО из первой
половины флеш. Если загрузчик флаг не обнаруживает - значит не надо обновлять прошивку и просто передаёт управление рабочему ПО в первую половину прошивки.

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

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

Расположите с помощью компоновщика команду перехода на _c_int00 (точку входа в С-программу) с самого начала образа прошивки и передавайте управление на первый адрес прошивки.

Обработчики прерываний описываютсся одинаково везде.

Неправда

[batisto4ka]

1. неизменяемой части (загрузчика) в первом секторе флеш, который прошивается изначально на заводе и при удалённой прошивке не может быть перешит;
2. собственно рабочего ПО (во флеш после загрузчика).

Ну где-то так я себе это и предсатвляю. У меня еще вот вопросы:
1. Как можно определить программно размер записанной программы в МК.
2. Как программно перегрузить МК?

[Danis]

Ну где-то так я себе это и предсатвляю. У меня еще вот вопросы:
1. Как можно определить программно размер записанной программы в МК.
2. Как программно перегрузить МК?

Вот для Вас полезная ссылочка будет
тыц