Возникла необходимость предвидеть в устройстве возможность дистанционного обновления ПО микроконтроллера, желательно по GPRS-каналу. Ожидаемый объем прошивки 64-128 кб.

Так как напрямую "в лоб" (прямо в память мк) это сделать скорее всего не получится, пришла идея использовать промежуточный буфер памяти в виде флеш памяти AT45 (она все равно находится на борту, 16 Мбит так что выделить 100 кб не проблема вроде). Идея в принципе проста - центральный сервер по команде будет отправлять по частям HEX файл с обновленной прошивкой, части будут проверятся по протоколу и на CRC, после чего будут записываться в буфер AT45, и формировать в ее памяти зеркало прошивки мк. После записи всего массива HEXа, сервер подаст команду на включение бутлоадера - и через минуту вторую устройство с новым ПО.

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

Хотелось бы услышать мнение форумчан по этому вопросу? Кто какой способ изменения ПО устройства использует?

Планирую заняться тем же, поделюсь своими соображениями.

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

Удачи!

Привет Марис!

Именно так я у себя и сделал: внешняя память AT45DB, файлик забирается с сервера записывается туда. По окончании записи проверяется СRC, если она в порядке - управление передаётся на загрузчик. Файлик передаётся и хранится зашифрованным (RC4). Также загрузчик получает управление при включении питания. Он проверяет - "а нет ли в памяти файла прошивки?" Если есть - перепрошивает процессор и стирает файл из памяти. Благодаря этому выключения питания в процессе перепрошивки не страшны. Процессор - MSP430F149, загрузчик меньше 2-х килобайт. Это работает уже на паре тысяч экземпляров, и спасало не раз.
Исходник , если что - мне не жалко

С уважением Ефанов Сергей.

Здравствуйте Сергей! Очень рад Вас "слышать"... Сколько лет, сколько зим...
У меня такая же идейка...
Исходник не помешал бы (особенно кодирование и если есть какое то пробное простое по сервера-обновления)...
Какое в среднем время занимает обновление? А последнюю прошивку на всякий случай в АТ45 сохраняете?



С АТ45 все просто делается, SPI на аппаратном уровне поддерживается...
По буту все ясно - нужно сделать надежным и универсальным - на все случаи жизни...

Вы не могли бы здесь их выложить?

За исходник спасибо...

>Файл забирается по протоколу HTTP через 80 порт с обычного web - сервера

Я просто думал немножко обрабатывать HEX файл на стороне сервера с тем чтобы уменьшить его размер для уменьшения трафика гпрс и объема памяти АТ45, а также для того что бы уменьшить размер и сложность бута?

>Примерно минуту, основное время занимает получение файла. Собственно перепрошивка процессора - секунд 15-20.

Меня именно и интересовало среднее время передачи прошивки по гпрс каналу и какой объем пзу процессора?

>А последнюю прошивку на всякий случай в АТ45 сохраняете?

>Нет, а зачем?

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

>Я просто думал немножко обрабатывать HEX файл на стороне сервера с тем чтобы уменьшить его размер для уменьшения трафика гпрс и объема памяти АТ45, а также для того что бы уменьшить размер и сложность бута?

Я использую бинарный файл (не НЕХ), закодированный в .uue

>Меня именно и интересовало среднее время передачи прошивки по гпрс каналу и какой объем пзу процессора?

GPRS - это канал с малопредсказуемой скоростью. Если всё хорошо - файл закачивается секунд за 30-40. Но частенько он идет небольшими кусками с долгими паузами.

В моём случае (MSP430F149) - 60К. Размер передаваемого файла (.uue) - 81К

>А последнюю прошивку на всякий случай в АТ45 сохраняете?

>Нет, а зачем?

>Ну так на всякий случай... что бы в любой момент по команде сервера перепрошить?

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



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

Нажмите для просмотра прикрепленного файла

Сергей что с Вашим емейлом? - не могу отправить письмо... приходят отчеты о ошибке...?

