Народ, вот такой вопрос:
сейчас хочу вплотную занятся ARM, есть два конкурента AT91(на FLASH) и LPC. Но вот есть такая задача (уже реализованная на AVR)мне нужно чтобы при старте запускался мой загрузчик который по заданному мной каналу связи мог бы перепрошивать основное приложение и потом передавать ему управление. Дак вот есть ли в этих ARM возможность самим себя перепрошить, без замыкания внешних пинов, а просто взять и прошить определенную область памяти? Ну и соответственно есть ли поддержка механихма передачи управления на польховательский загрузчик, а из него в приложение?

Заранее всем спасибо,

Михаил

Насчет AT91 ничего сказать не могу, но для LPC можно сделать так: делается прошивка для него, которая стартует первой и с помощью IAP (In application programming) прошивает основное приложение в определенную область флэша, а после этого передает на него управление. IAP работает без замыкания всяких пинов. А сам загрузчик у LPC так просто не прошьешь, да и не нужно это, поскольку есть возможность реализовать вышеописанный алгоритм.

Возможность подключить собственный бутлоадер есть у обоих (LPC и AT91).
Эта функция как правило называется IAP (In Application Programming).
Возможность защитить код от несанкционированного чтения также имеется (кроме LPC2104/05/06).

А можно по конкретнее ибо вот
есть конкретная задача: при старте нужно чтобы закпускался загрузчик(с поддержкой некоторых прерываний), потом он по команде пришедшей по CAN (или другому итерфейсу) передает управление приложению, или перепрошивает это приложение. Мне тут видится следующие вопросы:
1. Как происходит разделение векторов прерываний между загрузчиком и приложением
2. Для прошивки приложения мне нужно выполнятся в какой то специальной области памяти? Скажем в SRAM? Т.е. я должен сначало переписать функцию прошивки в SRAM, а потом передать ей управление? Но в этом случае как быть с векторами прерываний, их то я не могу переписать куда то.
3. Как происходит передача управления на загрузчик (при старте), на приложение при необходимости, и из приложения в загрузчик.

Люди дайте тогда хоть пример какой нить, или подетальней распишите как это все происходит.

С уважением,

Михаил

У LPC есть маленькая таблица векторов прерываний, которая может располагаться либо в начале Flash-памяти, либо в начале SRAM. Зависит ее расположение от настроек внутренних регистров процессора. Таким образом, можно разместить эту таблицу памяти и на ходу менять ее содержимое - какие-то вектора (например, FIQ) можно обрабатывать в бутлоадере, а другие (IRQ) в приложении.



Нет, для прошивки можно просто исполняться из Flash'a. Хотя, если хочется, то можно исполнять и из SRAM, но стартовать все-равно придется из Flash'a. А вектора прерываний, как я уже сказал, можно переписать.



При старте LPC родной загрузчик проверяет содержимое таблицы векторов исключений(прерываний) и если находит там по смещению 0x14 двоичное дополнение суммы всех остальных векторов, то передает управление по адресу 0x0 (вектор ресета). Далее стартует программа во Flash'e, которая может загрузить другое приложение и передать управление в ту область, куда она его загрузила.



Рекомендую скачать описание по интересующему процессору и почитать его. Там довольно популярно все написано.

Поставьте IAR например 5.11.

Если поставите по умолчанию, загляните потом в папку:
C:\Program Files\IAR Systems\Embedded Workbench 5.0 Kickstart\ARM\src\flashloader\

Там есть примеры загрузчиков практически под все процессоры.

Не у LPC, а у арма. Я кажется писал уже, лучше поместить в FLASH разумный обработчик IRQ и FIQ, на UNDEF и ABORT реализовать что-то вроде вываливания списка регистров и содержимого стека в последовательный порт с перезапуском.
От программы остаётся только програмирование контроллера прерываний (речь о AT91). Почему так: РАЗМЕЩЕНИЕ ВЕКТОРОВ В RAM ДОСТАТОЧНО ДУРНАЯ ИДЕЯ. Ибо затереть что-то в той области куда указывает NULL в силу разных программных глюков -- раз плюнуть. И дальше неописуемый и трудно диагностируемый глюкодром. А так оно в аборт вывалится, жалобно пропищит, поморгает диодиком и перезапустится, если как я говорю делать.

Можно посмотреть на сайте www tnkernel com. на его основе я делал себе обновлялку с sd карты.

А я там-же "оценил" такой (c ненужной промежуточной оберткой) подход к делу.

В подавляющем большинстве случаев это хороший вариант для bootloader.

Не лучшая, это точно.

Затереть вероятно и RAM тратится впустую, только вот на РЕМАПИРОВАНУЮ таблицу NULL не указывает.

Загрузчик размещаете в конце памяти, при запуске передаете управление ему (RESET вектор на него направьте).
Он ждет сигнала с внешнего канал и либо апдейтит приложение, либо запускает существующее.
Для получение приложения "снаружи" вам и прерывания-то не нужны будут, получить по любому интерфейсу десяток-два килобайт, имея в своем распоряжении все процессорное время (мы же в загрузчике !) легко можно и без прерываний.

