Вопрос по структуре 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_]

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

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