Обработка Faults на Cortex-Mx, Как используете? Опции

[Arlleex]

Интересует, как коллеги обрабатывают все Faults на микроконтроллерах Cortex-Mx.
Я про NMI, Hard, MemManage, Bus, Usage, SVCall, Debug Monitor, PendSV, Systick.
С SVCall, Debug Monitor, Systick все понятно, с PendSV в принципе тоже.

А что делаете с тяжелыми отказами, отказами шины и прочими? Сейчас я просто вывожу состояние нужных регистров и стек. Как правило, если где-то программа падает, я узнаю об этом на этапе отладки. Но ведь может быть такое, что устройство уже стоит у заказчика и частично подлежит отладке на объектах. И оно должно продолжить функционирование. Как обрабатывать тогда ошибки? Перезагрузка по WDT? Или все-таки грамотный обработчик исключения должен понять природу ошибки и попытаться исправить ее? Если да, то каким образом? Сейчас мне видится вариант с сохранением лога событий в памяти (допустим, SD карты) и перезагрузкой МК. Пока что больше хорошего развития событий не знаю. Отсюда и предположения для обсуждения:
1. Должны ли существовать обработчики исключения CPU, связанные с аварийным событием (промах по памяти, тяжелый отказ, например, и т.д.) только на момент разработки и отладки ПО и выявлять все проблемы именно на этапе разработки, а при этом в боевой работе устройство ни коим образом не должно ловить такие Fault-ы?
2. Пункт 1 влечет за собой следующий вопрос: если в боевом коде обработчики должны быть предусмотрены (я подразумеваю, что все-таки это именно так) - как правильно строить архитектуру обработки ошибок? Что должен делать код в обработчике, кроме как сообщать программисту (каким-то образом) о состоянии регистров?
3. Вопрос больше из разряда "как больше нравится" - код обработчика на ассемблере или на Си?
То есть, как вы поняли, вопрос в грамотном управлении ходом событий для обеспечения надежности и безотказности устройства.

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

Сообщение отредактировал Arlleex - Jul 7 2018, 15:42

[AlexandrY]

Интересует, как коллеги обрабатывают все Faults на микроконтроллерах Cortex-Mx.
Я про NMI, Hard, MemManage, Bus, Usage, SVCall, Debug Monitor, PendSV, Systick.
С SVCall, Debug Monitor, Systick все понятно, с PendSV в принципе тоже.

Ловить HardFault-ы в релизе во время эксплуатации нет особого смысла.
Слишком много информации надо зафиксировать о контексте события, слишком обременительно хранить историю версий и парсить многомегабайтные логи.
Лучше их выловить отладочным адаптером заранее.
Поскольку такие проблемы чаще всего из-за специфичной периферии SoC-а и происходят во время ее исследований.
Либо по причине некачественного интерфейса к внешней памяти.
Но тут надо не HardFault-ы ловить, а гонять разнообразные тесты.
Помню случай когда ошибка c DDR вылезала у меня только когда компилер генерил STM инструкцию с сохранением более 7 им регистров в определенной последовательности и никак иначе.
Это вызывало самые причудливые Hard Fault-ы всех сортов.
Никакие логи и дампы регистров и стека не помогали. После каждой смены опций компиляции картина ошибок менялась.

Если устройство действительно критичное для безопасности, то никто не даст вам полагаться на обработку HardFault, а потребуют полный пакет самотестирования всего и вся в чипе перед каждой ответственной операцией.
Насчет как писать надежный софт есть специальные стандарты.
Вот тут доступно написано
Что интересно, допускается восстановление после HardFault-ов, если они были ожидаемы и произошли во время штатного тестирования.
Т.е. перед тестированием переопределяем обработчик на специальный для данного теста, по завершению тестирования ставим на место стандартный обработчик RTOS.

[haker_fox]

Лучше их выловить отладочным адаптером заранее.

Но как? Вот сегодня у меня. LPC4337. FreeRTOS. 12 задач. Снаружи 4 АЦП, память SDRAM, дисплей, ethernet, rs-485, реле и прочая дребедень, свойственная промышленному контроллеру. Периодически, один раз на 10 одинаковых событий вылетает hardfault, либо портится память в произвольной задаче (структуры данных в классе). Вот как искать? MPU? Но ему же закалебёшься объяснять, какая память какой задаче принадлежит. Ловушка переполнения стека в оси не срабатывает. Call Stack ничего полезного мне не даёт, либо я не умею читать между строк. В итоге я полдня сидели и комментировал задачи, пришёл к работоспособному варианту, и методом научного тыка разобрался, что вызывало ошибку. А это было у меня под носом. Но
пока пришёл к этому, затратил немало времени.

Только хочу уточнить, что тестирование делается перед каждым включением двигателя, актуатора или еще чего.
Тестируются все критичные области RAM-а и все объекты RTOS, включая сервисы как менеджер памяти, межпроцессорный обмен и т.д.
Тестирование всего этого также повторяется с заданной периодичностью, хоть и раз в 10 мс.

Сигнатуры в ОЗУ? Тестовые блоки с CRC? Не представляю, как можно тестировать менеджер памяти, межпроцессный обмен. Вы, как я понимаю, подобным занимаетесь. Может быть напишите нам подробнее эти тонкости, если они не затронут ноу-хау. Просто иногда хочется лбом об стенку биться, ибо не знаешь, где искать)))

[AlexandrY]

Периодически, один раз на 10 одинаковых событий вылетает hardfault, либо портится память в произвольной задаче (структуры данных в классе). Вот как искать?

Как правильно ловить hardfault-ы - https://www.iar.com/support/tech-notes/debu...lt-on-cortex-m/

Сигнатуры в ОЗУ? Тестовые блоки с CRC? Не представляю, как можно тестировать менеджер памяти, межпроцессный обмен. Вы, как я понимаю, подобным занимаетесь. Может быть напишите нам подробнее эти тонкости, если они не затронут ноу-хау. Просто иногда хочется лбом об стенку биться, ибо не знаешь, где искать)))

Не, к счастью мне такого не надо пока применять.
Обходимся так называемой ABC релейной схемой. Дивайсы с ней легко проходят сертификацию и на софт даже не глядят.
Просто в MQX таких фичей по самодиагностике много, я их аккуратно обхожу и как они работают особо не разбирался.