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

На моей практике проблемы с ЭМС часто приводили к защелкиванию внутренней периферии, тогда никакие 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, чтоб все вернулось в исходное состояние на шине.