Ух ты!!!! Вроде я уследил за ходом выших мыслей...
Я создаю массив buffer[4096], забиваю его данными, а потом в команде 51 просто указываю имя массива buffer(имя является адресом первого элемента). правильно ли я понял????

О, да!

Ложу я прошивку с помощью бутлоадера(сам он находиться по 0-му адресу) по адресу 0х00004000
проверяю целостность и прочее - все Ок.
передаю управление на прошивку вот так:

typedef void (*pt2Function)(void);

pt2Function BootCall = (pt2Function)0x00004000;

в итоге - ничего. он все равно крутится в бутлоадере.

может я не правельно передаю управление???

Утро вечера мудренее . Разобрался - надо было перед вызовом вышеописанного перехода сбросить все альтернативные функции портов. Но я не знаю почему данная процедура помогла.

Вот только перейдете вы по этому адресу в user-mode процессора и перенастроить стеки для других режимов уже не сможете.
Поэтому лучше вызывать вот такую функцию (для KEIL):

в проект добавить файл swi.s

и конечно в startup.s сделать импорт SWI_Handler

Спасибо за совет.
А можно более подробно прокоментировать код?

Что именно тут комментировать? Вы вызываете SWI прерывание, при вызове которого переключается режим cpu на supervisor и на всякий случай в ARM. И уже в этом режиме вы переходите на адрес пользовательской программы (адрес передается в r0).

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

Для организации загрузки программы написал несколько классов, которые должны использоваться в бутлоадере (AES шифрование, подсчет CRC и т.д.). Написал собственно загрузчик, но теперь осталось правильно все это скомпоновать.

Как сделать, чтобы определенные объекты классов компилировались с 0-го сектора (загрузчик), а остальные скажем со 2-го сектора (пользовательская программа)?

Вычитал, что это решается с помощью scatter, нашел где он настраивается в Keil, но там вроде можно всю программу сместить, а как сделать частями, ума не приложу.
Была идея сделать 2 разных проекта, один загрузчик и разместить его с 0-го сектора (и использовать далее во всех остальных проектах его без изменения). А второй проект это пользовательская программа, которая всегда начинается со 2-го сектора. Есть еще плюсы, у этого метода, но главные минусы в том, что:
- всегда надо четко и, самое главное, в ручную оговаривать точки входа в пользовательскую программу (включая вектора прерываний) и загрузчик, потому что при компиляции они не будут знать о существовании друг друга;
- хотелось быть часть однотипного кода по работе с интерфейсами, USB, CAN и UART разместить в загрузчике, чтобы не дублировать их в двух программах. Но тут встает та же проблема, ручного указания адресов методов и самое главное ручное резервирование памяти, которое используют объекты классов интерфейсов, чтобы компилятор пользовательской программы туда ничего не назначил.

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

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

Можно с этого места поподробнее? Т.е. саму идею понял, но как это все должно выглядеть - не совсем

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

Есть еще один минус у двух проектов. Я планирую использовать AES шифрование, которое жестко будет зашито в загрузчик, а значит все пользовательские программы необходимо шифровать одним и тем же ключем, это же касается и сигнатуры. Мне кажется это неправильно!!!

Теперь что касается общей части для обоих проектов. Смысл идеи состоит в том, чтобы дать возможность обновлять прошивку удаленно. В моем случае это происходит через штатно установленный отдельный модуль связи, который общается с другими модулями по CAN. Для работы на этой шине, разработан протокол обмена, позволяющий передавать файлы больших размеров, склеивать их на приемном устройстве, вести одновременный прием от нескольких устройств, ну и т.д. Это достаточно большой кусок куда, который не хотелось бы дублировать, чтобы не тратить лишнего, так как я и так уже вышел на использование 75% имеющейся памяти. А в добавок, этот фрагмент кода очень емкий по использованию RAM. Мне самому идея удаленного программирования не нравится, однако начальство настаивает на его присутствии, так как у нас уже были случаи, когда приходилось объезжать множество объектов для перепрошивки, а когда эти объекты находятся в разных городах или даже в странах это еще более утомительно.

для gcc примерно так:

До main() еще дойти надо. До вызова main() исполняется startup-код, который готовит переменные, настраивает стеки и кое-какую периферию, вызывает конструкторы глобальных объектов и уже после всего этого вызывает main(). А сам стартап-код вызывается из вектора исключения RESET.
У приложения точно так-же есть своя таблица векторов. В которой вектор RESET указывает на стартап-код. А стартап-код вызывает main(). Загрузчик копирует эту таблицу в начало ОЗУ и делает remap. Таблица оказывается отражена на адрес 0. По адресу 0 оказывается команда перехода на стартап-код приложения. Осталось перейти на адрес 0.
Почему? А если все программы будут с разными ключами - как вы их загрузите в одно устройство?
Нужна ли вся эта функциональность загрузчику? Может ему достаточно сильно урезанной версии? Или может у приложения есть возможность сохранить образ прошивки в какой-то внешней памяти, а загрузчик тогда будет брать шифрованную прошивку из этой памяти? А как аварийный вариант и для первоначальной загрузки предусмотреть что-нибудь типа uart?

Имелось в виду, что создавая загрузчик как отдельный проект я его буду зашивать во все свои устройства, а это могут быть совершенно разные устройства и модули


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

Так что мешает при компиляции под конкретный модуль подставлять заголовочный файл с ключами шифрования для этого конкретного устройства. Или просто держать копию исходников загрузчика в папке с проектом конкретного модуля (у меня так).