Требуется объединить в одном проекте прикладной код и bootloader, котороый этот код собственно и апдейтит.
Т.е. основной рабочий код размещает линкер, как обычно, а лоадер нужно разместить в BOOTSECTION.
Хочется сделать все это одним проектом, а не грузить в контроллер 2 разных куска кода по разным адресам.
Как в проекте ИАР 5.10 можно разместить код с указанного абсолютного адреса?
Вариант с
#define MYSEG 0x3700
#pragma segment="MYSEG"
годится только для переменных, для кода - нет. Какие еще могут быть варианты?
Заранее спасибо за помощь.

Глупо вылить в кучу разные вещи.

А это не проблема комполятора-линкера - склейте HEX файлы Ваших проектов и грузите "одним куском".

Вы видимо не внимательно читали вопрос, я просил не оценку своих умственных способностей, а помощь в решении конкретного вопроса.. Склеивать 2 НЕХ файла мне, как раз и не нужно. Мне не грузить одним куском нужно, а компилировать одним проектом.
Хоть Вы и считаете глупым валить разные вещи в одну кучу, но на самом деле это не разные вещи и одна куча...
Лоадер берет код из внешнего источника, сравнивает № версии этого кода с № версии кода, размещенного в контроллере и принимает решение грузить или нет. Это в примитиве. На самом деле, у этих 2 проектов есть общая область данных, которая должна быть доступна обоим проектам.

"Не читал, но осуждаю" ИМХО бутлодер не должен быть настолько интеллектуальным, чтобы проверять версию! Его задача сообщить наружу загруженную версию, принять данные, записать куда ему укажут или куда "положено" и проверить при старте корректность/валидность кода прикладной задачи. Не его собачье дело какую версию в него будут грузить. А вдруг последняя версия с глюком и нужно откатиться к предыдущей? Как быть?
По поводу размещения кода читайте раздел Controlling data and function placement in memory в User's Guide. В IAR EW430 и EWARM для этих целей pragma location и pragma section используются.

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

и видимо по этой причине Вы написали следующее

Ну что сказать... внимательно читайте, что пишите .
Рекомендацию подтверждаю.

Даже лучше 'известному адресу' находится только указатель на эту область данных.

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

В моем случае бутлоадер именно ДОЛЖЕН быть интеллектуальным. Ему некому сообщать наружу номер версии. Там - снаружи простая флэшка, на которой может быть записана, как новая, так и старая версии программы. И задача лоадера понять, нужно ли делать обновление или нет. Но это тоже в примитиве. Все несколько сложнее. Так стоит задача.
И если не "утаптывать" 2 проекта в один (а они в моем случае не такие уж и разные вещи), то решение получается совсем кривое.
За наводку спасибо. Правда, pragma location я пробовал, компилер ругается, что эту директиву нельзя использовать для кода, только для переменных. Может что не дочитал... Посмтрю еще раз...

... сравнив пару байт в прошивках с текушей. Убойный интеллект.

Мне не понятен смысл Ваших реплик. Вы отправляете уже 3 сообщение и ни слова по существу вопроса... Все больше эмоции, хотя причина их мне не ясна...

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

А потом ракеты летят не туда или вообще не взлетают Не может программа быть умнее программиста, написавшего ее. Решение в конечном итоге должен принимать ЧЕЛОВЕК, а не какой-то там бутлоадер! Есть у вашего бутлоадера хоть какой-то HUI для этого?

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

Съем журнала никак не связан с обновлением ПО. То, что вы объединяете эти два процесса, таит в себе много разных неприятностей. Но вы видимо везунчик, раз до сих пор ни с одной из этих неприятностей не столкнулись.

Я просто описал, насколько можно подробно, что и как происходит.
Что касается неприятностей, то я знаю, о чем Вы пишете. Для их избежания важно, чтобы данные в ОЗУ не меняли свои адреса от версии к версии.
Это условие соблюдено, потому мне и "везет". Кроме тогог, после перезагрузки стартовать нужно не с 0-го адреса, а, минуя преамбулу, сразу с рабочего кода. Чтобы избежать инициализации всех переменных и стека.
Вот собственно и все. Кажется...
И все работает...

До поры до времени.

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

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

Посмотри мой прикреплённый пример в этой теме
http://electronix.ru/forum/index.php?showtopic=69248

Спасибо!
Проблему решил.
РАзобрался с размещением функций по абсолютным адресам.
Так же, как и Вам ОЧЧЕНЬ помогли поучения zltigo.