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

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

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

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

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


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

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

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

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

На обработку заходят все траблы (hard fault, mem manage, bus fault, обработчик с прерывания от оконной собаки, прерывания от ассерта и т.п.),
в данной обработке есть стэк в нём адресс возврата, дата-время, состояние глобальных данных (флагов состояния, стэков динамических ошибок и т.д.)
вся информация до которой можно дотянуться.
по адресу возврата вычисляется модуль (модульная архитектура). прерывания полностью
блокируются, происходит запись во флэш(скользящая адресация, по трём банкам) и уход на рестарт.

При подъёме логики производится чтение из флэша. Если были траблы - производится расшифровка и запись в лог файл в MicroSD карточку
(если стоит), в лог файл.

где то так.

O! Какая хорошая идея со счетчиками входа/выхода в функцию.
Да, можно сделать ячейки RAM __no_init,
если вотчдог ресета не было, мы их обнуляем, если был, значит там данные, пишем их в ЕЕПРОМ при рестарте вотчдога.
В данном случае EEPROM маленький, 128 байт, FRAM нет, правда есть место во флаше СТМки.

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

Погуглю, может 24LCXX можно безболезненно на FRAM поменять..



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

Как-то пока отлавливается всё логами и натурными экспериментами. Но в идеале:

1. Глобальный и многозадачный вотчодги. Многозадачный вотчодог делается так: задача с минимальным приоритетом должна выполниться хотя бы раз в минуту, для примера. Глобальный вотчдог срабатывает при сбое ОС, например в Hard Fault.
2. Пишем логи просто в порт для проведения натурных экспериментов. Можно отключать/включать перемычкой, чтобы производительность не страдала.
3. При появлении Fault выдавать стэк трейс или хотя бы SP, PC. Это правда не поможет при таинственных зависаниях.

было такое. поставил оконную собаку. с прерыванием. в прерывании отключаем и на стандартный обработчик hard fault.
сам обработчик прямой как лом. при записи флэш все лупы со счётчиком. т.е. на ресет всё равно выйдет рано или поздно.

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

Блин нафига память 128 байт? SPI фрамки килобайтами память мериют... Если уж ставить внешнюю память то лучше всегда FRAM

туда и пишу.
три сектора
0x08004000-0x08007FFF
0x08008000-0x0800BFFF
0x0800C000-0x0800FFFF

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

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



Не знаю. Уже была на устройстве, причем о ней не знали и писали конфигурацию во флаш.
Почитаю/подумаю про ФРАМки, может уговорю заменить.
У нас главные по железу другие, я человек сторонний, нанятый для задач - в основном по программированию ну и
периодически железячникам палки в колеса вставляю.

он отслеживает как и обычная собака - сброс. но не только с верху ограничение по времени но и с низу. т.е. сброс должен попадать
в "окно". Но прелесть его в другом - он может позвать за один такт до сброса IRQ своё... Вот на нём и считываем проблемный адресс...

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


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

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

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

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

Общие функции вызываемые всеми будут иметь флаги отличающиеся на больше чем 1 это факт их бы я и отслеживать не стал. Но основная линия алгоритма должна идти с различием на 1 или 0. Или это такая каша, которую никакими логами не отследишь... ИМХО.

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

В общем архитектура приложения не менее важна чем прочие средства отладки...

П.С. А киньте почитать про window watchdog пожалуйста, а то что-то сходу не нашел...