Обработка 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

[Arlleex]

Спасибо участникам обсуждения!
Примерно так я себе это и представлял, на самом-то деле. Однако предполагал, что существует некий сводный "мануал-ритуал", в котором жесткими канонами высечены такие правила

2) компиляция RELEASE: аппаратный reset устройства.
И для того и для другого случая, копирую защёлкнутую инфу в спец. область памяти, которая не будет стёрта при reset-е, снабжаю её флагом и CRC. И, если устройство имеет non-volatile память, то после штатного рестарта, после начального инита периферии, эта инфа переписывается в журнал критических сбоев в этой non-volatile памяти.

Ну то есть по сути в начале main()-а у Вас можно увидеть что-то наподобие:

Код

int main(void)
{
    if(GetCriticalErrorStatus() == ERROR_OCCURRED)
        WriteInfoAboutError();

    ...
}

где GetCriticalErrorStatus() - функция, которая читает флаг в ОЗУ, установленный trap()-ом или обработчиком HF. Верно?

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

[jcxz]

где GetCriticalErrorStatus() - функция, которая читает флаг в ОЗУ, установленный trap()-ом или обработчиком HF. Верно?

Да. Читает и очищает.

Какие изящные программные способы логгирования вы применяете?

Лучше логи писать в журналы (без ФС) - оно как бы органически под это дело и подходит. Я так и делаю. Журнал у меня - это некая FIFO-структура во FLASH/FRAM, с размером элементов обычно кратным целому числу блоков записи (хотя это не обязательно). Каждый такой элемент - одна запись журнала (на одно событие). При старте ПО выполняется монтирование каждого журнала: поиск "головы", определение числа записей, проверка их валидности и т.п.
Хотя можно сделать устойчивую к сбоям свою ФС. Но это избыточно, так как ФС нужна для возможности произвольного доступа к файлам, что налагает значительные сложности в реализации. Но произвольный доступ не нужен для журналов, а значит - избыточен.

Так может потеряться информация о файле, поэтому я делаю дублирование файлов, и это выглядит костылем.

Так даже с дублированием инфа может потеряться. Ведь обычно в файловой системе при обновлении файла происходит неатомарная модификация разных областей на носителе. Вследствие чего могут возникнуть ошибки в FAT или записи каталога, которые приведут не только к порче записываемого в данный момент файла, но и других файлов (всякие cross-links and etc.).