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

[haker_fox]

Мой обработчик HardFault состоит из диагностического вывода в консоль содержимого регистров. Взят на просторах инета. Плюс к этому блокируются все прерывания, и через некоторое время прибор перезагружается по собаке. Событие пишется в журнал, но лишь как HARDFAULT_EVENT". В журнал уже не кладу никакой другой полезной информации. Полагаю, что на этапе отладки нужно минимизировать вероятность этого события. А если на объекте появится, то... ну что поделать) Попробовать воспроизвести у себя. Поэтому расчёт на пса, и собственные силы в отладке.

Продолжать работу после hard faulta не считаю разумным, т.к. причин этого явления может быть несколько разных. Например, невыровнный доступ к памяти. И что с этим делать? Если это правится в исходниках, там и нужно поправить. Если это "случайная" ситуация, зависиящая от внешней среды... то тоже исходники править, только больше алгоритмически. Или улетели с нулевого указателя? И вот что с этим делать? Прибор не может работать, не обратившись к нужной функции. Значит его нужно перзапускать, что и делает собака.

Как правило, приборы, особенно построенные на МК без MMU - не компы. Операционных систем, которые берут на себя весь процесс восстановления и защиты экосистемы, там нет. Писать это и тестировать самому - не одного ежа можно родить) А если только MPU? Или у нас Cortex-M0 без оного? Считаю, что лог + перезапуск самое то)

[jcxz]

А если только MPU? Или у нас Cortex-M0 без оного?

Расчудесная и многими любимая фирма STMicroelectronics даже некоторые МК на Cortex-M3 умудряется делать без MPU. Видимо заботится о юзерах - чтоб мозги не перенапрягли, разбираясь в нём.

Есть не один способ сбросить МК без собаки. Зачем ждать, пока собака проснется?

Да знаем мы уже Ваш способ! этот способ - юзер с большим рубильником

А если этот ваш МК стоит на приводе управления тормозами поезда? А если в самолете?

...то их (девайсов) должно быть как минимум 4-ро. Если один вздумал вольнодумничать - 3 других дадут ему по шее, так чтоб перезагрузился. А если пойдут 2 на 2, то попросят помощи у машиниста/пилота.

Ловить HardFault-ы в релизе во время эксплуатации нет особого смысла.
Слишком много информации надо зафиксировать о контексте события, слишком обременительно хранить историю версий и парсить многомегабайтные логи.
Лучше их выловить отладочным адаптером заранее.

Ну никто-ж не спорит, что лучше быть богатым и здоровым чем бедным и больным писать код сразу и без багов. Но что-то ни у кого это не получается. И при компиляции в RELEASE ненайденные баги не исчезают волшебным образом.

Тестирование всего этого также повторяется с заданной периодичностью, хоть и раз в 10 мс.

Сдаётся мне, что попытка вытворить такое не уменьшит, а наоборот - увеличит вероятность наличия багов.

MPU? Но ему же закалебёшься объяснять, какая память какой задаче принадлежит.

Вообще - это возможно. Если каждая задача работает только со своими переменными.
Собираем эти переменные в свои регионы памяти: для каждой задачи - отдельный регион, куда линкуются только её переменные; в хуке переключателя контекста (в uCOS такой уже есть, но если и нет - можно просто вставить в имеющийся переключатель) при переключении на какую-то задачу закрываем всю память от записи (или вообще любого доступа) кроме региона этой задачи.
Но так редко бывает, чтобы задача работала только со своими переменными без взаимодействия с другими задачами. Хотя тут тоже есть варианты.
А изначально Вам следовало определить причину HF. И от неё уже танцевать.
Конечно бывает, что HF вызывает вторичная причина (первичная просто разрушила чью-то память не вызвав HF, а когда пользователь этих данных полез к ним, то у него и случился HF). Тут уже сложнее. Но тоже есть варианты решений.

Место вставки элементарно подсчетом скобок определяется. Только для каждого класса надо будет добавить GetDebugString

Набежали, блин, PC-теоретики....

Замедление разработки в ответственных системах скорее всего даже полезно.

Да я тоже считаю что лучше 5 раз сходить на кофе-паузу чем 2!!! Ведь чем меньше времени программист проводит за клавиатурой, тем меньше у него времени плодить баги!
На прошлой работе у меня был коллега, так он так начальству и говорил: "Вот я сейчас лишние полчаса просидел в кафе, так я же это с целью ускорить разработку - иначе бы за это время успел написать баг, но поиски которого пришлось бы потратить несколько дней. А так - выпил лишнюю чашку кофе - и ускорил проект на несколько дней!"

[AlexandrY]

Ну никто-ж не спорит, что лучше быть богатым и здоровым чем бедным и больным писать код сразу и без багов. Но что-то ни у кого это не получается. И при компиляции в RELEASE ненайденные баги не исчезают волшебным образом.

Сдаётся мне, что попытка вытворить такое не уменьшит, а наоборот - увеличит вероятность наличия багов.

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

Второе, искать надо там где бОльшая вероятность. И я согласен с ST, что самый чувствительный участок - это RAM. RAM занимает самую большую площадь на чипе.
А сбои в RAM-е имеют свойство накапливаться. Поэтому чем чаще тестируете RAM тем меньше накопленных ошибок будет.

Ну и последняя модная фишка от IAR 8.20 - стековые канарейки (stack canaries)
Такая фича компилера, когда он автоматом вставляет некую проверку стека на целостность в каждую подозрительную функцию.

Кста, если кто забыл. Есть еще такая фича у IAR как С-RUN Runtime Checking, тож проверяет кучу косяков в риалтайме как и Ubsan

[haker_fox]

Ну и последняя модная фишка от IAR 8.20 - стековые канарейки (stack canaries)
Такая фича компилера, когда он автоматом вставляет некую проверку стека на целостность в каждую подозрительную функцию.

Прямо сейчас внедрил в проект этот инструмент. Пусть будет. Вдруг поймает что-то.
AlexandrY, я, как понял, вы IAR только используете?

[AlexandrY]

Прямо сейчас внедрил в проект этот инструмент. Пусть будет. Вдруг поймает что-то.
AlexandrY, я, как понял, вы IAR только используете?

Нет не только. Сейчас в активной поддержке у меня проекты в Keil 4, Keil 5, IAR 7 , MPLAB
А вот как раз на 8-й IAR я еще не перешел. Жду плагина под MQX.