Стратегия загрузчика для поврежденных приложений - PullRequest
Новая
       118

Стратегия загрузчика для поврежденных приложений

2 голосов
/ 16 марта 2020

Я реализовал загрузчик для микроконтроллера Kinetis ARM Cortex-M4.

Основное приложение (начиная с 0x10000) перепрограммируется через загрузчик через пользовательский интерфейс RS232. Я реализовал функции jumpToApplication и jumpToBootloader с точки зрения загрузчика и приложений, и до сих пор все работает нормально.

Одна стратегия, которую я очень хочу понять, - это что делать в случае повреждения поврежденного главного применение?

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

  1. Основное приложение зависнет и затруднит перепрограммирование
  2. Микроконтроллер перезагрузится и будет застрял в bootloader> application> bootloader (et c) l oop

У меня есть структура SharedData, которая позволяет мне обмениваться данными (через фиксированный Расположение ОЗУ) между загрузчиком и приложением. Я рассмотрел добавление rebootCounter к этой структуре, которая будет увеличиваться при срабатывании HardFaultInterrupt в основном приложении.

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

Есть ли больше "отраслевых" стандартных способов решения этой проблемы?

ОБНОВЛЕНИЕ

Чтобы уточнить, конечная причина для того, чтобы задать этот вопрос, состоит в том, чтобы охватить следующий сценарий:

  1. Загрузчик запрограммирован в устройство на этапе производства с помощью JTAG
  2. Основное приложение (последняя сборка) загружается на этапе тестирования
  3. На этапе тестирования происходит отключение питания. обрыв или проблема с подключением, и устройство запрограммировано только частично
  4. При повторном включении питания загрузчик «предположит», что в основной части fla sh есть действующая программа, и «перейдет» к это приложение
  5. Микроконтроллер теперь застрял в безлюдной земле, не имея возможности повторно загрузить fla sh через загрузчик снова, не открывая p Вложение продукта и перепрошивка чипа через JTAG - это не то, что мы можем сделать, когда продукт находится в поле.

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

UPDATE # 2

Следующий пост, кажется, думает в том же духе:

https://interrupt.memfault.com/blog/how-to-write-a-bootloader-from-scratch

Ответы [ 2 ]

0 голосов
/ 04 апреля 2020

Я бы добавил некоторое значение 'magi c' (скажем, 0xDEAD00D) в конце приложения, и там только переход к применению значения magi c. Вы можете иметь указатель на это место на 0x10000.

Чтобы сделать вещи более надежными, запрограммируйте значение magi c после завершения проверки.

0 голосов
/ 16 марта 2020

Сначала я рекомендую добавить некоторую задержку в ваш загрузчик, который ожидает индикатор запуска процесса обновления прошивки. Я разработал нечто подобное; настольное приложение периодически отправляет стартовый байт и при подключении устройства переходит в режим загрузчика и ждет еще пять секунд, чтобы получить новую информацию о прошивке; так что не важно, есть ли действительное основное приложение на fla sh или нет. Другое решение для проверки существующего основного приложения использует специфицированный c сектор fla sh для информации о встроенном программном обеспечении, прежде чем процесс обновления встроенного программного обеспечения удалит этот сектор. После успешного обновления прошивки запишите указанные c данные в этот сектор. В загрузчике прочитайте этот сектор и убедитесь, что на fla sh есть действительное приложение.

...