И причём здесь ссылки на вполне приличные статьи?
Почти со всем по второй ссылке согласен, особенно с "В любом случае надёжная работа МК первична, на неработающем "железе" никакая программа не может быть выполнена надёжно"
Несогласен частично с "некоторые другие простые приемы повышения надежности систем" по причине РАНОВЕРОЯТНОГО (почитай уж что-нить, если действительно не знаешь что это) возникновения сбоев в разных областях памяти/разных регистрах в случае некоего стороннего воздействия на аппаратуру.
А по первой ссылке - тоже правильно - там для кое-кого написано: "В нормально работающей системе не должно возникать неиспользуемых прерываний, поскольку они просто не разрешаются".

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

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

Последнее, ышо раз, помехи не воздействуют на программу. Да, работа программы может быть неадекватна при аппаратном сбое (плевать, помеха ли или другие причины). Да, есть способы как принять решение (алгоритмы) в случае возникновения ошибок в данных. Но сколько ни пиши программ, аппаратные ошибки они не смогут исправить.
Если допускается работа программы в условиях аппаратных сбоев, то чего? Если процессор отдельно, например старый добрый Z80, а скажем, контроллер прерываний 82C59 отдельно, то решение о его исправности или неисправности можно принимать не один раз, но ИСПРАВНЫМ ПРОЦЕССОРОМ. Если же они на одном кристалле, то неисправность контроллера прерываний РАВНОВЕРОЯТНА с неисправностью (равно с повреждением данных) ЛЮБОГО регистра на кристалле. А при этом, нарпимер в AVR контроллер прерываний вырожден (не виден) до механизма непосредственного вызова обработчиков прерывания, так что проверить нечем, кроме как указать точку слива ошибочных вызовов. Но вызовы-то либо разрешены, либо нет. Т.е. либо неисправно и вызвалось, либо исправно и не вызвалось, или вызвалось, потому как кто-то случайно разрешил обработку прерывания в теле программы (баг программера, а не железа). Да, можно написать супер-обработчик для всех неиспользуемых прерываний, но если программер багу не допустил, то вызова левого обработчика при исправности аппаратной части быть не должно!!! Иначе такое железо нах в утиль