Как поймать "Баг" на скорости 72 МГц ?
(тема для обсуждения и поиска решения)
Задача: Есть условное устройство на базе STM32F103C8 (Cortex-3M) которое работает на максимально разрешенной частоте в режиме максимальной нагрузки, то есть активно работает ядро АРМ, периферия, порты ввода-вывода, DMA, таймеры.
В процессе длительной работы (неделя) систематически происходит сбой. Зацикливание, спонтанный неконтролируемый сброс МК и т.д.
Всё это возможно по ряду причин: Сбой по питанию, переполнение стека или "кучи", кривой арбитраж шин или прерываний, неисправность МК. Причин масса.
Вопрос: Как поймать сбой происходящий в периоде довольно длительного отрезка времени?
У простого разработчика разумеется нет тех аппаратных возможностей которыми оперируют крупные лаборатории и производители серийных устройств, нет возможности обвешать "девайс" супервайзерами, логическими анализаторами и неделями круглосуточно гонять устройство, писать
Log-и, а потом отрядом в 50 человек анализировать их.
Стало быть нам придётся думать самим. Что у нас есть? Есть отладочная система CoreSight.
Есть две "собаки" WatchDog таймера. Внутренний, зависимый от периферии и независимый автономный.
Внутренний оконный WWDT, перед командой Сброса МК может сгенерировать прерывание. Данная опция специально разработана инженерами из STM для того, чтобы иметь возможность сделать дамп данных (память, состояние регистров, состояние периферии и т.д) перед сбросом системы МК.
Что может быть проще? Написали в обработчике прерывания от "собаки" процедуру инициализации SPI,UART
или I2C и выплюнули в внешнюю Флэш-память дамп всей оперативной памяти + состояние регистров.
Далее считал с флэши и сиди анализируй - где споткнулся или завис МК. Бинго !
Это я описал самое очевидное и "тепличное" развитие событий. ТАК бывает... Но редко...
А если контроллер прерываний "упал" или зациклился в одной точке? Если вообще ядро АРМ "упало" или
зациклилось? А может вообще - стек налетел на "кучу" и управляющая программа рандомно пошла вразнос и
остановила генераторы шин или периферии? В данном случае "собака" WWDT бессильна. Она мертва.
Есть конечно ещё независимый IWWDT - но он не генерит прерываний - тупо сбрасывает контроллер.
Есть отладочное CoreSight - до которого тоже ещё надо уметь достучаться.
Так что Давайте высказываться, Уважаемые участники сообщества. У кого какие есть на это мысли и решения?
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
Как поимать "баг" в STM32 на скорости 72 MHz?, методы поиска и устранения спонтанных и редких сбоев в работе МК
Apr 24 2018, 12:09
