Приветствую.

Разбираюсь с at91, пишу простой бутлоадер по USB (без криптографии и пр.). Драйвер для USB - CDC, пример с сайта работает вполне исправно, слегка подточил для себя.

Атмеловскую доку почитал, но пока пребываю в конфузии

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

Заранее благодарю за советы и замечания.

Из PC лучше слать блоками по 64. Бут собирает два блока и заливает страницу.


Перед началом в бут передается размер прошивки.
Хедер не обязательно, а вот CRC было бы неплохо.

По 64 байта? А почему не сразу страницей, т.е. 256 байт, чем такой подход лучше?



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

Для RS232 такой подход был бы лучше, для USB CDC я бы рекомендовал использовать большие пакеты (1-2 страницы).


То есть как? Вычитаем из общего размера длину каждого полученного пакета, если 0 - конец передачи.

А вообще лучше сделать простенький командный интерфейс, чтобы PC говорил устройству, что делать: грузить/читать данные, запустить приложение и т.п.

что-то я все равно не догоняю
Предположим размер образа 5088 байт. Пилим его на куски по 256 байт (это размер страницы для at91sam7s256), получаем 19 частей по 256 байт и 1 кусок размером 224 байта.

Как здесь может помочь Ваш подход?



для начала реализую что-то простое, чтобы просто работало, а потом буду добавлять фичи.

1. Говорим загрузчику на кристалле: размер образа L=5088 байт.
2. Передаем 19 пакетов по 256 байт. Загрузчик вычитает размер пакета из размера образа (L=5088, L=4832, L=4576...L=224)
3. Передаем последний пакет 224 байта. В этот момент L=0, передача закончена.

Приветствую.

Я так и подумал, но тогда нужно передавать и размер пакета? Ведь принимаемый по USB буфер может быть бОльшего размера, например, 300 байт.
Сорри за глупые вопросы я только разбираюсь.

Размер и так будет известен, но лучше снабдить каждый пакет хидером, где будет указано:
1. Что это за пакет (код команды)
2. Его длина
3. и т.п.
То есть сделать свой простенький протокол обмена.

Ага, таки хедер нужен - туда же можно и CRC поместить.



То есть здесь можно передавать команды - например, запись страницы, чтение, запуск и пр. ? Т.е. простой командный интерфейс.

Спасибо, сейчас перспектива намного яснее!

Еще такой вопрос: приложение, которое будет загружаться бутлоадером, должно быть откомпилировано и слинковано как-то особенным образом или обычным? Где-то читал, что вроде советуют первые N байт заполнять нулями, для этого в IAR есть выходной формат mpds-code. Или я не так понял?

Спасибо!

Приложение должно быть собрано и слинковано:
1. Для старта с соответсвующего адреса
2. Со своим startup'ом, учитывающим наличие bootloader'а

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

Вот в этом документе http://atmel.com/dyn/resources/prod_documents/doc6282.pdf посвященном бутлоадеру, почему-то ничего не сказано про то, как учитывать наличие бута из приложения

Что должно содержаться в C-startup'e приложения (ведь о нем речь?) - таблица векторов, объявленная в коде бутлоадера? Или может быть есть где-то почитать об этом?

С таблицей векторов в случае SAM7 все достаточно прозрачно - можно сделать remap и расположить её в RAM, или использовать ту же таблицу, что и bootloader.

В самом загрузчике перед передачей управления следует сбросить использованную периферию и запретить прерывания.

А в вызываемом приложении потом включать прерывания? А с чем связана необходимость отключать прерывания на момент передачи управления?

Спасибо.

Да.

Вероятностью улететь из приложения в неизвестном направлении.