Мне не нужен протеус, чтобы понять очевидное.
Просто надо разложить ситуацию на составляющие.
Исходные данные: программист настроил прерывание, но забыл для него сделать соответствующий обработчик. Это безусловно грубая ошибка, в результате которой программа не работает. Итак - программа не работает, как должна.
А теперь варианты развития событий.

1. Программист забил таблицу неиспользуемых векторов reti. Девайс прошивается и включается. Разработчик видит, что девайс ведет себя не так как надо: меню работает, всякие сообщения вводятся-выводятся, но какая-то часть функций не работает. Начинаются ковыряния с отладчиком - оновноной код отрабатывает отлично, имеющиеся в программе обработчики прерываний отрабатывают отлично - а программа не верно работает... Программист в панике.

2. Программист забил таблицу неиспользуемых векторов заглушками rjmp pc+0. Девайс прошивается и включается. Разработчик видит, что девайс не работает вообще. Т.е. что-то мигнуло, что-то выдалось, и после этого зависло. При помощи аппаратного отладчика, если он есть, мгновенно находит место, где программа висит, и это место - четко в таблице векторов. Всё, программист нашел свою плюху - отсутствие обработчика этого вектора. Аналогичное решение в симуляторе.

3. Программист забил таблицу неиспользуемых векторов переходами на единственную заглушку rjmp pc+0. Как и в п.2 всё висит, в отладчике видно только одно - висим в заглушке. Это не говорит ничего о том, откуда мы попали в заглушку, но все равно легко просмотреть таблицу и найти вектор без обработчика. Решение чуть-чуть сложнее, чем в п.2, но все равно элементарно.

4. Таблицу векторов заполнил компилятор avr-gcc, т.е. при необслуживаемом прерывании происходит сброс программы. В отличие от предыдущих двух вариантов программа, в зависимости от того, как часто происходят запросы необрабатываемого прерывания, либо вообще практически не стартует (визуально), либо проходит начальную инициализацию и сбрасывается. В плане диагностики этот вариант хуже, чем предыдущие два, но все равно однозначно говорит программисту о необходимости смотреть в таблицу векторов, не гадая.

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

Итак, вывод: вариант с reti в пустых ячейках таблицы векторов - наихудший при отладке и поиске проблем. Наилучший вариант - заполнение неиспользуемых ячеек заглушками rjmp pc+0. Компромиссные варианты - с единственной заглушкой или со сбросом.

Убедил?

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

При самопроизвольном изменении регистров ничего не поможет.

Добавлено after 2 minutes 6 seconds:
Но если Вам так хочется как-то защищаться от "незапланированного прерывания" только не RETI, делайте переход на обработчик прерывания по умолчанию. Но это разговор по кругу.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

сбой - это явление, аналогичное падению метеорита на голову: защититься от него невозможно никакими программными ухищрениями в принципе. единственная более-менее приличная страховка от сбоя - это WDT.
ну, вы меня знаете (или должны знать - не первый же год читаем сообщения друг друга на форуме!) - я крайне негативно отношусь к безапелляционным утверждениям!
прошу вас доказать, с какого перепугу симулятор студии лучше протеуса, если студия в принципе не симулирует аналоговую периферию, захват таймера, некоторые режимы работы таймера и вообще с отладкой "as_realtime" у студии боооольшие проблемы?

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Для начала вспомним, что мы в теме ассемблера. Reti наилучший вариант при бездействии. Nop-ы и 0xFFFF (слово) 0xFFFFFFFF - наихудший.
Теперь методы борьбы. К примеру. Асм.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

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

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

это совсем не то, о чем шла речь ранее!

Добавлено after 1 minute 53 seconds:
да, вот еще что: у вас в Proc_Errors не нужно cli

