Пишу bootloader для xmega - заливка hex файла в контроллер посредством usart.
Собственно уже написал и даже работает. Все hex файлы прошивок на которых произвожу проверку работоспособности имеют структуру в которой адреса расположены последовательно, т.е. нулевая страница, затем первая, и т.д. Собственно под это заточен мой бутлоадер.
При этом задался вопросом - а не может ли после компиляции очередной программы сгенерироваться hex файл c разбросом страниц? Т.е. например такой файл в котором сначала идет часть адресов нулевой страницы, затем первая страница, вторая, а потом скажем еще часть адресов нулевой страницы. В этом случае по моему алгоритму бутлоадера первоначальные адреса для нулевой страницы я потеряю.
Подскажите могут формироваться такие hex файлы или мои опасения напрасны и адресация в файлах прошивок (скажем сгенераированных winavr) всегда идет последовательно?

Такие файлы могут встретиться. Насчёт WINAVR не скажу.
Но в жизни видел.
Как и размер "страницы" - который не размер страницы, а просто количество байт с указанного адреса - тоже бывает разным. И адрес может быть не "круглым" числом.

Сообщение отредактировал Genadi Zawidowski - Mar 14 2013, 12:37

Если флэш-память контроллера больше 64К, то в hex-файле будут включены специальные записи адреса сегмента памяти. Под сегментом здесь понимается кусок памяти в 64КБ. Это сделано потому, что в стандартных записях хекса адрес только двухбайтный.
А порядок следования записей хекса есть следствие работы линкера и вполне может быть так, что записи не всегда могут идти подряд. Поэтому, лучше следовать букве стандарта, если хотите, чтоб бутлодер понимал любые файлы, сгенерированные любым линковщиком

Подобный маразм врятли Вы получите. Но запросто можете получить такой вариант, когда не все строки будут содержать 16 байт полезных данных. Я видел как иар спокойно генерит такие файлы. Когдато для моего бутлоадера для мега128 подобные сокращённые строки стали камнем предкновения. Выход был найден - поставил галочку fill unused memory все файлы стали генерироваться без сокращённых строк. Ещё одна проблема касающаяся файлов с размером более 64к - это наличие команд переключения страниц памяти. После такой команды адресация обычно снова начинается с нуля.

Сокращенные строки не проблема, у меня обрабатываются строки любой длины. Переключение сегментов тоже работает. А вот чего нет в моем бутлоадере - это защиты от таких хитрых хексов. Вот сколько не пробовал сейчас компилировать атмеловские исходники разного размера, все время на выходе получается правильный hex файл c последовательной адресацией, без возвратов.
Можно конечно сделать защиту от такого хитрого хекса, при возврате к уже записанной странице, сначала вычитывать ее, добавлять новые слова и снова записывать, но у меня память в области бута уже почти под завязку, боюсь этот код не влезет.

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

Можно шить bin-файл. Размер записываемого блока тогда может быть кратен размеру страницы flash.
К тому же не нужно будет пребразовывать из хекса (место сэкономится) .

Это где же столько оперативки взять, чтоб всю флэш туда вместить?
Я, например, делаю так. hex-файл при помощи специально разработанной утилиты для PC компилируется в загрузочный файл с разбивкой на страницы с шифрованием (если требуется), туда добавляем информацию о принадлежности к устройству, CRC всей флэши и т.д. Затем, опять же при помощи спец утилиты, которая связывается с бутлодером контроллера и делает все необходимые проверки соответствия, содержимое флэши передаётся в контроллер постранично. Каждая страница идёт со своей собственной CRC16, проверяется бутлодером, им же расшифровывается и пишется во флэш. Другими словами, hex разбирается на большом компе, а пользователю отправляем только файл образа прошивки и маленькую утилитку.

не встречал хексов с беспорядочным размещением блоков данных (хотя это допускается его структурой и "стандартом"), но сплошь и рядом бывают хексы, когда в них имеются "дыры", т.е. участки адресов, для которых данные не определены.

У меня собственно откуда все эти подозрения возникли. Я такие хексы видел для 51-го контроллера. Вот прицепил файл с примером (поставил там комментарии, чтобы не искать). Это hex сгенерированный кейлом под силабсовский контроллер C8051F340. Правда там в отличии от avr байты пишутся в память по одному, а целиком происходит только стирание страницы.
Для avr пока таких файлов не наблюдал.

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



Это по сути ничем не отличается от перепрошивки на месте обычным программатором. Вы даёте возможность пользователю самостоятельно обновить ПО. Даже если обновление ПО не удастся он всегда может самостоятельно заново попытаться прошить устройство.
Если у топикстартера нет необходимости удалённого обновления ПО то подобный метод вполне может подойти. В одном из моих первых устройств с загрузчико atmega128 на ходу успевала принимать hex-файл, выделять страницы и прошивать flash контроллера. Но я всегда хотел чтобы ктото написал утилиту для PC которая могла-бы разбивать бинарный файл и по принципу запрос-ответ отправлять данные постранично.

Согласен, такой подход выгоден для удалённых и/или недоступных устройств (марсоход ) в таких случаях на доп. флэш-памяти нельзя экономить

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

Вот, посмотрите. Мега162. Во второй строке - адрес устройства. Надо убрать расширение rar.

Так в этом файле я никакого "криминала" не вижу. Все в порядке. Вот если вторую и третью строки переставить местами, тогда да - уже проблема.

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