Всем привет.

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

Во-первых, для себя я вижу 2 концепции бутлоадера, каждый со своими плюсами и минусами.

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

Преимущества(+)/недостатки(-):
+простота бутлоадера, в том числе не нужно инициализировать юарт и модуль из бутлоадера.
+не нужно долго висеть в буте
+перезагружаться в бут можно только после того, как прошивка успешно закачана
-если не верно закачалась прошивка либо же не рабочая прошивка - только вручную перепрошивать
-нужен МК с бОльшим обьемом Flash

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

Преимущества(+)/недостатки(-):
+бут может сам скачать новую прошивку
+контроллер с меньшим обьемом флеша
-сложность бута - нужно будет иниициализировать юарт, включать и инициализировать gsm модуль.
-долго находиться в бутлоадере

Какой вариант лучше? И, может, есть более совершенные решения?

Теперь вопросы по реализации:
1. Какие подводные камни могут быть в написании бута?
2. Читал на форуме про то, что нужно перезаписывать таблицу векторов(или вектора прерываний?)? Можно об этом подробнее? Как это делается? Где об этом можно подробнее почитать, а то никакой вразумительной инфы не нашел.
3. Бут и основная программа пишуться ведь как 2 разных проекта?


Отадельным вопросом - как заставить программу перейти на выполнение с определенного адреса? Где найти об этом информацию?
Пробывал как в примере от ST:


Не получилось. На ф-ции Jump_To_Application(); уходит в hardfault
Особенно не понятно, где тело этой функции, нигде в присоединенных файлах эта функция не описана. (файлы примера прикрепил к сообщению)

Был бы очень благодарен, если бы кто-то подсказал, где об этом можно прочитать и где можно найти рабочие и понятные примеры.


