Logging. Какие опции, Как изловить трудно повторяющийся баг Опции

[A. Fig Lee]

Народ, а че вы делаете чтобы изловить once in a while событие.
Например есть у нас ОС, и вот раз в пару дней система выпадает в осадок и не отвечает.
Что делать?
Опции:
1) иметь наружный дополнительный контроллер с питанием от батарейки, ножки которого дергать периодически из задач ОС.
Контроллер будет писать какая задача заткнулась. Сложно, муторно, надо делать плату и прикручивать к основной.
2) Использование battery backed RAM, писать инфо туда. Хорошо, когда есть еще риал тайм клок.
Чтоб время писать.
3) Использование вотчдога, только как определить что именно заткнулось?
В айдл таск проверять счетчики и смотреть, какая задача вылетела?
По вотчдогу писать в EEPROM?

Как вы вылавливаете баги?

[Jekin]

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

[A. Fig Lee]

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

Рассматриваем случай когда устройство уже в экплуатации или тестируется, без внешних соединений, в рабочей остановке

Чего именно Вы хотите? Обнаруживать повисание определённых задач (а-ля позадачный вотчдог)?

Наверное. Периодически могут сказать, что устройство перестало работать. Почему перестало, как найти проблему.
Для hard fault сделал запись в EEPROM, при тесте работало.
Hard fault-a не было, почему "перестало работать" не понятно.

[AlexandrY]

Рассматриваем случай когда устройство уже в экплуатации или тестируется, без внешних соединений, в рабочей остановке


Наверное. Периодически могут сказать, что устройство перестало работать. Почему перестало, как найти проблему.
Для hard fault сделал запись в EEPROM, при тесте работало.
Hard fault-a не было, почему "перестало работать" не понятно.

Ну очевидно у вас проблемы электромагнитной совместимости.
Здесь надо углублятся в железо. Анализировать трассировку, расположение разъемов и компонентов на плате и т.д.
Если вам конечно нужно решить проблему, а не найти причину.

На моей практике проблемы с ЭМС часто приводили к защелкиванию внутренней периферии, тогда никакие WDT и прочие ухищрения не срабатывают. Бывает происходит сброс, а узел осциллятора уже не живой, не стартует программа.
Бывает сам кристал уходит в аут и не заводится при определенных погодных условиях.
Нельзя сбрасывать со счетов радиацию. Радиация сильнее вблизи массивных металических объектов и гранитных, мраморных массивов.
Клавиатура без защитных заземленных контуров идеальный осточник статических пробоев, процессоры виснут мертво.
Специфический дребезг вызванный ЭМИ на линях I2C, SPI, UART и проч. вызывает мертвое подвисание периферийных модулей.
И проч.

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

В этом плане опасней были микроконтроллеры от NXP со всяким встроенным в ROM вспомогательным фирмваре.
Наиболее защищены от таких неприятностей чипы от Freescale, с несколькими внешними осцилляторами, несколькими внутренними и несколькими независимыми WDT.
И их операционка MQX уже сверху донизу оборудована логами, не надо перепахивать ядро RTOS чтобы еще что нибудь залогить.

[jcxz]

Нельзя сбрасывать со счетов радиацию. Радиация сильнее вблизи массивных металических объектов и гранитных, мраморных массивов.

Хм.... А если ваш девайс висит на гранитной стене, рядом с которой проехал Абрамс, то получаем тройной удар:
гранит + стальной массив + включения обеднённого урана. И тогда совсем кранты
Отседова вывод: на подступах к девайсу необходима установка противотанковых ежей.

Специфический дребезг вызванный ЭМИ на линях I2C, SPI, UART и проч. вызывает мертвое подвисание периферийных модулей.

Во-во! Как раз сейчас наш железячник борется с подобным на I2C при воздействии наносекундных помех. И пока безуспешно...

Наиболее защищены от таких неприятностей чипы от Freescale, с несколькими внешними осцилляторами, несколькими внутренними и несколькими независимыми WDT.

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

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

Тут косяк тока в том, что если к примеру какая-то задача X зациклилась в некоем цикле без вызова функций ожидания ОС (100% загрузка CPU),
а в этот момент контролировалась другая задача Y (имеющая приоритет ниже чем у X), то reset произойдёт, но как проблемная будет обозначена задача Y, а не X.

[adnega]

Во-во! Как раз сейчас наш железячник борется с подобным на I2C при воздействии наносекундных помех. И пока безуспешно...

А ведь это задача не одного только железячника. Порой и программисту нужно подергать SCL, чтоб все вернулось в исходное состояние на шине.