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

То честно говоря не вижу в этом особого смысла, да и возможности. При включении можно проверить всё, что угодно. А как во время работы проверить ОЗУ? Остановить устройство, и записывать-считывать память, регистры и т.п.?

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

Мне, вот, просто интересно стало. А что же делать если микроконтроллер расположен внутри ПЛИС, ведь это почти тоже самое что и взять стандартный чип? И как такие устройства работают?

Как как.. Да как два пальца абосфальт.. Записал чё-нить в ОЗУ и тут же прочитал (проверил тем самым записалось ли). Не знал про такой способ?

А тут же, это когда, через такт, секунду, месяц?
А ещё бывают volatile переменные, что, запрещать к ним доступ, что бы прочитать что записалось?

Можно выделить сразу буфер, для проверуи памяти. Сначала проверяете его, а потом блоками перетаскиваете в него содержимое из ОЗУ, проверив определённый участок памяти, возвращаете туда то что перекидывали. Естенственно на время теста нужно вырубать прерывания. А период тестирования определяется параметрами надёжности и безопасности вашего устройства.

Известно из работ 80-х годов по тестированию ОЗУ (конкретнее - если найду книжку - скажу) о том, что такой способ является самым грубым и не обеспечивает выявление даже половины возможных неисправностей.

Единственный способ проверок такого рода, резервирование двойное, а то и тройное.

Тестирование памяти вообще достаточно серьёзная задача. Ну а какие ещё способы тестирования ОЗУ в фоновом режиме Вы можете предложить).

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

Интересно...., а контроль переполнения стека тоже относится к одному из видов фобий или есть какая нибудь целесеобразность?

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

А потом - суп с котом одна из массовых ошибок памяти это ошибки/сбои адресации а не данных - подзаписали не туда и все...

Можно контроллировать и без MMU. Во всяком случае детектить выход за границу можно. В ручную напр так:
Зарезервировать участок памяти перед стеком, заполнить каким-нить патерном, нагрузить программу работой "по самые нехочу", снять слепок памяти и посмотреть как глубоко залезли в резервную память.

Автоматически можно также, во многих случаях отдетектится переполнение до того как система зайдет в тупик.

Предложите свой способ...

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