bootloader Опции

[Nikola Kirov]

хочу написат свой bootloader для ATmega но не поннял из документации как написат его в IAR.
1. Как указат IAR-а какой обем Boot Memory?
2. Как указат что соответсвущие функции принадлежат bootloadera?
3. Как из своеи програме въизват bootloadera?

или написания bootloader -a под IAR совершенно по другому делается?

[prottoss]

хочу написат свой bootloader для ATmega но не поннял из документации как написат его в IAR.
1. Как указат IAR-а какой обем Boot Memory?
2. Как указат что соответсвущие функции принадлежат bootloadera?
3. Как из своеи програме въизват bootloadera?

или написания bootloader -a под IAR совершенно по другому делается?

Сам, честно говоря, бутлоадер не писал, врать не буду. Но мне кажется, что надо
1. в xcl-файле определить сегмент кода для бутлоадера с определенного адреса, нужного объема. По объему смотри даташит на используемый МК.
2. При написании функций, пренадлежащих бутлоадеру, необходимо указывать, к какому сегменту (естественно к сегменту оного) они пренадлежат
3. При программировании МК предварительно запрограммировать фьюз-биты, относящиеся к определению памяти под бутлоадер.
4. не знаю, как с таблицей прерываний. Может она в IAR автоматом закомпилится выше нового сегмента, а мож нет.
В любом случае надо компилить и смотреть ассемблерный листинг - что получилось

Может я, конечно, чушь нагородил, но, мне кажется примерно так это делается. До Нового Года тож собираюсь написать бутлоадер для USB

[Nikola Kirov]

Интересно мнение из человека кто писал bootloader именно под IAR.

[bmf]

Именно под IAR и есть у Atmel: AVR109 - Self-programming
pdf + исходники
h**p://www.atmel.com/dyn/resources/prod_documents/doc1644.pdf
h**p://www.atmel.com/dyn/resources/prod_documents/AVR109.zip
и никаких трудностей переделать для требуемого камня не представляет

[VladislavS]

prottoss прав, в IAR размещение сегментов в памяти надо ручками в xcl править. В примере с Atmel лежит экселевский скрипт, который это xcl генерит.
Но мне кажется лучше это сделать ручками для полного контроля и понимания.

[IEC]

Вообще то сначала делается загрузчик, а потом через него заливается основная программа. Загрузчик размещается в верхнюю область памяти программ и при первом включении берет управление на себя. Проверяет необходимость прошивки новой программы (состояние внешних портов или еще что нибудь), и, если надо, по любому интерфесу принимает код и шьет его в нижнюю область. Если прошивать код не надо - передает управление на основную программу по адресу 0000. Вообще то на этом форуме вопрос уже рассматривался неоднократно. Поищи.

[Olegovich]

prottoss прав, в IAR размещение сегментов в памяти надо ручками в xcl править. В примере с Atmel лежит экселевский скрипт, который это xcl генерит.
Но мне кажется лучше это сделать ручками для полного контроля и понимания.

Возможно (а скорее точно), ещё надо будет написать свой cstartup (ассемблерный файл который проводит первичную инициализацию и в котором записан переход на начало кода main).
Ну и останется придумать протокол для загрузки и правила входа в загрузчик, когда пользовательское приложение уже будет загружено. // я загрузчик кстати писал

[prottoss]

prottoss прав, в IAR размещение сегментов в памяти надо ручками в xcl править. В примере с Atmel лежит экселевский скрипт, который это xcl генерит.
Но мне кажется лучше это сделать ручками для полного контроля и понимания.

Возможно (а скорее точно), ещё надо будет написать свой cstartup (ассемблерный файл который проводит первичную инициализацию и в котором записан переход на начало кода main).
Ну и останется придумать протокол для загрузки и правила входа в загрузчик, когда пользовательское приложение уже будет загружено. // я загрузчик кстати писал

Не вижу смысла писать что то еще на ассемблере.
Пишем основную программу, начинающуюся с void main(void) или int main(void), кому как угодно.
За тем создаем сегмент кода, где будет располагаться бутлоадер. Пишем бутлоадер

void main(void)
{ bootloader();

......// основная программа
}


void bootloader(void)
{ if(условие для начала перепрошивки)
{ .......// шьем основную память
}
else
{ return;
}
}

[Olegovich]

prottoss прав, в IAR размещение сегментов в памяти надо ручками в xcl править. В примере с Atmel лежит экселевский скрипт, который это xcl генерит.
Но мне кажется лучше это сделать ручками для полного контроля и понимания.