За исходник спасибо...
Посмотрел Ваш пример... все понятно кроме декодирования RC4....? Не подскажите где можно почитать что то толковое по этому вопросу? Может у Вас имеется какой то пример программный кодировка => декодирование... Из того что прочитал в инете понял что в RC4 есть ключ (массив) разной длины по которому идет кодирование и декодирование...? но какой алгоритм не очень представляю ?

>Файл забирается по протоколу HTTP через 80 порт с обычного web - сервера

Тогда у меня вопрос как вы его выкладываете на сервер и как читаете на сим300 ? HTTP - не поддерживает ведь работу с файлами, нужен FTP а с ним на сим300 и с нашим доступом в инет от операторов практически нереально работать... Как я понимаю на сервере тоже должен быть какой то алгоритм работы по которому он по запросу с устройства выдавал частями файл...? - думал разработать для этого дела протокол обмена с сервером... как вижу а Вас система наверное проще?

...уже позже почитал про формат .uue - довольно интересный формат...

Как так "не поддерживает" ? Очень даже поддерживает... Тот же самый GET и поехали. А к тому же SIM300 с производства снимается, а у пришедшего на смену ему SIM900 есть даже встроенная поддержка механизма работы с файлами на http/ftp (правда, при чтении есть ограничение на длину).

Если спросить у Google "RC4 описание" то он всё и расскажет
А ещё есть хорошая книжка :
"Брюс Шнайер "Прикладная криптография".

Как выкладывать - даже непонятно, в чём вопрос? Копирую туда файл (руками), как ещё?
А как забираю - вот кусок обмена между SIM300 и процессором:

AT+CDNSORIP=0

OK
AT+CGATT=1

OK
AT+CIPCSGP=1,"internet.beeline.ru","beeline","beeline"

OK
AT+CIPSTART="TCP","195.34.238.215","80"

OK

CONNECT OK
AT+CIPSEND

> GET /v100.uue HTTP/1.1
Host: 195.34.238.215


SEND OK
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Tue, 20 Nov 2007 18:02:28 GMT
Content-Type: application/octet-stream
Accept-Ranges: bytes
Last-Modified: Tue, 20 Nov 2007 17:30:42 GMT
ETag: "f09869139b2bc81:a04"
Content-Length: 82275

YoRcY

M,4``"CQ```(^0-($L!(JH[`2,):P$IR=LD"`6B`!PD,F`/)`WP`A`/)#(@#"
M0RX`PD,I`/)`[P`J`/+0\``;`.)#&0#RT%\`&@#20Q\`PD,=`/)`_``>`,)#
M,P#"0S$`\D,R`/)`&0`W`,)#-0#R0.8`-@#"0P``PD,!`,)#)0#"0RT`@D.F
M`<)#!`#"0P4`@D-@`8)#8@&"0V0!@D-F`8)#@`&"0X(!@D.$`8)#A@&"0X@!
....
....




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



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

Нажмите для просмотра прикрепленного файла

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

За наводку спасибо!



здесь тоже все ясно... а как файл с модуля забираете - просто все что льется с порта в память пишите? АТ45 успевает все записать? еще как я понимаю файл .uue нужно преобразовать в нормальный вид (хотя по спецификации вроде все несложно выглядит преобразование 4 байта в 3)...

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



ну да так и планирую...

Как минимум еще одной "идеи" не хватает
Неплохо еще сжимать образ. Бинарные коды программ неплохо сжимаются. Несложные алгоритмы могут сжать в 2-а раза и более.

Не все операторы хорошо пропускают активные FTP соединения. Надо побеспокоится о наличии пасcивного FTP.
Вообще могут возникнуть проблемы с FTP серверами. Неплохо было бы подумать забирать прошивку с mail-сервера. Это более гарантированный и надежный сервис и не требует особых усилий для прохода NAT-ов.

С легкостью. Там собираешь страницу в буферной памяти (с любой максимальной скоростью SPI), а затем записываешь всю страницу.