И при неудачной заливке все вместе накрывается медным тазом.
Кроме того, например, у LPC в конце FLASH сектора по 32K - многовато для загрузчика.

И в начале накроется медным тазом. Запишутся первые 512 байт с правильной CRC векторов и CRP - этого уже хватит, чтобы ISP запускал только "приложение". Если "приложение" больше 512 байт - медный таз. Кстати. Если писать в конец и делать нестандартным способом - можно "не накрыться".

Bootloader сам себя не перешивает. И посему останется в неприкосновенности. Для пущей надежности можно и его область прикрыть от записи так-же, как и штатный.

Приложения, однако, запускает/не запускает тот самый bootloader, который остается целым.

Это если ему повезет записаться целиком.

Шансы, естественно есть некоторые "выжить". Но зачем играть в рулетку без всякой на то надобности.



Повторяю последний раз по буквам - ОН НЕ ПЕРЕЗАПИСЫВАЕТСЯ и по этой причине ему везет всегда.

А первый раз? Возмут пустой МК, программатор и начнут шить, после записи первых 512 байт у программатора сядут батарейки или 220 выключится или что-то зависнет. Поэтому я от CRP3 решил отказаться. Если что на CRP2 все стирать и снова.

Боже, какие ужасы, господа ....

А что мешает начать запись не с 0-го сектора, где IRQ, а с первого ?
и 0-й сектор записывать последним, после всех проверок, на лету исправив RESET вектор на себя ?

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

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

Пытайтесь неуклюже выкручиваться? Хоть перавя прошивка bootloader в нулевой сектор, хоть первая прошивка приложения туда-же абсолютно одинаково "опасны".

Проясните, пожалуйста, что есть "стандартный" и "нестандартный" способ записи ?

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

Стандартный - по нарастанию адресов, нестандартные - все остальные

Это ошибочные утверждения.

Уточните, пожалуйста, где именно действия не гарантируют результат ?

reset - на загрузчик, он в конце флеша.
Получает прошивку, если необходимо, ложит ее в флеш с первого сектора (0-й в кеше в RAM), после записи и проверки CRC (поблочно и всей прошивки) пишет 0-й сектор с уже исправленным RESET, указывающим на себя.

Вот когда он после стирания не запишется, то и будет "оболом". И совершенно не имеет значения есть остальные сектора, нет их...
Как следствие, уж совсем никакого значения не имеет порядок записи секторов.

хм. А чем вероятность незаписи 0-го сектора отличается от вероятности незаписи любого другого ? Мне кажется, что в случае, когда 0 сектор пишем последним, более вероятно то (примерно в SectorCount раз), что ошибка возникнет в процессе записи предыдущих секторов, о чем немедленно будет сообщено хосту, раздающему прошивку. В таком случае мы в наибольшем количестве случаев корректно отработаем сбойную ситуацию и сообщим персоналу.

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

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

Да ничем и по этой причине порядок не имеет никакого значения. - я не понимаю, извините, как вероятность порчи нулевого сектора в случаях записи [0....n] и [1..n, 0] может быть одинаковой ....

Уже писал - ни заглушки (для IRQ/FIQ ) ни переноc векторов RAM в принципе не нужны. Для SWI можно четко послать сразу на приложение, ибо bootloader-у они едва-ли нужны. Обработчики исключений в bооader ничем не хуже могут работать, чем в любом другом месте. С отладкой проблем тоже нет. Никаких особых причин, тем более "ряда причин", честно говоря придумать не могу.

Я такую проблему решал следующим образом.
1. Перед програмирование первых 512 байт запоминаем первые 64 байта в бувер.
2. заполялняем кодом 0xFF первые 64 байта в буфере програмирования.
3. програмируем блок.
После програмирования в сей прошивки програмируем сохранённые 64 байта.

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

Помогите новичку
Пишу bootloader для LPC 2478 под KEIL.

Проблема стара, как мир - загружаю bootloader в начало флэш. . Основная программа компилируется отдельно. Бинарник основной программы заливаю через USB во флэш по заранее известному адресу. Прыгаю на этот адрес: MOV PC, #0x6000. Прога не заводится. Отдельно основная программа работает. Переход по заказанному адресу тоже происходит (проверял дебагером). При переходе на Основную программу видимо начинает выполняться Startup.s основной программы, а там все адреса от 0x0, а не от моих 0x6000. Делать Remap и выполнять основную прогу из RAM, по-моему, глупость. Вот я и мучаюсь.

Сморел ветки:
"прыгнуть на другой адрес ROM"
http://electronix.ru/forum/index.php?showt...rt=#entry410209
"Опять про загрузчик"
http://electronix.ru/forum/index.php?showt...rt=#entry416511
"Самопрограммирование ARM"
http://electronix.ru/forum/index.php?showt...rt=#entry385320
И многие другие, но по причине крайне малого опыта, почти ничего не понимаю. Ну ещё это можно назввать глупостью, наверное... Короче, помогите,пожалуйста.
Что нужно сделать, чтобы передать управление на залитую через USB, прогу???

Заранее благодарен!!!