И чтобы не плодить сообщения, напишу про еще одну проблему с отладочной платой: на STM32VLDiscovery целевой контроллер работает, прошивается, но невероятно греется. Даже на 2 секунды нельзя на нем задержать палец. Очень горячий. Закороток визуально нет, да и паяльником я не притрагивался к плате , не знаю, с чего все и началось. Тестера под рукой тоже нет. Не работает светодиод LD4. Правда я не знаю, это следствие или причина нагрева, сейчас далеко от цивилизации, протестить и перепаять ничего не могу. (схема : http://www.st.com/internet/com/TECHNICAL_R...CD00267113.pdf)

Кайл умеет ходить шагами по дизассемблеру. Рекомендую, сразу будет видно, ОТКУДА улетает.

Да вот оттуда и улетает, как JumpAppl() жму. Больше же нет ничего для дизассемблера, проект кончается.

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

Вот прямо в дизассемблере так и написано JumpAppl()? У меня там обычно что-то вроде BL R0 и чуть выше можно увидеть, откуда в R0 вдруг оказался неправильный адрес перехода.

Я ее (их обеих) вижу в окнах Memory в отладчике. Все, как надо: адрес стека, адрес по сбросу...


У меня тоже, естественно. BL R1. И адрес в нем правильный, из таблицы, что находится по адресу 0x08004004.
А дальше - то, что описал.

Здесь вот какая штука - в основной программе использую Keil RTX RTOS. Может, она и меняет что-то, например, VTOR. Надо посмотреть в несдвинутом проекте.

Из программы-загрузчика по стартовому адресу основной программы 0x08004000 переходит. Начинает обнулять переменные и когда обращается к внешнему ОЗУ, впадает в HardFault. Устанавливается бит Imprecise data access violation, и всё.
Если же основную программу скомпилировать с адреса 0x08000000, то работает.

Складывается впечатление, что нужно сконфигурировать ExtMem. Что делается в кейловской SystemInit, вместе с установкой рабочей частоты, еще до обнуления переменных в __main.
Я SystemInit использую свою, контроллер внешней памяти программирую потом. Почему же программа не висла до этого?

Еще вижу в отладчике для сдвинутой программы в панели NVIC VTO=0x08004000 (как и должно быть), и TBLOFF=0x100080 (а это что за хрень?). В несдвинутой программе последнее - по нулям.

Перенес инициализацию FSMC (заодно и всего остального) в SystemInit. Как и предполагал, переход из загрузчика заработал. И как только до этого инициализировались переменные (массивы-буферы), ума не приложу.
Вот только просто ждать таймаута для перехода - не по человечески. Можно по кнопке оставаться в загрузчике. Так ее еще передать и принять нужно...

Должен выполнять, но возможно нужно настроить MPU предварительно.
По-крайней мере для LPC1788 в UM указано:
Default memory space permissions for the Cortex-M3 do not allow program
execution from the address range that includes the dynamic memory chip selects.
These permissions can be changed by programming the MPU
В реальности если запустить код в SDRAM, то при шагании JTAG видно, что несколько команд (с десяток) код выполняется нормально, но на некоторой команде вдруг улетает в
Memory Management Fault (MMFSR.IACCVIOL = 1).
Я только что прописал конфигурирование MPU и после этого всё заработало - теперь программа нормально выполняется из SDRAM (LPC1788).

Хочу спросить... Что-то не могу после прошивки новой программы перескочить в основную. Если после сброса, и таймер отсчитал 2 с - переходит нормально. За эти 2 с я должен нажать кнопку на панели, тогда дается таймер в 16 с для приема кода прошивки. Так вот, если кода не пришло, тоже не могу перейти в основную программу. Как будто, что-то переинициализировать нужно.

Добавлю информации. После записи во флэш проверяю, что есть новый адрес для стека (т.е., что прошивка записана, и есть куда идти). Этот момент сигнализирую вспышкой светодиода. Дальше перехожу в основную программу.
Сразу после программирования диод не пыхает, т.е., не обнаруживается зашитая прошивка. После сброса - нормально проходит, после 2 с ожидания в загрузчике. Если нажму кнопку в это время, после 16 с светодиод тоже пыхает, но перехода нет. Чудо.
Запросы от USART стираю. Больше никакими прерываниями не пользуюсь.
P.S. Я, собственно, прерываниями от USART не пользуюсь. Проверяю состояние. Постирал pending биты запросов. Еще забыл про таймер. От него тоже стер. Всё то же.

А в отладчике после 16 с перескакивает в основную программу и работает. И после обновления прошивки тоже перескакивает. Что-то я пасую.
Похоже, перескакивает он всегда, только работать, как надо, не хочет.

А еще у меня Keil пишет "*** error 34, line 32: undefined identifier" на строку G, main в файле инициализации отладчика. Конкретно, на main. ?

Так и не могу разобраться, что же не дает загрузчику перейти в основную программу сразу после ее прошивки. Ну, попринимал я что-то USART-ом, посчитал время таймером, пописал во флэш... и хочу выйти. Чего не хватает? После сброса (тот же загрузчик, но без приема нового кода) - все нормально запускается. Может, барьеры нужны?

Про кэши ART почитал.

Неслабые такие кэши? Но в загрузчике я их не включаю. И prefetch тоже.

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

Все, исправил. Кнопка от панели передается двумя байтами, да еще и нажатое и отпущенное состояния. Лезло ненужное в основную программу.
Сбрасываю флаг USART_SR_RXNE, основная программа перестала улетать в прерывание.

Теперь задача - зашифровать-расшифровать прошивку. Думаю, не задействовать ли вычислитель CRC в мк.

Есть проблема со входом в бутлоадер STM32L051 (cortex m0+) из тела программы, микроконтроллер сбрасывается. Тот же код только с другими адресами прекрасно работает на STM32L151 и STM32L401 (cortex m3/m4). Подскажите в чем может быть проблема?



Сообщение отредактировал veteq - Mar 19 2015, 13:25

Попробовал XTEA. Пока только закодировал. Не знаю, сколько времени будет декодироваться в микроконтроллере.
Есть одно замечание. Поскольку кодируются блоки из двух слов, то и перемешивание битов идет в пределах этих двух слов. Дальше все начинается сначала. То есть, одинаковые последовательности слов в начале двоичного файла прошивки (пустые обработчики прерываний) после кодирования тоже будут выглядеть одинаково. Что наталкивает взломщика на принцип кодирования.

Сделал и декодирование, все по https://ru.wikipedia.org/wiki/XTEA#cite_note-report-1
Декодируется быстро, практически, мгновенно.
Фактически, имеется 4 32-битовых ключа, и количество итераций тоже можно выбрать на свой вкус.