Средства и методы разработки

Интересно, почему такой упор на (не)исправность процессорного ядра, памяти... Да неисправно что угодно может быть. Тактовый генератор. Выдавать короткие импульсы вызывающие сбои везде. Или ошибка типа "memory corruption", испортившая "ранмтайм" и как следствие вызывающая постоянные сбои при выполнении отдельных функций. А так-то мысль трезвая. Не обязательно проверять исправность именно регистров процессора, достаточно в цикл работы включить некую проверочную процедуру (проверочное событие в систему обработки событий, проверочное сообщение в канал связи и т.п.), которая выполняет некоторые расчёты похожие на рабочие (событие обрабатывается, сообщение передаётся), и проверяет результат на правильность. Про то, что кварц в системе на МК может завестись на не той частоте или не завестись -- очевидный факт, я всегда проверял частоту по встроенному генератору и ожидание готовности кварца/PLL делал с таймаутом. Лучше 5 раз проморгать диодом потом, индицируя конкретную ошибку (её же даже в компорт не запишешь), чем пол дня искать проблему с осциллографом в руках. Такого рода ошибки (не совпала контрольная сумма ПЗУ и сбой тактового генератора) индицируются только светодиодом или звуковым сигналом. Расстановка по памяти проверочных слов вокруг важных данных (https://en.wikiped …er_overflow_protection) достаточно распространённая практика даже при программировании на ПК. Лучше сразу соломку подложить, чтоб потом не так больно падать. Как вариант, структуры хранящие важные данные могут быть защищены простенькой контрольной суммой (кодом Адлера) или хешем (FNV1a), который проверяется перед обращением и пересчитывается после каждой модификации. Чтоб в случае ненамеренной модификации получить не трудно понимаемые глюки, а чёткую диагностику ошибки. CRC в протоколах связи и какой-либо контрольный код при записи во flash -- наверное у всех есть. Опять же последнее может быть нужно не из-за неисправности аппаратуры, а для обнаружения прерванной (в т.ч. по вине программистов) записи. В худшем случае могут получиться "плавающие биты", когда сегодня читается верно, а завтра уже не очень. Контрольный код (типично CRC, т.к. обнаруживается большую вероятность обнаружения ошибок) для канала связи или при записи во flash нужно выбирать тщательно. Например, передаваемые пакеты, или недозаписанная flash-память, может давать ошибку массового обнуления или "объединичивания" второй половины пакета (в I2C, например). И у таких пакетов CRC очень вероятно может совпадать (a обычная сумма справится лучше, но сумма имеет намного худшую вероятность обнаружения ошибок в других случаях, кроме того, сумма не обнаруживает перестановку местами сегментов данных). И добавка в конец пакета просто проверочного байта, например 0x55, запросто обнаруживает такие ситуации, а CRC -- массово пропускает. То, что микроконтроллер при управлении чем-либо должен иметь свою предельно простенькую модельку объекта управления и проверять соответствие её состояния сигналам считываемым через входы (концевики, датчики углов), а не работать ориентируясь только на входные сигналы -- по-моему очевидность. Это позволит обнаружить и неисправности, и ошибки в алгоритмах управления. Опять же пример с лифтом: в момент открывания дверей датчик должен переключиться за некоторое время или число обооротов. И не нужно крутить двигатель до появления дыма, если не переключается. Или, например, даже простая задача сканирования клавиатуры. Залипание клавиши на длительное время -- это именно залипание, и не нужно делать автоповтор, не нужно считать её нажатой. Нужно залоггировать ошибку и считать клавижу не нажатой до отпускания. По крайней мере часть других клавиш можно нажать: если нажимаются по одной, без шифтов, то вообще все (при использовании матрицы), если нажимаются с шифтами то образуется фантомная нажатая клавиша (почему матрица с диодами лучше).