В даташитах и в AVR109 упоминается, что есть возможность для загрузчика прошивать самого себя, но детально принцип не описан. Если загрузчик занимает более одной страницы, то, очевидно, уже после прошивки первой страницы целостность программы нарушится (могут поменяться распределение памяти, адреса вызова функций), и она не будет корректно работать. Где бы что почитать по этому вопросу?

Т.е. вы хотите, чтобы загрузчик обновлял сам себя.

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

2. Либо иметь область загрузчика размером (выраженном в страницах) таким, чтобы в ней помещалось два загрузчика. Далее алгоритм такой же как и в первом случае, только все действия происходят в области загрузчика.

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

это лок-фузами делается, там разница в том, что это NRWW секция и проц останавливается на время записи страницы.

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

Не обязательно. Просто обновление NRWW секции тянет за собой невозможность установки блокировки чтения и записи области загрузчика. Если в локере нет необходимости, проблем не существует.

Из AVR109: "The SPM instruction can only be executed from the Boot Loader section."

Непонятно, зачем они это написали, ведь в реале это не так.

В реале это именно так. То есть из области приложения выполнить SPM можно, но толку не будет.

Ойц. Увидел. Значит, путь один - только макс. размер загрузчика и поддержка его двух копий. Когда-то баловался с мегой48 - там как раз бутлоадера нету - конструкция сложная и ненадежная, менять пришлось все- от стартапа до линкерскрипта, наигрался и забросил.

А как же таблица векторов прерываний - ведь она будет в первом бутлодере.

Сообщение отредактировал MVJ - Feb 3 2011, 13:57

Я так понимаю, что нужно сделать некое ядро, использующее только регистры для работы и остальное ОЗУ - для содержимого страниц, туда весь код с использованием SPM и верификацию, загнать его в последние адреса, и оно сможет обновить таблицу векторов. Но размеров минимального бутлоадера может оказаться маловато для такого ядра.

Непонятно: зачем нужно обновлять bootloader? Ну, приложение - ясно, но - bootloader...

Но, если это всё же кому-то нужно, то, imho, сделать это "дешевле" в два приёма.
1. Загружается в Application Section программа загрузки bootloader'а.
2. Эта программа зашивает уже сам загрузчик.

Проблема с SPM - надуманная: достаточно в конце области BLS иметь код - типа функции Do_spm из примеров загрузчиков от Atmel. При необходимости программа из Application Section к нему обращается по заранее известному адресу...

Действительно непонятно.

Ведь например в mega48 или tiny2313 вообще только application section, т.е. секции загрузчика нет вообще. Но тем не менее есть поддержка самопрограммирования, т.е. имеет место быть команда SPM.



А вы не используйте прерывания.

А там, где есть загрузчик, команда не выполняется. Оно во всех ДШ описано буквально одним предложением. С беглого просмотра не найдешь.