Ситуация такова - создал проект, начал отрабатывать модули. В установках для Release на выходе установил для основного файла - "intel-standard". Кроме того указал создавать еще и дополнительный - "row-binary". Все вроде бы работало нормально, создавало HEX-файл с расширением a90 и двоичный файл с расширением bin. Так все было нормально до того момента, когда стало нужным задействовать в программе обращения к EEPROM и выводить файл его содержимого.

Короче, согласно мануалу для линкера создал xcl-файл. В хвосте дописал:
-y(CODE)
-Ointel-standard,(XDATA)=Test.eep

Запустил компиляцию, жду. После полуминуты ожидания принудительно обрубаю компиляцию и смотрю на результат: Test.a90 - как ему и положено, Test.eep - тоже нормальный создало, а вот Test.bin - родился размером за 3 Гб и намеревался расти дальше. В начале его - действительный бинарный код, а далее - толпа нулей, стремящаяся до бесконечности.

Хорошо, в меню для линкера выключаю создание дополнительного файла. Все идет как по маслу, создаются два правильных Test.a90 иTest.eep.

Ладно, экспериментирую дальше, снова включаю создание дополнительного bin-файла, но в программе "глушу" все обращения к EEPROM. После компиляции получаются 3 правильных файла - a90, bin и eep. Естественно в EEPROM - 0 байт.

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

Кто может что-либо подсказать на сей счет?

IAR AVR 4.12A

Дальнейшие разборки поведения линкера привели к следующему:
Предположим, выставляю в General options на закладке Target в пункте System configuration птицу на Configure system using dialogs (not in XCL file).
Для линкера в Output выставляю intel-standard.
Убираю в программе обращения к EEPROM.
Генерирует нормальный HEX-файл.
Меняю intel-standard на raw-binary.
Генерирует нормальный BIN-файл.
Возвращаюсь назад к intel-standard и в программе разремливаю обращения к EEPROM.
Запускаю компиляцию и получаю: Error[e133]: The output format intel-standard cannot handle multiple address spaces. Use format variants (-y -O) to specify which address space is wanted - что вполне естественно.
Далее снова меняю intel-standard на raw-binary.
Снова запускаю компиляцию и получаю "задумчивость" на длительное время - выходной файл растет до 4Гб (у меня на этом диске FAT32), после чего получаю радостное сообщение о невозможности создать выходной файл. Естественно, этот файл нахожу на своем законном месте, размером он 4Гб, в самом начале его - бинарный код, а дальше - нули до самого конца.
Конечно, ругнуться ошибкой e133 у него так и не получается, поскольку до этого дело не доходит.
Короче говоря, при попытке сгенерить BIN-файл, при условии, работы с EEPROM, хоть с XLC, хоть без, у линкера срывает крышечку.
По крайней мере у меня создалось впечатление, что это именно то.

Может кто-то с таким тоже сталкивался?

Не заставляйте линкер делать то, что он не должен делать если у Вас используется не одно пространство (The output format ... cannot handle multiple address spaces.).
В .xcl файле сделайте следующее:
-Ointel-extended,(CODE)=.hex
-Ointel-extended,(XDATA)=.eep
-Oraw-binary,(CODE)=.bin
а в настройках оставьте генерацию, ну скажем, файла с отладочной информацией .dbg .

Что за фокусы с (CODE)/(XDADA)? У линкера там просто вариант формата, эквивалент опции
-Y документирован.

Читаем главу Restricting the output to a single address space в файле xlink.pdf

Спасибо! Минус документописателям :-( - в описании ключа ни сном ни духом ни отсылки.

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

Взять любой проект, где в программе есть обращения к EEPROM, указать линкеру, что ему нужно работать с конфигурационным файлом, в Output указать хотя бы ubrof, а в конфигурационный файл вставить следующие строки:

-Ointel-standard,(CODE)=$PROJ_DIR$\Release\Exe\Test.a90
-Ointel-standard,(XDATA)=$PROJ_DIR$\Release\Exe\Test.eep

Все пройдет нормально и сгенерируются 3 файла - .dbg, .a90 и .eep.

Потом добавить строку:

-Oraw-binary,(CODE)=$PROJ_DIR$\Release\Exe\Test.bin

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

Аналогичное произойдет, если указать в Output intel-standard а в конфигурационный файл сначала вставить строки:

-y(CODE)
-Ointel-standard,(XDATA)=$PROJ_DIR$\Release\Exe\Test.eep

Cгенерируются 2 файла - .a90 и .eep.

Добавить строку:

-Oraw-binary,(CODE)=$PROJ_DIR$\Release\Exe\Test.bin

и снова убедиться в вышеописанном.

Мало того, даже если не пользоваться дополнительным конфигурационным файлом, а использовать дефолтный, а в окне Linker/Extra Options поставит птицу на Use command line options и вставит в окно вышеуказанные строки, то произойдет все то же.

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

Советую все же самим убедиться в таком поведении линкера. IMHO, это есть глюк линкера.
IAR AVR v.4.12A.

Действительно глюк.
Тогда воспользуйтесь обходным манёвром, вместо строки
-Oraw-binary,(CODE)=.bin
вставьте строку
-Ompds-code,(CODE)=.bin
Это тот же бинарный формат, только называется иначе

Ну, вот, это как раз то, на что я хотел обратить внимание.

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

А так хотелось красивого...

Не понятно, с mpds-code тоже "досыпаются"?
У меня вроде всё нормально.

Бинарник, размер которого меньше килобайта, досыпает нулями до килобайта. Такие пироги...

Это я о тестовой программке.

Что-то не получилось задать относительные пути (через $EXE_DIR$ и т.п.) - пишет "не могу открыть файл" с именем непоср. $EXE_DIR$, т.е. не выполняет подстановку. Это линекер так интерпретирует?.
Реагирует только на абсолютный путь в xcl, что не удобно.

А Вы вообще никаких констант не пишите. Линкер по умолчанию кладёт выходные файлы в папку exe и даёт им имя проекта. Можно указать только расширения.
Я делаю так:

Понятно.
Просто в одном из предыдущих постов увидел относительные пути (вернее оттуда скопировал), а оно не пошло.

Возвращаясь к теме формирования выходного файла в формате raw-binary.
IAR выпустил новый линкер, в котором, как утверждается, этот (описанный здесь) и некоторые другие баги исправлены.