Есть Мега64. Использовано только 70% флэша. Как заполнить
оставшуюся неиспользованную флэш память оператором "nop"?
Используем компилятор GCC. Вопрос в том может ли GCC сгенерить
код определённого размера чтобы пространство вне основной проги
заполнялось пустым оператором.

В IAR в опциях компилятора есть возможность заполнить неиспользуемую CODE memory определенным кодом. Что-то похожее может быть в GCC

Ну в общем никто не знает....Нормальный компилятор должен как то это делать....

зачем это надо?
Хотите чтобы программа дольше шилась и флеш изнашивался быстрее?

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

Для AVR нет принципиальной разницы в поведении ядра на опкодах
0xFFFF (то чем заполнен флеш в результате команды CHIP_ERASE)
и
0x0000 (NOP)

Не это ли вас интересует?
objcopy −−gap−fill=val
Fill gaps between sections with val. This operation applies to the load address (LMA) of the
sections. It is done by increasing the size of the section with the lower address, and filling in the
extra space created with val.

Кстати заполнять надо не NOPами (или XORами, которым соответсвует код 0xff), а JMPами на ресет (или какой нибудь другой вектор ), что для старших мег будет весьма непросто.

Опять же каков в этом смысл?
После прогонки по всему массиву памяти проц выйдет на RESET сам.
Тут более уместно будет поставить команду CLI сразу по PROG_START, чтобы пере-инициализация после такого сбоя прошла без сюрпризов от включенной периферии.
Но думаю компиляторы достаточно умны чтобы позаботиться об этом самостоятельно.

Да вобщем-то особого смысла и нету, особенно когда речь идет о длинных переходах. Но когда-то такое практиковалось.



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

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



Заполнение джампами кажется более логичным, но сказано nop'ами - значит nop'ами.

Ну значит avr-objcopy --gap-fill 0x00 --pad-to 0x10000 oldfile.elf newfile.elf

Или совместить это с преобразованием в выходной файл:

avr-objcopy --gap-fill 0x00 --pad-to 0x10000 -O ihex theproject.elf theproject.hex
или
avr-objcopy --gap-fill 0x0000 --pad-to 0x10000 -O binary theproject.elf theproject.bin

Кстати - инструкции 0xffff я в списке не нашел вообще. Она неопределенная?

Относительный смысл имеет только заполнение чем-то вроде софтового прерывания/системного вызова/брейпойнта. Цель - выйти на отладочную процедуру, как минимум фиксирующую состояние регистров и кусочек стека. Дальнейшее поведение у меня зависит от наличия подключенной отладочной консоли - если есть - стоим и ждем. В консоле есть возможность покопаться по памяти, MCB, ТСВ и прочему. Для систем на x86 еще и дизассемблер встроен .
Если нет - перезапуск cо светодиодной индикацией призывающей взглянуть на 'интересное' в логе при случае. Естественно, это мееет смысл для случая когда контроллер более менее 'общительный' и/или может где-то сохранить подробности вылета.