Возможно (а скорее точно), ещё надо будет написать свой cstartup (ассемблерный файл который проводит первичную инициализацию и в котором записан переход на начало кода main).
Ну и останется придумать протокол для загрузки и правила входа в загрузчик, когда пользовательское приложение уже будет загружено. // я загрузчик кстати писал

Не вижу смысла писать что то еще на ассемблере.
Пишем основную программу, начинающуюся с void main(void) или int main(void), кому как угодно.
За тем создаем сегмент кода, где будет располагаться бутлоадер. Пишем бутлоадер

void main(void)
{ bootloader();

......// основная программа
}


void bootloader(void)
{ if(условие для начала перепрошивки)
{ .......// шьем основную память
}
else
{ return;
}
}

Так нехорошо. Загрузчик лучше компилить отдельным проектом, он не должен входить в функцию main, т.к. у AVR под загрузчик отводятся верхние области памяти. При таком (up) построении возможно придется перешивать саму область загрузчика, что чревато.
имхо, загрузчик и приложение д.б. независимы.

[prottoss]

Так нехорошо. Загрузчик лучше компилить отдельным проектом, он не должен входить в функцию main, т.к. у AVR под загрузчик отводятся верхние области памяти. При таком (up) построении возможно придется перешивать саму область загрузчика, что чревато.
имхо, загрузчик и приложение д.б. независимы.

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

[ObitJr]

+ если они будут разными проектами и еще выставить биты защиты - достаточно надежно получиться. Если прошивать одним проектом то можно потерять bloader - придется шить чем-нить другим

[Olegovich]

Мы ведь говорили выше, что загрузчик располагается по адресам, ранее определенным отдельным сегментом в xcl-файле. Т.е при получении прошивки после компиляции функция загрузчика будет располагаться по нужным нам адресам, т.е. по верхним адресам.

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

[prottoss]

Мы ведь говорили выше, что загрузчик располагается по адресам, ранее определенным отдельным сегментом в xcl-файле. Т.е при получении прошивки после компиляции функция загрузчика будет располагаться по нужным нам адресам, т.е. по верхним адресам.

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

Хотя я с Вами согласился, что проект основной программы должен быть отделен от проекта бутлоадера, сдесь я могу возразить. Когда мы пишем функцию и НЕ указываем адрес по которому должна располагаться функция - компилятор сам располагает эту функцию в сегменте кода CODE - этот сегент всегда определен по умолчанию и в нем располагаются все функции программы включая майн и стартап. А если нам надо, что бы функция располагалась в сегменте бутлоадера, тогда мы указываем принадлежность ее к сегменту и если надо, адрес с которого она располагается

[BVU]

Посмотрие еще вот это может пригодиться:

Прикрепленные файлы

 MegaLoad.rar ( 306.99 килобайт ) Кол-во скачиваний: 127

 

[IEC]

А можно и сегмент CODE указать начиная с F000h например для программы загрузчика. Проблема в том что загрузчик будет вечен ля процессора, а основная программа временная! До следующей перезаписи!

[Rst7]

Есть еще одна маленькая тонкость - где лежит библиотека.

Разрабатывал я прибор, он в флеше программ хранил архив событий, соответственно код работы с архивом, прерываний, сидел в сегменте BOOT (который был определен в xcl). А библиотеку пришлось xlib'ом пришлось трахнуть: все функции перенести в сегмент LIBCODE (из CODE) и пристегнуть его к бутсектору (в xcl). Сегмент INTVEC - туда же, в бутсектор.

[Nikola Kirov]

Пороботал над проблема и он оказался более сериознъи.
Значит боттлоадер сделаем. Ето не проблем.
Сделаем в другой проект. Там будем конфигурироват линкера с внешнии xcl файл.
И в примера от Атмел ето так. Потом запрограмируем процесор с проект боотлоадера и установим защиту на област боотлоадера.

Проблем получается потом. А в проекте где боотлоадер будем ползоват нада указат что верхная граница флаша ето начало боотлоадера. Иначе линкер может ползоват област боотлоадера и разположит там кое что. А для ето нада полности написат xcl фаил и конфигурироват линкер из него. Для маленкого проекта как боотлоадер не проблем сконфигурироват все из фаила. Но ето проблем при реалнъи проект. Я вручно так и не смог успешно конфигурироват мой проект.

Ест ли в IAR более простой метод сконфигурироват верхная граница флаш памяти?

[prottoss]

...Проблем получается потом. А в проекте где боотлоадер будем ползоват нада указат что верхная граница флаша ето начало боотлоадера. Иначе линкер может ползоват  област боотлоадера и разположит там кое что...

Проблема решается, что называется, в лоб:

перед функцией int main(void), в области, где, например, определяешь глобальные переменные пишем:

