Как поимать "баг" в STM32 на скорости 72 MHz?, методы поиска и устранения спонтанных и редких сбоев в работе МК Опции

[manul78]

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

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

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

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

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

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

[haker_fox]

В таких случаях надо ставить внешний WDT

Посмотрел бегло микросхемы внешних псов, да, должно работать, т.к. отключить их невозможно.

[yuri_t]

Дизайн WDT должен отвечать (как минимум) следущим трбованиям

- Иметь независимый от CPU генератор

- Не иметь run-time точек конфигурации (как, например PIC WDT)

Этим требованиям НЕ отвечают 99% встроенных в CPU WDT;

Fault tolerant: 2 документа обзорного типа attached

 sam_boeing_slides.ppt ( 426 килобайт ) Кол-во скачиваний: 30

 AIRBUS_A320_A330_A340_Electrical_Flight_Controls.pdf ( 1.09 мегабайт ) Кол-во скачиваний: 61

[haker_fox]

Fault tolerant: 2 документа обзорного типа attached

О! Спасибо! Почитаем!!!

[Ruslan1]

50/50... Есть проект "маршрутизатор-переводчик" промышленный. По 485-му "мастер" разговаривает с 232-ми "слейвами". Протоколы разные.
они известны, но изменить их нельзя. Данный девайс получает пакеты, переводит их в нужный формат и отдаёт "слейвам", получает от них ответ, опять переводит в другой протокол и отправляет "мастеру".
Вот такая штука из "говна и палок", работает... Но с глюками. Спонтанными. Может долго работать без сбоев. Но иногда частит. Суть в том, что глюки начинают вылазить при оживленном траффике по сети, если запросов-ответов мало может неделями работать без проблем.

Это вообще не проблема, и решается очень "плоско и дубово": система обвешивается логическими анализаторами, которые пишут канал связи и некоторые тестовые пины. Для отладки еще полезно завести специальный канал для сигнализации ошибки, и по нему разбираться в гигабайтах логов.
Я такое делал на системах до полсотни устройств с непонятными глюками по связи, применял наверное до десятка 8-канальных китайских анализаторов в параллель (именно сигналы отслеживать, а не данные!). Все писалось на комп сутками. Ничего сложного в разборках, обычная рутина.

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

Логический анализатор- это "абсолютное оружие" при отладке.
Обычно больше сложности в правильном планировании таких эксперимента, чем в разборке результатов.

Девайс работает на отшибе на территории завода. К нему лишний раз не набегаешься, и лабораторию измерительную не соорудить вокруг.

Ну это вообще тепличные условия.