[Ruslan1 16]

Есть устройство, в которое приходит полудуплекс RS-485 (два провода). Ну и питание (еще два провода) 

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

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

 

1. Общение

Команды загрузчика:

- Очистка FLASH памяти

- чтение из FLASH памяти последовательности адресов

- запись в  FLASH память последовательности адресов

 

2. Вход в режим загрузчика

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

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

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

 

3. Софт на компьютере:

- инициирует соединение (посылает команду чтения флеша в цикле до получения ответа)

- читает подготовленный hex-файл, разбивает на части и подсовывает его в RS-485 интерфейс в виде команд записи.

- может проверить соответствие файла и содержимого FLASH программируемого контроллера.

 

Вроде все достаточно плоско и понятно, или я слона не заметил?

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

[aaarrr 64]

3 hours ago, Ruslan1 said:

если не обнаружено команд, обращенных к  загрузчику, то идет переход на основную программу

Сначала следует её целостность проверить.

 

3 hours ago, Ruslan1 said:

Кроме как делать паузу до перехода на основную программу, не вижу надежных вариантов, но может они есть.

По команде из основной программы.

 

ИМХО, лучше по возможности загрузку данных осуществить в основной программе. А загрузчик пусть только поместит проверенные данные в нужное место.

[HardEgor 66]

31 минуту назад, Ruslan1 сказал:

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

Послать "магическое число" или команду.

[x893 35]

1 hour ago, aaarrr said:

ИМХО, лучше по возможности загрузку данных осуществить в основной программе. А загрузчик пусть только поместит проверенные данные в нужное место.

Это если места хватит. Не хватит - п.1

Работы на пару часов, поэтому всегда можно переделать.

[Ruslan1 16]

14 hours ago, aaarrr said:

Сначала следует её целостность проверить.

По команде из основной программы.

ИМХО, лучше по возможности загрузку данных осуществить в основной программе. А загрузчик пусть только поместит проверенные данные в нужное место.

Проверка на целостность: Согласен. Бутлоадер при программировании записывает переданную из компа контрольку в свою область флеш, ну и считает при каждом старте контрольку уже имеющейся во флеше программы.

Про  задействовать основную программу: можно, как дополнительная опция. Но должно также работать и если основная программа разрушена (не полностью записана, а устройство пересбросилось). А если "дополнительная"- то можно и без нее обойтись, чтоб не множить сущности. Ну разве что, ввести  команду для удаленного пересброса устройства, помогает не трогать питание, и позволяет  программить в сети с несколькими устройствами (только нужное  устройство пересбросится и будет в режиме бутлоадера следующие, скажем, 5  секунд).

12 hours ago, x893 said:

Это если места хватит. Не хватит - п.1

Работы на пару часов, поэтому всегда можно переделать.

Угу. думал про "переместить" и вообще без специального бутлоадера.  Делается и правда легко и без напряга, как несколько команд в основной  программе. Но есть  противопоказания:

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

2. Главная проблема: если  что-то пошло не так (пусть контролька  нормальная, но в прошивке  глюк), то будет кирпич. Так как нет никакого "защищенного бутлоадера", обеспечивающего прием другой  программы, если программа уже не работает.

[Сергей Борщ 119]

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

[jcxz 184]

12 минут назад, Сергей Борщ сказал:

Я делаю так. Устройство готово к работе сразу после включения,

Ну вообще-то это не совсем так. Устройство в вашем алгоритме готово не после включения, а в худшем случае - после загрузки и обновления новой прошивки.

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

[Ruslan1 16]

1 hour ago, Сергей Борщ said:

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

Спасибо за ссылку, почитаю обсуждение.

 

Предварительно: что-то много у Вас завязано на основную программу. И на случай окирпичивания есть пин,  которого у меня нет. Собственно,  устройство- это залитый в компаунд кирпич. Себестоимость невелика, да и (пока) из-за ошибок в программе ничего  не выкинули, но все-таки хочется однажды взять себы в руки и таки написать к нему удаленный загрузчик. 

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

[jcxz 184]

44 минуты назад, Ruslan1 сказал:

Предварительно: что-то много у Вас завязано на основную программу. И на случай окирпичивания есть пин,  которого у меня нет. Собственно,  устройство- это залитый в компаунд кирпич. Себестоимость невелика, да и (пока) из-за ошибок в программе ничего  не выкинули, но все-таки хочется однажды взять себы в руки и таки написать к нему удаленный загрузчик. 

Предполагаете, что рабочая программа может окирпичиться, а bootloader - нет? Почему? Найдёте отдельного идеального программиста для него?  

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

[Ruslan1 16]

21 minutes ago, jcxz said:

Предполагаете, что рабочая программа может окирпичиться, а bootloader - нет? Почему? Найдёте отдельного идеального программиста для него?  

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

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

 

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

[Harbinger 10]

1 час назад, Ruslan1 сказал:

И на случай окирпичивания есть пин,  которого у меня нет.

Как-то пришлось с RXD извратиться. Тоже для "кирпича", залитого эпоксидкой. На RS-485 устраивается break и передёргивается питание. При старте бутлоадер до инициализации UART проверяет RXD, если там 1 - стартует основная программа, если в течение определённого времени 0 - обновление.

[jcxz 184]

30 минут назад, Ruslan1 сказал:

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

Надёжнее хранить бэкап предыдущей прошивки. И откатить на неё при выполнении какого-то условия.

[Сергей Борщ 119]

2 часа назад, Ruslan1 сказал:

Предварительно: что-то много у Вас завязано на основную программу.

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

    // reset to start bootloader
    SCB->AIRCR = 0
        | (0x5FA << SCB_AIRCR_VECTKEYSTAT_Pos)
        | 1 * SCB_AIRCR_SYSRESETREQ_Msk
        ;
    __builtin_unreachable();    // inform gcc that we never reach here, to optimize code better

Все остальное реализовано в загрузчике.

2 часа назад, Ruslan1 сказал:

И на случай окирпичивания есть пин,  которого у меня нет.

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

 

2 часа назад, Ruslan1 сказал:

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

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

 

3 часа назад, jcxz сказал:

Ну вообще-то это не совсем так. Устройство в вашем алгоритме готово не после включения, а в худшем случае - после загрузки и обновления новой прошивки.

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

3 часа назад, jcxz сказал:

Для многих применений это неприемлемо. Например - если устройство не должно прерывать выполнение своей функции более чем на N секунд.

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

[Arlleex 131]

Чисто технически можно сделать такой бинарь, который лишь прикрывается прошивкой.
Ну, то есть, подготовить файл прошивки так, чтобы загрузчик принял его за рабочую. И это вполне имеет место быть.
Например, если софт загрузчика на ПК читает файл прошивки и рассчитывает по нему CRC, подсовывая его в рабочий канал связи.
В результате, скормив МК что угодно с подтверждающей контрольной суммой, МК тупо перейдет на исполнение этого мусора. Кирпич.
Я так не делаю теперь, так как однажды принял битый файл бинарника на флешке. Записал - извлек флешку, а потом удивился, почему кирпич.
Тупо сравнил файлы оригинала и того, что записался на флешку - отличаются с N-го байта. Не стал разбираться, в чем проблема, было некогда.
В итоге у меня есть утилита, которая читает выхлоп IDE (.hex), рассчитывает и подсовывает в нужные места размер и CRC этого файла прошивки.
Который я, естественно, вначале проверю на отладочном варианте изделия, прежде чем отправлю прошивать устройства заказчиков.

P.S. У меня, кроме команд работы с загрузчиком, в загрузчике поддержан некий поднабор команд основного приложения. Их немного.
Это, например, запрос имени устройства (у меня CAN и в общем случае, я не знаю, сколько и каких девайсов сейчас висит на шине), серийника и т.д.
 

53 минуты назад, jcxz сказал:

И откатить на неё при выполнении какого-то условия.

Проблема как раз в том, как определить эти условия. То есть, найти и обобщить критерий, по которому блокировать новую прошивку и откатываться.

[haker_fox 60]

Ребят, я искренне удивлён) На дворе 21 век, уже 20 лет от начала прошло, а тема бутлоадера до сих пор актуальна! Я недавно писал пару своих загрузчиков, прошёлся поиском по форуму. Так там целые баталии на эту тему: как шить, где хранить, чем шифровать...