Дык самое простое - взять, например, "lpc24xx_usb_bootloader; AN10764 (LPC24xx USB bootloader)"
с этой странички: http://www.nxp.com/pip/LPC2478_1.html
и посмотреть...

RAM тратится??? :-))) При объемах 32кБ, например, что значат 64 байта???
Не надо грешить против истины :-)))
Размещение в RAM иногда наилучшее решение, особенно когда ресурсов немного.

Приведу пример. Записываешь маленький загрузчик в начале флэш , который загружает с какого-то внешнего источника (датафлэш или UART, например) программу загрузчик под любые нужды(USB, SD Card и т.п.) в RAM. Старт загрузчика...
При этом загрузчик в начале флэш получается очень маленький (можно вписаться в 4кБ).
При работе загрузчика по барабану как RAM тратится. Ничего не затрешь.

Или такой пример. У меня стоит датафлэш со всякого рода картинками и загрузка этих картинок так и сделана -- с SD карты загрузчик записывается в RAM и записывает картинки на датафлэш. Экономия флэш около 6 кБ.

Проблема не в том, что тратится, а в том, что тратится без всякой надобности.
32K RAM, говорите у Вас? Тогда сколько у Вас Flash? - сотни К- полмега и при этом Вы в качестве весомого аргумента пытаетесь представить "Экономия флэш около 6 кБ"
Так вот, Ваши слова

К Вам и относятся.

Иногда имеют право быть ЛЮБЫЕ решения. Но львиная доля из возможных - ну очень иногда. Кроме того, причем тут грузить или не грузить нечто в RAM, если я говорил только о том, что размещение таблицы векторов в RAM можно не использовать никогда и не испытывать при этом никаких проблем ни с чем.

1.Я, правда, не понимаю, как реализован в этом примере запуск загруженной программы.
а) загрузили прогу через какой-то интерфейс во flash;
б) Скопировали вектора в начало RAM;
в) Установили REMAP;
г) Дальше-то как и что? Как заставить выполняться загруженную программу?

2. Тут вот в этой же ветке уважаемый zltigo предлагает в RAM вообще ничего не копировать. И мне эта идея очень нравится. Но вот опять же не пойму, как запустить прогу?

Jump/Call. Любым способом http://electronix.ru/forum/index.php?showtopic=35580
Спрашиваете одно и то-же постоянно, уже где-то утверждали, что под отладчиком переход видите. Ну неужели не понятно, что в Вас проблемы НЕ с передаче управления, а в собственно программе.

Понятно... Я вот как представляю суть этой проблемы...
В загружаемой программе у меня все адреса функций считаются от 0x0, но эта самая программа загружается bootloader'ом, не в нулевой адрес. Она начинается у меня с 0x6000. Прога прыгает на адрес 0x6000, но после выполнения первой же инструкции опять возвращается в bootloader, так опять же эта инструкция оперирует адресом, который отсчитан от 0х0, а не от 0х6000. Вот что с этим делать, я и спрашиваю уважаемых форумчан, так как сам не допетриваю.

Это Вам, уважаемый zltigo, позволяют ставить камни с сотнями кБ... А мне со скрипом разрешают ставить LPC.
У меня же 32 кБ RAM и 128кБ flash. Программа не дописана, а уже 120 кБ занято. А надо-то чуть-чуть дописать. В этом случае 6кБ флэш--это весомый аргумент...
Хватит, чтобы навести красоту:-))).

Неудивительно, что ничего не работает. В проге обычно есть загрузка в регистр прямых адресов констант/функций и прочего. Если прога компилируется для работы с адреса 0, то она НЕ БУДЕТ работать на адресе 0х6000. Короче, прога должна работать на своём адресе. Для этого её нужно перекомпилировать (перелинковать) на другой адрес. Берётся скрипт линкера и в нём правится адрес начала флэш на нужный 0х6000. Потом перелинковка и всё. Прошивку можно заливать по адресу 0х6000.

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

Ну вообще-то, можно. Самому написать компилятор

Угу первое что приходит на ум. Может как-то менее трудозатратное.

А потребность-то в чём? Нужа такая прошивка, которую можно грузить по любому адресу флэша (ну типа туда, где в данный момент свободно) и там же её выполнять?

Ну вобщем да, или есть уже готовая прошивка без исходников которую нет возможности запустить с нулевого адреса. А так бы прерывания "отремапил" прыгнул куда надо и всё.

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

Большое спасибо, GetSmart!!!
Всё сделал,всё работает!

Ещё один вопрос. Хочется, чтобы исполняемая прога начиналась с адреса 0x0, а bootloader лежал бы где-нибудь в конце (чтобы не морочиться, каждый раз с линковкой основной программы). Но, при попытке переписать содержимое первых двух кластеров, Винда гооврит, что файла повреждены. Не подскажете, это Винда не даёт переписывать первые два кластера FAT16 или контроллер?

По хорошему загрузчик должен лежать по нулевому адресу и после сброса стартует именно загрузчик.
В противном случае могут быть проблемы вроде "всё сломалось"

Хм... Да... Это точно... Согласен.


Но тогда меня из любопытства интересует вопрос, чего же он в 0х0 не пишет-то?

А почему защитить код на LPC2106 нельзя?