В даташитах и в 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 - там как раз бутлоадера нету - конструкция сложная и ненадежная, менять пришлось все- от стартапа до линкерскрипта, наигрался и забросил.

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

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

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

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

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

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

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



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

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

Так ядро одно и тоже.
Что они для разных кристаллов разные ядра клепают что-ли ?

Если хочется универсализма на разных типах AVR с применением SPM, то этого легко добиться: выделите небольшой косочек программы с этой командой в процедуру; помести эту процедуру в конец памяти (там, где есть BLS - она в неё и попадет, там где BLS нет - попадет в Application Section); обращайтесь к этой процедуре хоть из приложения, хоть из загрузчика по известному смещению от конца памяти. При такой организации ПО и приложение может "шить" Flash (в BLS и Application) и Boot, если таковой имеется...

+1 я так и делал.

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

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

Т.е., обновлять загрузчик в работающем у пользователя приборе можно, но это не есть хорошее решение ...

Я тоже был удивлён необходимостью обновления загрузчика, но потом, в оправдание автора топика, в голову пришла мысль - для чего это может быть использовано. Например, устройство имеет несколько интерфейсов для общения с "внешним миром"; в BLS не помещается код, позволяющий обновлять приложение с любого из имеющихся в устройстве интерфейсов; перепрошивкой загрузчика можно дать возможность владельцу устройства обновлять приложение удобным ему (владельцу) способом.

Поскольку перед записью страницы ее нужно очистить, то получается, что страницу, содержащую Do_spm переписать нельзя. Тогда прошивка МК должна содержать 3 секции: приложение, загрузчик и секция с Do_spm(в концеNRWW). Первые две перекрестно обновляются, а 3-я обновлению не подлежит.


Действительно МК имеет 2 интерфеса (СОМ-порта) для общения с "внешним миром": на однои RS485, на другом GSM-модем, который получает обновление для МК и хранит его в своей памяти. С обновлением через RS485 проблем нет, а вот при обновлении с GSM-модема загрузчик должен кроме всего прочего поддерживать минимальную функциональность модема. Здесь есть некоторые ньюансы, которые, возможно будет необходимость подправить. Отсюда и такой большой размер загрузчика (~3k) и желание иметь возможность его обновлять.

Само-собой разумеется...

P.S. Впрочен при большом желании и её можно переписать: если при её стирании/записи использовать SPM (ну, или Do_spm), специально расположенные в других страницах BLS.

Если размещать Do_spm в BLS, то загрузчик может быть "ну очень" большим: всю неиспользуемую память в Application section можно использовать под загрузчик. Можно даже почти весь загрузчик разместить в Application section, за исключением, разумеется, векторов и Do_spm.

Сама Do_spm у меня занимает незначительную часть загрузчика, а размещать часть загрузчика в Application section имеет смысл только если он весь не помещается в NRWW.

Я тут подумал,как оно должно выглядеть.
1. Имеется ядро с Do_SPM, я уже говорил.
2. Перепрошить загрузчик может аппликуха, забив все имеющееся ОЗУ кодами загрузчика, построив системный вызов, т.е что надо передать в регистрах - crc16 памяти, начальный адрес блока, размер и может еще что-то. Дальше -jmp Boot
3. После прошивки - верификация и ресетимся, если все ок, либо jmp 0 если засада. В крайнем случае, само ядро может пропатчить точку входа. Это пока не продумано.
4. Если теперь управление перехватывает загрузчик, можно менять аппликуху.
кто поделится мыслями о том, как унифицировать понятие "живой загрузчик" ?
ЗЫ придумал. Когда вызываем Boot с определенными значениями в регистрах - сбрасываем оттуда собаку.
Не думаю, что изложил мысль понятно, попробую написать программу.

Вообще, конечно, самообновление загрузчика это от лукавого.
У меня недавно в диктофоне edic такое самообновление закончилось фатально для устройства.

Есть хорошая статья по этой теме http://easyelectronics.ru/avr-uchebnyj-kur...ootloadera.html доходчиво написано.

А памяти под прошивку на плате нет? У меня тоже есть подобные устройства. Во всех загрузчик просто проверяет наличие обновления в внешней flash, обновляет основную прошивку при наличии обновления, проверяет целостность и производит восстановление при сбое. Сам он не занимается скачиванием прошивок. Для этого предусмотрена основная программа которая может принимать прошивку по gprs, USB или com-порту и ложит её в внешнюю загрузочную память.

Мне страшно представить если во время обновления загрузчика произойдёт сбой (например кратковременно пропадёт питание) - кто его (загрузчик) восстановит. Поэтому ИМХО правильней загрузчик не обновлять вообще!

Все это понимают (в том числи и ТС), но, как я понял, у ТС загрузчик довольно сложный и "сырой", а устройства поставлять - время уже пришло. Поэтому, для возможного исправления "ляпов" в загрузчике, ТС и желает заложить функцию обновления кода самого загрузчика.