Люди я чето непонимаю.
Итак цель - бутром записывающийся в конец флеш, для бутрома нужны прерывания, для того чтобы его собственная таблица векторов не затиралась приложением нужно также хранить ее в конце флеша, при старте переписывать в RAM и делать remap, при выходе из загрузчика делать remap обратно на флеш.

Так вот как это грамотно сделать в IARе?, кроссворксовский код

просто так не проходит. RAMSTART в линкер-скрипте сделал 00200100- пофиг, без команды remap работает с ней беда, до main проц не доходит. Думаю причина в том, что remap как -то не вяжется с инитом компилера? причем посмотреть отладчиком что происходит тоже не очень удается.

Что такое
RSEG INTRAMSTART_REMAP
RSEG INTRAMEND_REMAP
в статртапе? недопонял.

может есть где проект под IAR с ремапом а?

Не совсем то, что спрашивается, поскольку делает remap при старте на ОЗУ:

Сначала проверка, что сейчас по нулевому адресу. Записывается 0x12345678 в ОЗУ на неиспользуемый вектор, а потом сравнивается с нулевым смещением. И не забудте првильно установить вектора Exceptions для обоих случаев.

Сообщение отредактировал amw - Apr 20 2007, 10:46

Системная ошибка. Загрузчик вместе со своими векторами живет в начале ФЛЕША, а пользовательское приложение работает в ремапе. Этим мы гарантируем, что при любом слете в процессе перезаписи проц будет в состоянии стартануть и попасть хотя бы в загрузчик.
Вот рыба. проект состоит из двух - загрузчика и приложения.
Действия загрузчика -
1) инициализация ноги PIO принудительного старта загрузчика и PLL.
2) проверка был ли это старт из приложения, если да - запуск собственно загрузчика.
3) проверка был ли сигнал принудительного старта, если да - запуск собственно загрузчика.
4) проверка КС приложения. Если не совпала - запуск загрузчика.
4a) Если совпала - копирование векторов приложения в ОЗУ, ремап, переход на вектор сброса (старт приложения).
---- действия 1-4 происходят в __low_level_init() ----
5) собственно загрузчик. Сброс периферии, проверка был ли это вызов из приложения, если нет - ждать команду начала прошивки. Если из периферии - пропустить ожидание команды, команда была получена приложением.
6) собственно прошивка - допишите во вкусу
7) рестарт. После рестарта снова попадем в загрузчик, он проверит КС и т.д.


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

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

Да штука то в том что сам remap как раз и работает, только после него не работает ничего. Я кажется понял - pc после него указывает на рам а мне нужно чтоб оно из флеши выполнялось а таблица експекшены были в рам

Сергей Борщ
Насчет системной ошибки - я ему вектор ресета оставляю в начале флеша и не даю переписывать его через загрузчик.
Вообще спасибо большое, ушел думать.

Размер страницы - 128 байт, размер сегмента векторов - вдвое меньше. Чтобы переписать остальные вектора надо предваритально затереть их все, вместе с вектором ресета.

Не понял причем здесь размер страницы. Я по вектору ресета всегда в лоб пишу команду "b reset_загрузчика" если идет запись в начало флеш - это все что меняется в исходной программе. Адрес, который реально был в программе запоминается и по нему происходит прыжок в конце работы загрузчика. Правда нужно еще добавить вычисления, когда в начале программы стоит инструкция "ldr pc..". Но мысль насчет того что команда затирается понятна.

Все таки я что-то не пониммаю насчет remap. В приведенных примерах вроде нет никакого шамантсва с pc.Судя по логике после этой команды pc естественно не меняется и так как сейчас код выполняется из Internal Memory Area 0, то после подсовывание на это место RAM получается фигня. Вопрос - каким образом перескочить на выполнение кода из Internal Memory Area 1? Или я вообще все не так понял?

Да, вместо этого шаманство в файле линкера. Загрузчик исполняется не с отремапленых адресов 0x0000.... а с реальных адресов флеш 0x01000000.... Поэтому после ремапа его код остается на месте. Именно для этого я положил в архив исправленный загрузчик для иара FlashAT91SAM7Sx.d79, ибо родной из-за ошибки умеет писать только в адреса 0x00.....


А если программа пользователя хочет подвесить свои обработчики на остальные вектора? Можно конечно там сразу поставить LDR PC, AIC_IVR, но это уже ограничение, а как быть с FIQ?

Я уже понял вроде. Пасибо. Туплю бывает. Добавил еденички, только после команды ремап все равно не работает код. Прерывания отключены и всякие копирования векторов в рам тоже закоменчены. Отладкик такой код прошивать-отлаживать уже отказывается, наверно надо ковырятся в mac-файле.
А без ремапа работает - флешка шьется читается, нормально все. Волшебство.


Так, еще раз. Я при заливке программы через бутром меняю ей только вектор ресета, все остальное остается как есть.

А вот если так:

