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

[A. Fig Lee]

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

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

[Golikov A.]

если есть возможность FRAM поставить, то можно на ней сделать дата логер циклический. На EEPROM конечно ничего хорошего не сделаешь при нормальной активности смены потоков...

Единственный вариант это сделать флаги вход - выход задачи. Делается так

char FlagIn_FuncName;
char FlagOut_FuncName;
при входе в функцию увеличиваете первый, при выходе второй.
а по вочдогу все флаги от всех функций в EEPROM записывайте в ближайший не пустой сектор из выделенных для логированния. Если памяти полно то флаги можно int сделать, тогда сможете даже оценить сколько по времени проработала программа. Естественно пара не совпадающих флагов укажет функцию смерти...

[jcxz]

Единственный вариант это сделать флаги вход - выход задачи. Делается так
char FlagIn_FuncName;
char FlagOut_FuncName;
при входе в функцию увеличиваете первый, при выходе второй.
а по вочдогу все флаги от всех функций в EEPROM записывайте в ближайший не пустой сектор из выделенных для логированния. Если памяти полно то флаги можно int сделать, тогда сможете даже оценить сколько по времени проработала программа. Естественно пара не совпадающих флагов укажет функцию смерти...

Не очень понял что это даст и как оценить - работает или нет программа?
Эти счётчики в любой момент времени могут совпадать (in и out) или различаться на >=1. Что по ним можно понять?
Если вы про отслеживание их изменений, ну и что? Зависла одна задача, зато другая - нет, она продолжает вызывать эти функции и счётчики меняются.
И какой выигрыш?
А ещё иногда (хоть и редко) бывают переключения стека, когда с самой глубины вложенности управление передаётся на верх стека, минуя все выходы из функций
(типа longjmp()). Ну или try/catch на худой конец.
А накладные расходы - огромные, если на каждую функцию... Как памяти, так и быстродействия....

Я так понимаю, для window watchdog можно только одну задачу отслеживать?
Если их несколько, только по очереди?

Я делаю так:
Есть некая периодическая задача ОС (выполняется циклически раз в неск. сотен мс), она полностью управляет сторожевиком (линией WDI).
У неё есть список задач, которые нужно контролировать.
Каждая задача представляет из себя собственно цикл обработки сообщений: пока задаче нечем заняться, она ждёт на каком-то объекте синхронизации ОС.
Когда задаче откуда-то приваливает работа (из ISR или от другой задачи), то оттуда активируют её объект синхронизации.
Выполнив работу, задача опять ждёт на этом объекте. Соответственно - она периодически проходит через функцию ожидания этого объекта.
Подобным образом построена работа программ в винде (ожидание сообщения WMSG_..., обработка его и опять ожидание).

Так вот, та, периодическая контролирующая задача, перебирает по порядку контролируемые задачи, ставит флажок "а жива-ли сейчас такая-то задача?"
(ID задачи), затем активирует объект синхронизации данной задачи и перестаёт дёргать WDI пока стоит этот флажок.
Каждая контролируемая задача, выйдя из объекта синхронизации, проверяет не по ней-ли стоит флажок? Если да - сбрасывает его, говоря тем
самым: "я жива!".
Контролирующая задача, увидев это, дёргает WDI, и переходит к след. подопечной задаче.
Если возможны случаи, когда какие-то контролируемые задачи могут быть заняты длительное время обработкой каких-то данных (штатно) и
долгое время (близкое или более чем время == период_WDI - период_контролирующей_задачи) не возвращаются к функции проверки
флажка "ты жива?", то контролирующая задача, зная это, после установки флажка "ты жива?", продолжает какое-то время дёргать WDI
(это время равно разнице между максимальной длительностью занятости задачи и разностью (период_WDI - период_контролирующей_задачи)).

Так что - при такой схеме, при зависании одной из задач (не выходе её к своему основному объекту синхронизации) или зависании контролирующей задачи,
перестанет дёргаться WDI со всеми вытекающими.

Ну и конечно всегда использую механизм ловушек: все необрабатываемые fault-ы и прочие прерывания идут на ловушку, assert-ы, и везде где нужно в программе
вызываю программные ловушки по критическим ошибкам.
Обработчик ловушек пишет дамп ловушки с регистрами/дампом стека опционально во FRAM, и, в зависимости от режима компиляции (DEBUG/RELEASE),
уходит либо (для DEBUG) в trap-режим с периодическим выводом на отладочный лог дампа критической ошибки, либо (для RELEASE) - в reset.