Народ, а че вы делаете чтобы изловить 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 пожалуйста, а то что-то сходу не нашел...

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

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

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

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

Может конечно и такое быть. Буду иметь ввиду. Но для этого мне надо исключить софт.
Пока предыдущие 2 случая:
1) в течение суток или 2х в зависимости от ethernet нетворк траффика глохло радио на устройстве.
Оказалось что переполнялась очередь запросов на прерывание от ethernet,
radio работает через SPI (DMA & IRQ), не могло воткнуть свой запрос на обслуживание, в результате висло.
Это относительно простой случай
2) в Кокосе баг в CoWaitForSingleFlag(). Получилось при определенных условиях что задача ушла из waiting list а в ready list не попала.
Вылавливал 2 недели, сужая кольцо. Проявлялось раз в сутки в лучшем случае.

Сейчас получше, но пару раз в неделю 2-3 устройства из сотни может зависнуть.
Это не hard fault, туда уже поставил ловушку.


В RM008 мануале по STM32 windowed watchdog.



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

Так вот, можно просто проверять увеличиваются ли счетчики задач.
Кстати, у меня в дескрипторе задач счетчики уже есть, каждый раз задача переключается, они увеличиваются.
Достаточно, чтобы идентифицировать застрявшую задачу.


Интересная, продуманная идея. Спасибо.
Единственно, я опасаюсь повторения ситуации, когда у меня все задачи стали изза бага в Кокосе.
Айдл правда работал.
Надо или в айдл задачу все это запихивать или в таймер, что лучше, мне кажется.

Ошибка в ядре это очень серьезно. Я бы бросал эту ось пока не поздно.

А где их нет?
Поздно бросать.
Устройство само по себе state machine, все стандартно катится по временным отрезкам.
Ось не нужна. Даже вредна. Но она есть. Приходится с этим жить.

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


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


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


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

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