#define BOOT_LOADER_SIZE 0xFF // 256 байт, хотя можно сколь угодно
#pragma location = FLASHEND - BOOT_LOADER_SIZE
__root char __flash boot_loader_code[BOOT_LOADER_SIZE];

макрос FLASHEND определен в заголовочном модуле на примененный в проекте CPU. Например, в фйле для МК ATmega8515 - iom8515.h макрос FLASHEND имеет значение 0x1FFF

Естественно, перед прошивкой, массив boot_loader_code можно удалить. Однако, неоходимо проверять не увеличился ли код, после удаления массива. Размер сгенерированного кода можно увидеть, если в меню Tools->Options, на вкладке Messages в поле Show build messages установить пункт All

[Nikola Kirov]

prottoss тъй показал мне хорошее решение. Оно навело меня на пут истиннъй.

Для тех кто тепер будут сталкиватся с етого опишу как сделат все.

Сначала делаем проект толко для боотлоадера. Пример из ATMEL достаточно нагляднъй.

Потом из hex фаил с помочи редактора записъиваем в бин файл област боотлоадера.

В проект в которъй нада боотлоадер поставит в опциях линкера добавляем
ето для АТмега16

-Z(CODE)BOOT=1C00-1FFF
--image_input=C:\boot.rnn,Bootloader,BOOT,2
-gBootloader

Первая опция создает сегмент BOOT , нада диапазон указат в соотсветствие с памяти соответного контролера.
Вторая опция load file C:\boot.rnn (ето бинарнъи фаил боотлоадера) в сегмент BOOT и присвоивает ему индентификатор Bootloader.
Третая опция разрешает линкера place Bootloader.

Ето и все.

[prottoss]

-Z(CODE)BOOT=1C00-1FFF
--image_input=C:\boot.rnn,Bootloader,BOOT,2
-gBootloader

Хм... Это получается, что все таки в проекте с основной программой будет компилится код бутлоадера?

[Nikola Kirov]

Не будет компилироватся а поставляем в област боотфлаша готовъи машиннъи код.
Так является что в изходнъй файл проекта присуствует и боотлоадер и если област боотфлаша не защитена прописъивается и он. Мне кажется что етот вариант удобнъй.

[prottoss]

Не будет компилироватся а поставляем в област боотфлаша готовъи машиннъи код.
Так является что в изходнъй файл проекта присуствует и боотлоадер и если област боотфлаша  не защитена прописъивается и он. Мне кажется что етот вариант удобнъй.

Может быть так и на самом деле удобней, на вкус и цвет товарищей нет

[ObitJr]

Сколько писал, но никогда не видел что линкер "случайно" положит "что-нить" в верхние адреса...
А по идее вставки кода бутлоадера - какой собственно в этом толк и зачем тогда вообще использовать эту возможность - пишите стандартную либу, включаете в каждый проект и первой строкой вызывайте его тело...

[Nikola Kirov]

И как просто оформит bootloader как библиотеку? Включения боотлоадера в проект приводит к необходимости конфигурироват все опции проекта из xlc фаила а ето неудобно и сложно.
Я вообще не понимаю почему IAR не сделали работа с боотлоадера боолее удобной. И в документации вообще молчат по етой теме.

[prottoss]

И как просто оформит bootloader как библиотеку? Включения боотлоадера в проект приводит к необходимости  конфигурироват все опции проекта из xlc фаила а ето неудобно и сложно.
Я вообще не понимаю почему IAR не сделали работа с боотлоадера боолее удобной. И в документации вообще молчат по етой теме.

Вам же еще в самом начале топика говорли, что вообще не зачем бутлоадер включать в проект. В этом ПРИНЦИПИАЛЬНО нет необходимости. Бутлоадер сидит в микросхеме. Вы пишете новый проект, или, что более естественно, обновляете старый. Компилируете его. Естественно у вас есть программа для РС, не ажно для какой операционной системы, которая знает как общатся с Вашим бутлоадером. Эта программа Ваш новый код передает бутлоадеру, который, в свою очередь, записывает этот код поверх старого, то есть обновляет действующее ПО микроконтроллера.
И, по моему даже незачем парится со вставкой разных массивов (что я предлагал выше) и кода бутлоадера. Сам себя бутлоадер преписать не сможет - его область защищена от записи. Вам же достаточно только произвести контроль объема кода, что легко выполняется в ИАРе.
Зачем создавать себе много проблем из пустого места.
А обновить бутлоадер можно имея под рукой любой доступный программатор АВРов, который скорее всего у Вас есть, раз Вы общаетесь в этом разделе форума.
Так что совет Вам, не парьтесь, а пишите спокойно новые программы или обновляйте старые через бутлоадер.
Удачи.

[prottoss]

1