Как поймать "Баг" на скорости 72 МГц ?
(тема для обсуждения и поиска решения)

Задача: Есть условное устройство на базе STM32F103C8 (Cortex-3M) которое работает на максимально разрешенной частоте в режиме максимальной нагрузки, то есть активно работает ядро АРМ, периферия, порты ввода-вывода, DMA, таймеры.
В процессе длительной работы (неделя) систематически происходит сбой. Зацикливание, спонтанный неконтролируемый сброс МК и т.д.
Всё это возможно по ряду причин: Сбой по питанию, переполнение стека или "кучи", кривой арбитраж шин или прерываний, неисправность МК. Причин масса.

Вопрос: Как поймать сбой происходящий в периоде довольно длительного отрезка времени?
У простого разработчика разумеется нет тех аппаратных возможностей которыми оперируют крупные лаборатории и производители серийных устройств, нет возможности обвешать "девайс" супервайзерами, логическими анализаторами и неделями круглосуточно гонять устройство, писать
Log-и, а потом отрядом в 50 человек анализировать их.

Стало быть нам придётся думать самим. Что у нас есть? Есть отладочная система CoreSight.
Есть две "собаки" WatchDog таймера. Внутренний, зависимый от периферии и независимый автономный.
Внутренний оконный WWDT, перед командой Сброса МК может сгенерировать прерывание. Данная опция специально разработана инженерами из STM для того, чтобы иметь возможность сделать дамп данных (память, состояние регистров, состояние периферии и т.д) перед сбросом системы МК.
Что может быть проще? Написали в обработчике прерывания от "собаки" процедуру инициализации SPI,UART
или I2C и выплюнули в внешнюю Флэш-память дамп всей оперативной памяти + состояние регистров.
Далее считал с флэши и сиди анализируй - где споткнулся или завис МК. Бинго !

Это я описал самое очевидное и "тепличное" развитие событий. ТАК бывает... Но редко...
А если контроллер прерываний "упал" или зациклился в одной точке? Если вообще ядро АРМ "упало" или
зациклилось? А может вообще - стек налетел на "кучу" и управляющая программа рандомно пошла вразнос и
остановила генераторы шин или периферии? В данном случае "собака" WWDT бессильна. Она мертва.
Есть конечно ещё независимый IWWDT - но он не генерит прерываний - тупо сбрасывает контроллер.
Есть отладочное CoreSight - до которого тоже ещё надо уметь достучаться.

Так что Давайте высказываться, Уважаемые участники сообщества. У кого какие есть на это мысли и решения?

Вы тестируете какими-то скриптами? Они выполняются на платформе конечного устройства, или на внешнем процессоре (например на ПК)? Если так, то как они получают доступ к ФС устройства?

Вот один из примеров - https://geektimes.com/post/274416/

Это обычные тесты скорости, надежность и "безглючность" ФС не тестируется.

Во! И это только тесты скорости.
А теперь покажте мне героя который еще добавит сюда еще тесты надежности и безглючности.

Жаль, что потер уже свой проект, в котором были тесты на чтение\запись в течении суток, работу ФС в режимах внезапного удаления карты, появления бедов, и пр. ошибок в интерфейсе, причем проверялось это в то время на жаре и холоде... По результатам выявилось несколько проблем в модуле ФС и драйвере карты. Прошло 5 лет и я уже подзабыл что да как...

Но опять же при чем тут температура, внезапное удаление карты и течение суток.
Вопрос стоит как проверить на программные ошибки?
Тестировать сами SD карты можно и на компьютере. С этим как раз проблем нет.

Причем тут сд-карты, проверялось, что будет, если внезапно удалить карту во время операций инита, чтения или записи. При первых проверках выяснилось, что драйвер зависает, ФС работает неадекватно, при посл. вставлении карты и пр... Температура - это как доп. испытание МК, карты и платы...
В подавляющем большинстве демок и проектов такое тестирование не проводится.

Ну и при чем тут тестирование все таки?
Это обычная итерационная процедура разработки.
Файловая сложная, вы ее до конца конечно не изучили и методом тыка вот так добивались работы при извлечении карты.
Нормальный подход, сам так делаю.
Но это не то тестирование, которое тут воспевают.

Это как-раз и называется "нагрузочное тестирование"... К сожалению большинство кодеров, которые делают демки для соотв. камней этой штукой не заморачиваются от слова вообще.

какой ужас

Что делать, далеко не всех клиентов заботит качественное питание аппаратуры и качество соединителей, а приказать им я не могу, вот и стараюсь, чтоб хотя бы с моей стороны все четко отрабатывалось.

Нет это я бы назвал "перегрузочное" тестирование.
Т.е. тестирование чего угодно: там климатики, износа карты, каких то экстремальных механических вмешательств, даже может влияние ядерного взрыва,
но только не того что реально помогает выявить глубокие баги.


А теперь догадайтесь зачем все таки 4-е! WDT ставят, причем оконных.
За сбои питания отвечает не WDT, а brownout детектор.
А если вам нужно привлекать к этому WDT, то у вас точно не все в порядке с тестированием на программные зависания.

А зачем? Я полагаю, что WDT это абсолютно независимый (ну кроме питания, одного корпуса) счётчик от процессора и его периферии. Который в любом случае сбросит процессор, если за время таймаута, не будет сброшен. Для повышения надёжности? Или каскадирования? Т.е. сработал 1-й пёс - предупреждение, второй - серьёзное предупреждение и т.п.? Или на каждое ядро свой пёс?

Так для контроля реалтайма. Не на ядро, а на задачу.