Только не говорите мне, что я не умею готовить. Сколько раз я пробовал работать в протеусе. И все разы я проклинал все попытки. На простых проектах ногодрыгах еще что-то можно делать. На более сложных, как минимум жуткая тормозня.
Поэтому, модульная отладка программ. Принимаем как факт, что модуль работает, при симуляции, отладке программ выставляем режимы периферии, биты в регистрах. Если периферию невозможно симулировать, выставляем нужные переменные.
К примеру, проект. Ампер-вольметр переменного тока. Клавиатура, дисплей. Весь проект я отлаживал в студии и на железе. Именно так как я описал. Проект на си. На асме ничем бы не отличалось. Но я уже несколько лет не пишу проекты на асме.

То что Вы где-то что-то успешно отладили и где-то что-то в другом месте не получилось - это не аргумент.

Я не оспариваю вашу квалификацию. Вы не ассемблерщик. Это всего лишь означает тип мышления.
Proc_Errors общая подпрограмма для обработки ошибок.

Каким компилятором пользуетесь?

IAR. Иногда студию и тулчейн. Отладка всегда в студии. IAR создает файл в формате студии. Прошивка МК только через студию. STK-500 либо AVRISP MKII.

Просто Вы говорили что GCC давно не пользовались или что -то в этом роде. К студии другой подключен чтоли?

Добавлено after 35 seconds:
Ладно. Не важно. А то в оффтоп разговор пойдет.

Именно, что давно не делал проекты в Toolchain. Иногда делаю мелкие проверки. Либо, как в нашем случае, открыл старый проект, чтобы посмотреть на выхлоп компилятора.


О панике. Когда у тебя непонятки, ты несколько дней не можешь понять, в чем дело. И горят сроки. Нужно успокоиться. Критически взглянуть на свою работу. Составить план действий. Методику проверки.

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

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

Иногда стоит внимательно прочитать инструкцию, то бишь даташит...

Может быть я написал банальщину. Но это вы написали о панике.

студия может подхватывать для отладки готовый elf или hex
я им был, не обольщайтесь
что можно говорить в этом случае? если вы делитесь собственным впечатлением, то предваряйте свои высказывания "по моему личному опыту" или "мне кажется" или "я думаю", чтобы выши высказывания нельзя было принять за окончательную истину.

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

Добавлено after 4 minutes 35 seconds:
О панике я-то не буду.
во-первых, я знаю, как надо сразу делать правильно, и таблица векторов у меня будет на самом последнем месте поиска проблем.
во-вторых, про панику я говорил в контектсе поведения программы: когда что-то должно делаться, но при этом не делается, и в отладчике не видно явных странностей - это очень загадочно! и как раз такая загадочность возникает, если вместо остановки на "незапланированном" прерывании делается его незаметная обработка через reti - что вы предлагали. и это вполне может вызвать панику! очень много раз ко мне обращались за помощью "ничего не работает, но ошибок нет" именно по этой причине.
сейчас - да. раньше было лучше

Ладно поболтали, побежал я. Дела, заботы...

ГЫММ...
Как это (с точки зрения ассемблера) при корректно продуманной инициализации устройства да незадействованные в программе прерывания "сами - по себе" активируются???

Никогда с таким "казусом" не встречался...

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

Я тоже выше писал, что от самопроизвольного изменения состояния регистров не поможет ничего. Есть не 100% шанс что спасет собака.

Добавлено after 1 minute 11 seconds:
Что за срыв стека может быть в рабочей программе?

У AVR архитектура такая.
Давайте разберем случаи сбоя и переход программы. Пусть на вектор прерывания. Если неиспользуемый, reti и ничего не произошло. Либо с обработкой ошибки. Если используемый, то здесь можно применить флаг разрешения обработки прерывания.
В любое место программы. Тут сложнее. Ничто не спасает в таком случае. Если на пустое место, то будет перебор всех ячеек 0xFF, в конце мк сбросится на начало программы.
Так что, и ватчдог не особо спасает в случае сбоя.

Я не видел людей утверждающих, что ватчдог это спасение (хотя наверное есть такие). Устройство должно полностью работать без него и в тех условиях, для которых он предназначен.