[Dobermann 1]

Всем привет. Необходимо реализовать функционал удаленной перепрошивки контроллера, в данном случае по GPRS каналу. Кто может поделиться или продать исходники bootloadera, который реализует подобную функцию?

[kovigor 6]

Всем привет. Необходимо реализовать функционал удаленной перепрошивки контроллера, в данном случае по GPRS каналу. Кто может поделиться или продать исходники bootloadera, который реализует подобную функцию?

 

У Атмела есть несколько Application Notes по реализации BootLoader'ов с исходными текстами. Там ничего сложного нет. Разберитесь и приспособьте под свою задачу:

http://www.atmel.com/dyn/products/app_note...p?family_id=607

[Dobermann 1]

У Атмела есть несколько Application Notes по реализации BootLoader'ов с исходными текстами. Там ничего сложного нет. Разберитесь и приспособьте под свою задачу:

http://www.atmel.com/dyn/products/app_note...p?family_id=607

Большое спасибо, но нет особо времени с разборами, хотя после сдачи проекта непременно этим займемся

[kovigor 6]

Большое спасибо, но нет особо времени с разборами

 

Я почти уверен, что вы быстрее напишете свое, чем найдете готовое. А как МК с GPRS-модулем связан (по какому интерфейсу) ?

[Dobermann 1]

uart

[kovigor 6]

uart

 

Тогда задача совершенно тривиальная.

[Dobermann 1]

Тогда задача совершенно тривиальная.

не спорю, но времени то особо и нет

[mrKirill 1]

Всем привет...

не спорю, но времени то особо и нет

Вот уже, как минимум, 2,5 часа в пустую проведено...

[sensor_ua 0]

Удаленное обновление чревато обрывом связи. Всвязи с чем стОит принять решение о степени критичности такой ситуации по отношению к дальнейшему функционированию контроллера. Т.е. решить, должен ли продолжать работать (по основной программе) контроллер в случае неудачи при обновлении (необходима ли резервная копия). Если не хочется иметь мертвый девайс, нужно уметь идентифицировать целостность прошивки самим бутлоадером или через него и без такой сверки не отдавать управление основной программе. Но даже это не спасает от записи прошивки с логической ошибкой, которая может больше не позволить перейти в бутлоадер. Я бы предложил посмотреть в сторону бутлоадеров, совместимых с STK500 (например где-то там был http://www.miklobit.com) или загружающих extended-hex, которые можно дополнить нужными фичами. Но без проработки модели работы при отказе по связи это может быть пустой или даже вредной работой.

[subver 0]

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

[Sergey_Aleksandrovi4 2]

В том то как раз и проблема, что используя "голую" AVR (без внешних ОЗУ, ПЗУ) засунуть прошивку целиком во внутренний SRAM навряд ли получится. Объём Flash раз в 10 превосходит SRAM. Поэтому принимать прошивку только поблочно. Действовать именно как сказал sensor_ua: разрешать выполнение кода после перепрошивки только удостоверившись в её достоверности средствами загрузчика.

[Fry__ 0]

Вот уже, как минимум, 2,5 часа в пустую проведено...

За 2,5 часа bootloader не напишешь.

 

Удаленное обновление чревато обрывом связи.

Нормальному bootloader'у такое не страшно.

 

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

В качестве хеш-функции подойдет и проверка CRC32(16) для залитой прошивки.

 

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

Бутлоадер должен получать управление при старте в любом случае. После чего должен подсчитать CRC для прошитой области ROM и сравнить с сохранненой CRC, которая подсчитывалась при получении прошивки. Если обнаружится несоответствие - должен перейти в режим ожидания комманд от канала загрузки. Иначе - отдать управление...

 

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

Это как? Т.е. если RAM меньше прошивки то ставить внешюю? Зачем.

 

PS: Вообще создание подобного освещено в Application Notes (как уже писал kovigor ), ничего сложного в этом нет - нужно только канал данных поменять. И лучше конечно написать свой код.

 

 

 

[BALDA 0]

Скажите, а цена железа какая? (GPRS)

[mempfis_ 0]

В том то как раз и проблема, что используя "голую" AVR (без внешних ОЗУ, ПЗУ) засунуть прошивку целиком во внутренний SRAM навряд ли получится. Объём Flash раз в 10 превосходит SRAM. Поэтому принимать прошивку только поблочно. Действовать именно как сказал sensor_ua: разрешать выполнение кода после перепрошивки только удостоверившись в её достоверности средствами загрузчика.

 

Ну тогда Вам один путь - менять железо (ставить внешнюю flash объёмом >= flash AVR).

Или если позволяет flash контроллера в загрузчике (тут надо уточнить что за AVR стоит, какой объём flash и размер памяти загрузчика) скачивать прошивку записывая её в свободное место flash, там проверять целостность и только потом перешивать ту часть flash где лежит приложение. ИМХО реализуемо но с трудом на старших мегах (128/256) и только если размер рабочей программы будет меньше чем (flash_size-boot_size)/2.

При наличии внешней памяти дистанционная перепрошивка не вызывает особых сложностей.

 

[kovigor 6]

Бутлоадер должен получать управление при старте в любом случае. После чего должен подсчитать CRC для прошитой области ROM и сравнить с сохранненой CRC, которая подсчитывалась при получении прошивки. Если обнаружится несоответствие - должен перейти в режим ожидания комманд от канала загрузки. Иначе - отдать управление...

 

Именно так и делал. Решение непотопляемое. Бутлоадер никогда не модифицируется и при любом включении или сбросе устройства получает управление. Дальше все, как вы описали. Для защиты от заливки программы с логическими ошибками и заведомо правильной CRC32 можно ввести в бутлоадер небольшой временной интервал (к примеру, 5 секунд), в течение которого он будет ожидать команду обновления прошивки ...