Товарищи, подскажите, в каком формате поступают страницы прошивки (hex файл) в бутлоадер пусть для определенности megaloader v 7.4 ?

Хочу переписать PC загрузчик, разбираюсь с форматом.

Код записи хекса в самом бутлоадере таков:


Где PageByte=256, т.е. 256 байт в странице. А как страница закодирована в хексе?

Кусочек хекса:


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

описание hex формата

Страницы никак не заданы. Адресация в файле линейная.

Если проект серьезный, обратите внимание на avr231, там же на сайте есть пример для PC и контроллера.

Если не серьезный проект, можете глянуть функцию записи на билдере - см. прикрепленный файл.

Спасибо интересующимся, особое xelax и Jhohn. Вникаю.

С формой хранения (hex) понятно. Появились следующие вопросы:

1. Пусть страница памяти состоит из 256 байт. Пусть одна строка в hex-файле состоит из 16 (dec) значимых восьмиразрядных значений. Значит ли это, что для записи одной страницы мы упорядоченно построчно проходим по всем значимым значениям в хексе, переносим 256 значений в некий буфер, после чего полученный буфер пишем в память микросхемы? Соответственно далее повторяем цикл со следующими 256-ю значениями...

2. Прошу помощи в комментировании функций из лоадера (исходники megaloader приложил). К сожалению, я сишник, в азме плохо ориентируюсь.

fill_temp_buffer(TempInt,i); //call asm routine. - Сохраняет пришедшие значимые байты во временный буфер?
write_page(PageAddress,0x03); //Perform page ERASE - Команда на очистку страницы памяти?
write_page(PageAddress,0x05); //Perform page write - Команда на подготовку к записи в страницу памяти?
enableRWW(); - Есть соображение, что это как раз запись временного буфера в память кристалла?
read_program_memory(PageAddress + i,0x00); - Чтение (верификация) записанной в кристалл страницы?

3. Насколько разложил "по полочкам" алгоритм, лоадер принимает данные в виде:
а)Номер страницы
б)Значимые байты в двухбайтовом аски-представлении
в)Контрольная сумма

Так ли это?

Конечно, есть заголовок в начале сессии, и прочие символы протокола соединения/подтверждения, но не в этом суть процесса

Ваш вопрос сводится к следующему: последовательно ли расположены данные в hex файле?
- В зависимости от того как вы располагаете данные в памяти программ. Как правило данные располагаются последовательно. Вы это можете видеть по адресам: у следующей строчки .hex инкрементируются адреса на 16.

AVR109 - Самопрограммирование
write_page(PageAddress,0x03) пишет в SPMCR 0b00000011 - что соответствует очистке страницы
из ссылки выше:
"Запись страницы
Данные после того, как они были загружены в буфер страниц, должны быть записаны во Flash память. Для выполнения этого необходимо, как это было описано выше в пункте описания алгоритма стирании страницы, установить Z регистр. Затем устанавливаются биты PGERS и SPMEN в регистре SPMCR, а потом в течение четырех циклов необходимо запустить SPM команду."

write_page(PageAddress,0x05) пишет в SPMCR 0b00000101 - запись непосредственно

enableRWW(); - нет, читайте ссылку выше а то обленитесь ))


Да

Сообщение отредактировал Jhohn - Oct 22 2010, 22:24

Я бы рекомндовал забить болт на изучение форматов, а просто конвертнуть hex2bin и работать с бинарным файлом - это НАМНОГО проще.

demiurg_spb, спасибо за совет! Как раз раздумывал над механизмом набора байт в страницу. С бинарником попроще

А я бы не стал забивать болт, если хотите сделать универсальный загрузчик.

Например такие ситуации как будете через bin обходить?

1. Разрыв в адресном пространстве. Например некоторые переменные аффтар кода разместил по фиксированным адресам, не попадающим в адресное пространство, которое линкер заполнил кодом. Передавать FF, которые будут заполнять адреса между кодом и данными?
2. Образ eeprom через бинарь как передавать? Или его отдельным файлом?

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

С этим не спорю! Но время то уходит...

Почему бы тогда не взять другой бутлоадер, который написан на Си? Такие можно найти в сети и даже на сайте Атмела.

Введи 2 дополнительные команды в поле команд строки
6 - конец страницы
7 - начало страницы
входной Hex файл обрабатывай на PC
и делай выходной
с включением этих команд
в контроллере все упроститься:
в RAM делаешь буфер на 256 байт и заполняешь ого кодом 0xFF
грузишь его из Hex файла от начала страницы до конец страницы
пишешь во Flash далее в цикле до конца файла
и будет тебе щастие