[ViKo 1]

Значит его нужно перзапускать, что и делает собака.

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

[Arlleex 131]

А если на объекте появится, то... ну что поделать) Попробовать воспроизвести у себя.

Я еще понимаю, если устройство является технологическим (вспомогательным) и его отказ не оказывает влияния на всю систему.

А если этот ваш МК стоит на приводе управления тормозами поезда? А если в самолете? А если в дозаторе рентген-излучателя в медицине? Вам же хотелось бы быть уверенным, что не получите 100-кратную дозу при снятии рентгена грудной клетки? Вот и мне хотелось бы. Да куча примеров, в общем-то - думаю понимаете, к чему я веду. И даже из каждого недопустимого поведения устройства нужно делать выводы. И чем больше исходных данных - тем вкуснее пища для размышлений.

Насчет сторожевой собаки в данном конкретном случае - мне кажется это лишнее. Хотя кому как. Мне проще NVIC попросить сбросить МК сразу :laughing:

Изменено 11 июля, 2018 пользователем Arlleex

[haker_fox 60]

А если в самолете?

Не переживайте так, я тоже озаботился этим вопросом :rolleyes: Именно поэтому я развил тему авионики начиная отсюда, и тут.

[AlexandrY 3]

Интересует, как коллеги обрабатывают все 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 60]

Я еще понимаю, если устройство является технологическим (вспомогательным) и его отказ не оказывает влияния на всю систему.

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

 

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

[AlexandrY 3]

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

Только хочу уточнить, что тестирование делается перед каждым включением двигателя, актуатора или еще чего.

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

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

[haker_fox 60]

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

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

пока пришёл к этому, затратил немало времени.

 

 

Только хочу уточнить, что тестирование делается перед каждым включением двигателя, актуатора или еще чего.

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

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

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

[AlexandrY 3]

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

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

 

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

Не, к счастью мне такого не надо пока применять.

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

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

 

[Pavia 0]

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

Всё просто, но закалебёшься. Берём и пишем Unit-тесты на все случае жизни. Должны быть данные и проверочный-код который зайдёт во все ветки кода. Ошероув Рой.-Искусство автономного тестирования.

А по мимо автономной проверок ещё и внутренние делаются.

Проверка данных по входу обязательна для всех внешних систем.

 

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

 

и методом научного тыка разобрался, что вызывало ошибку.

Последний раз мне здорово помогло логирование. В лог для каждой функции пишем время имя функции/класса и параметры полученные по входу.

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

 

Я вот что думаю можно сделать так. Один раз пишется небольшая утилита которая внутрь каждой функции добавляет вывод в лог. И так же убирает.

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

[Kabdim 0]

Всё просто, но закалебёшься.

И всё сломается на первом же забежавшем быстрым нейтроном. :biggrin:

[AlexandrY 3]

Ошероув Рой.-Искусство автономного тестирования.

Хорошая книга, чтобы понять терминологию и больше не напрягаться вопросом почему я не пишу автономные тесты.

В малых встраиваемых системах автономное тестирование эт как футболистов на поле заставить пользоваться смартфонами с навигаторами.

Хуже способа замедлить разработку просто нет.

 

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

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

[jcxz 185]

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

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

 

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

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

 

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

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

 

Ловить HardFault-ы в релизе во время эксплуатации нет особого смысла.

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

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

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

 

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

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

 

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

Вообще - это возможно. Если каждая задача работает только со своими переменными.

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

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

А изначально Вам следовало определить причину HF. И от неё уже танцевать.

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

 

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

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

 

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

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

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

[Arlleex 131]

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

А вот тут, пожалуйста, поподробнее. Интересно как ловятся такие эскалационные баги :smile3046: В терминологии ARM, нсколько я помню, это называется "не точный отказ" (not exact fault).

[haker_fox 60]

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

Не работал с их МК старше Cortex-M0. А STM32F051 и подобные мне очень нравятся из-за богатых аппаратных возможнстей (система триггеров и передачи сигналов на запуск периферии). На "ура" на них делал источники тока с обратными связями, с многофазной системой синхронизации и т.п. Один из источников полностью программный. Т.е. связка таймер-ПДП-АЦП рулит ШИМ и обеспечивает цифровой ПИД-регулятор.

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

Угу. Смотрим на схемы Aribus A320, Boeing 7x7 как самые доступные в инете. Впечатляемся, и идём читать настоящие книжки)

 

 

А вот тут, пожалуйста, поподробнее. Интересно как ловятся такие эскалационные баги :smile3046: В терминологии ARM, нсколько я помню, это называется "не точный отказ" (not exact fault).

+1, тоже интересно. А ведь может быть и три таких ступени)

[jcxz 185]

А вот тут, пожалуйста, поподробнее. Интересно как ловятся такие эскалационные баги :smile3046: В терминологии ARM, нсколько я помню, это называется "не точный отказ" (not exact fault).

Вы не поняли. Я тут вовсе не говорил про эскалацию fault-ов. Баг не обязательно приводит к fault-у. Ну затёрла одна функция данные другой - с чего это может вызвать fault? А вот когда уже вторая функция начнёт пользоваться этими разрушенными данными, то может получиться fault. А может и не получиться, а порушатся данные третьей функции. И так далее. И когда это может привести к fault-у (а может и нет).

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

 

А эскалация - это когда к примеру у Вас запрещён BusFault, но происходит причина его вызывающая и, так как он запрещён, то происходит эскалация до HF. У меня обработка всех fault-ов построена на эскалации до HF - так проще, чем писать кучу обработчиков с одинаковыми действиями. В ISR HF по регистрам всегда можно определить первоначальный источник, до эскалации.

 

И "неточный отказ" не имеет никакого отношения к эскалации. Это просто один из видов отказов по вектору BusFault. Неточный - это значит, что регистр адреса отказа не содержит точного адреса отказа. Например - из-за кеширования. Выполнили Вы запись в память, но из-за наличия буфера записи, данные не сразу физически запишутся в ОЗУ, а через некоторое время. И если эта запись вызовет fault, то PC к этому времени уже убежит на несколько инструкций. Вот тут и получите "неточный отказ".