С такими объемами кодов как у нас и с сегодняшней стоимостью гпрс-интернет трафика - сжатие наверное будет лишним - разве что как метод дополнительного кодирования прошивки

Да с FTP никак не возьмешь... Можно и с mail-сервера забирать по pop3 но фактически это будет одно и тоже...

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



у 161 2 буферные страницы - можно еще и поочередно писать ( как обычно и делают)...

Скорее я имел ввиду то что с порту сим300 может литься и служебная информация, а при таком объеме различить ее не будет возможности...

По GPRS чем меньше размер файла тем больше вероятность его скачать.
Речь не о цене трафика, а вообще о вероятности доставки. Условия upload-а резко отличаются от download-а у провайдеров.
Часто приходилось видеть как после 100 кБ GSM сеть резко тормозила передачу файлов. Если на компе легко берут и рестартуют, то в embedded дивайсе это выливается в долгий зависон.
Еще хуже ситуация когда upload надо делать сразу на сотне, а то нескольких сотнях дивайсов. Тут лишний десяток килобайт может стать критическим.

Ну а FTP и Mail отличаются принципиально количеством логических каналов связи при перекачке. Это может оказаться важным в некоторых случаях.

Ну а патчи для программы можно и SMS-ами посылать. Вполне хороший и надежный способ.

я имел ввиду HTTP и mail

Здесь тоже не так просто. WEB сервера умеют поддерживать сжатие контента по gzip. Интересная фича, если есть ресурсы памяти на этот алгоритм.

Если Ваш клиент не будет передавать HTTP заголовок типа Content-Encoding: x-gzip, то Вам эта проблема не грозит. Сервер не будет сжимать передаваемое содержимое.
Ну и трафик конечно будет побольше

Бинарные если не зашифрованные. Зашифрованная программа при архивировании только увеличивается в размерах.

Использовать at45 - идея хорошая. Просто предусмотрите 2 банка для прошивки (текущая рабочая и обновляемая). При сбое в одном из банков программу можно будет всегда восстановить из другого.
По поводу метода перепрошивки. У нас было реализовано 2 способа:
1. Сервер даёт команду устройству на загрузку блока данных размером со страницу памяти at45. Устройство принимает её, проверяем crc посылки, сохраняет и отправляет подтверждение. После приёма всех страниц прошивки даётся команда на перепрошивку. Вариант довольно сложный т.к. требует написание сервера.
2. Устройство само скачивает прошивку с сервера с помощью http-запросов. Метод GET позволяет скачивать не только весь файл, а и выбранный диапазон байт (0-1023, 1024-2047 и т.д). Плюс метода в том что устройство само контролирует процесс загрузки, перезапрос выбранных страниц если не получено обновление, реконнект к серверу. Значительным плюсом является то что не нужно писать специальный сервер для обновления и все HTTP-сервера с которых я пытался скачивать прошивку поддерживали Partial Get. Минус - данные пришлось делать ascii-кодированными (хотя сейчас вижу вариант решения без кодирования) и оверхед при каждом запросе порядка 300 байт (шапка http-запроса).


В целом второй вариант показался более простым и сейчас успешно реализован. Осталось немного подрихтовать его чтобы обойтись без ascii-кодирования. Обновление ПО размером 64к (~150к gprs-траффика после доработки может уменьшится наполовину) занимает 2-3 минуты.

Или я торможу или чего-то не понимаю. А почему "пришлось ASCII-кодированными" ? Чем бинарник хуже ? Ведь вроде как нет совершенно никаких сложностей получить по GET бинарник ?

Проблема была в ключевых словах возвращаемых от модема (NO CARRIER и ERROR) которые могли попасться в передаваемой прошивке. Основня программа могла принять их за сбои в работе tcp/ip стека модема и решить что связь прервана. Не хотелось вводить дотошную обработку текста получаемого от http-запроса от того и возникла такая проблема. Сейчас всё уже исправил - зашифровал прошивку, получил бессмысленный набор байт в котором подобные ключевые слова не встречаются и не мешают работе основной программы.