Если программа должна работать из РАМ
то
она вся линкуется по адресам 0х200000(секции кода и данных
упираясь своими векторами в адрес 0х20000
при старте она проверяет был ли ремап если не был то ремапирует
и продолжает выполнение по коду расположенному на 0х20000
содержание векторов дублируется на нулевые адреса автоматически
иначе
она линкуется вся по адресам 0х10000 (в РОМ векторы и секция кода , секция данных начиная
с адресов 0х200040)
при старте вектора из секции кода ручками копируются с адреса 0х100000-0х10003ф
на адрес 0х200000 после этого проверяется был ли ремап
после ремапа вектора автоматически дублируются в трех местах по адресу 0х0 0х100000 0х200000
и вуаля!

Хм. У меня работает. Как ругается когда не прошивает? У меня просто вис, попробуйте мой прошивальщик положить вместо штатного.Посмотрите в окне памяти что творится в области векторов. Окно дизассемблера не обновляется, а в окне памяти все изменения видны сразу.
Да, меня заклинило - у вас же загрузчик в конце памяти. Т.е. остается нехорошесть в виде переписывания сегмента с векторами. Что-то там не сложилось и прибор надо возвращать к разработчику вместо повтороной перепрошивки на месте.
Уже одно это действие на SAM7 нетривиально - надо изменить что-то в начале ОЗУ и посмотреть как это отразилось в нулевых адресах. После чего вернуть исходное значение. В моем варианте все гораздо проще - для старта приложения скопировал вектора приложения в начало ОЗУ, сделал ремап, перешел на адрес 0. Переход из приложения обратно в загрузчик - запретил прерывания, сделал ремап, перешел на адрес 0.

Есть несколько непоняток по скрещиванию программы с бутлоадером.
1. Если я ставлю линкеру например -DROMSTART=00008000 в программе, то размер выходного бинарника не меняется. Значит вначале файла идут вектора, а затем программа как и в обычном случае, но со смещенными переходами?
2. Если я хочу прошить в чистый кристалл сразу и прогу и бутлодер, то как быть с векторами программы? Получается, нужно самому в этом случае создавать табличку векторов перед началом кода программы чтобы все это вместе вело себя также как и после перепрошивки проги бутом.

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

Трудно сказать, не видя файла линкера. Зависит от того, как описан сегмент векторов - он либо линкуется в нулевые адреса ( -Z(CODE)INTVEC=00-3F ) либо начиная с ROMSTART (-Z(CODE)INTVEC=ROMSTART-ROMEND или подобное).
Я опишу как делаю я. Насколько это правильно - со стороны, наверное, виднее. Я использую AES Loader и на мегах и на ARMах. У меня загрузчик и приложение - два отдельных проекта. Я прошиваю сначала загрузчик, потом приложение. В процессе этого заодно тестируется канал связи. Если мне надо прошивать все сразу программатором (пока нужно было только на мегах) - я прошиваю загрузчик без лок-битов, прошиваю загрузчиком приложение, убеждаюсь, что все работает, считываю программатором всю память, открываю полученный .hex текстовым редактором и удалаю все строки, содержащие одни 0xFF. Получаю прошивку для масового производства. В голове крутится еще такой вариант - если прошиваем .hex, то можно "склеить" два файла (загрузчика и приложения) текстовым редактором или утилитой вроде srecord. Если прошивка делается из ИАРа через JTAG, то наверняка можно склеить полученный файл загрузчика с приложением при помощи postlink (не пробовал, не подскажу).
Про вектора - они находятся в начале приложения, загрузчик их копирует в начало ОЗУ и делает ремап. Поскольку приложение - отдельный проект, то для него естественным образом получаются и таблица векторов, и инициализация памяти.

У меня основная программа закачивает обновление через изернет, рестартует и затем бут его переписывает на место проги. В будущем бут должен будет уметь закачать прошивку через UART, но... незнаю, может и придется реализовать это сейчас, но времени в обрез. А пока хочу попробовать воспользоваться опцией линкера "Raw binary image"... Как все получится - отпишу.

==============================================================
Шить еще не пробовал (заменил FlashAT91SAM7Sx.d79 на ваш), но отладчик упорно начинает работать с нулевого адреса даже если ROMSTART=00100000. Какнибудь можно его научить учитывать ремап/неремап при запуске? А вообще линкует хорошо. Дописывает указанный в rawbinary image файл куда надо.

Кстати, как отладчика заставить вставлять больше брейкпоинтов? В некоторых программах при отладке у меня получалось ставить одновременно не больше 2-3х брейков. А взялся за бут - так он мне вообще фигу показывает и даже пошагам смотреть может только на ассемблеровский код. Чтото гдето забыл я настроить. Раньше пользовался шаблонами...

То же самое будет происходить и в железе. По нулевой адрес в зависимости от ремап/не ремап должна зеркалится команда перехода на загрузчик (с адреса 0x00100000) или на приложение (зеркалится с адреса 0x00200000, куда ее копирует загрузчик).можно. в .mac - файле написать соответствующий скрипт. Напишите, что конкретно он должен сделать, я накидаю скрипт. Пока непонятно зачем, но накидаю.

Отладчик не зеркалит флеш в нулевые адреса при старте. Это и надо исправить.
Отлаживаю пока в симуляторе. Оттого и удивляюсь насчет брейкпоинтов.
Проц - AT91SAM7X256, ИДЕ IAR 440A