Вопрос по структуре hex файла Опции

[DeC_NN]

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

[mempfis_]

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

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

[DeC_NN]

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

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

[mempfis_]

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

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

[Арк К]

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

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