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 (точку входа в С-программу) с самого начала образа прошивки и передавайте управление на первый адрес прошивки.

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

Неправда

[Lotor]

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

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

[jcxz]

Конечно перед заливкой, надо провести полные испытания новой прошивки.
Ваши предложения как обойти этот минус?
Учтите, что рабочий интерфейс в общем случае у нас может быть сложным - сокет TCP/IP поверх Ethernet или GSM или ZigBee и т.п., т.е. - канал, для которого нельзя задать конфигурационные параметры по умолчанию.

[Lotor]

Ваши предложения как обойти этот минус?

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

[jcxz]

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

Каким образом?
Учтите мои требования по интерфейсам, приплюсуйте сюда необходимость реализации некоего рабочего протокола обмена (довольно сложного) в бутлоадере, необходимость определения параметров конфигурации каналов связи (формат этой конфигурации каналов связи может от прошивки к прошивке поменяться и бутлоадер должен заранее знать какой он был в прошлом и будет в будущем
Т.е. - вам придётся еще раз реализовать все те функции, что есть в рабочем ПО + необходимо как-то определить, что основное рабочее ПО функционирует неверно
(а ведь определить это бутлоадеру будет очень сложно, раз на этапе тестирования новой прошивки вы сами не выявили её неработоспособности, значит эту неработоспособность очень сложно даже вам определить не говоря уже о бутлоадере
Таким образом вам придётся написать бутлоадер значительно сложнее самого рабочего ПО! Значит если у нас рабочее ПО перед пуском в серию должно пройти опытную эксплуатацию на объекте как минимум месяц, то и такой бутлоадер тем более надо ставить на опытную эксплуатацию. Только как вы будете его отлаживать, ставить на опытную эксплуатацию на объект и УДАЛЁННО ОБНОВЛЯТЬ???
Таким образом - приходим к абсурдности этой идеи

А если вы о простом интерфейсе для обновления ПО, не подразумевающем использование различных каналов связи с переменной конфигурацией, то по-моему это уже есть в самом проце в ROM изначально - у NXP в её LPC есть ISP через UART.

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

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