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

[manul78]

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

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

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

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

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

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

[twix]

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

Поймать баг несложно на самом деле. Надо сделать всего три вещи.
1. Повесить на шину питания отдельный осциллограф и направить на экран обычную Web камеру с компа. И писать всю неделю видео.
Как вариант взять четырехканальный и писать 4 канала. По видео точно найдете соответствие сбоя и питания.
Стоит это копейки по любому.

2. Повесить отдельный канал логов на RS232 скажем и выдавать в него лог входа выхода во все подпрограммы, плюс тестовую информацию.
Точно также писать неделю с временем входа, выхода в каждую подгрограмму. Сюда же загонять копию всех входных данных, которые
поступают на модуль. Ну это и так будет видно если загонять в лог входные параметры подпрограмм.

3. Вместо реальных данных с датчиков, модулей протоколов, загнать шумовые цифровые данные по всем каналам с максимальной загрузкой.

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

[jcxz]

1. Повесить на шину питания отдельный осциллограф и направить на экран обычную Web камеру с компа. И писать всю неделю видео.
...
2. Повесить отдельный канал логов на RS232 скажем и выдавать в него лог входа выхода во все подпрограммы, плюс тестовую информацию.

Я вижу тут народ потроллить собрался

[twix]

Я вижу тут народ потроллить собрался

Да нет, мы реально вытаскивали 12 часовые логи с шины питания, осциллограф писали с экрана компа, ну вытащили экран по Ethernet на комп и писали экран.
А вебкамерой писали само устройство, дело было в лаборатрии, и некие загадочные глюки были похожи на вмешательство людей. Вот чтобы отсечь смежников
писали вебкамерой провода подключенные к устройству.

Какой бы отшиб не был у завода, старенький ноут, недорогой USB осциллограф и запись с экрана ноутбука сделать реально. Положить его где нить в углу и
можно по Ethernet заходить удаленным рабочим столом и смотреть чего там и как.

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

А уж валить в ПО данные случайно сгенерированные максимальным потоком стандартная процедура вообще. Где тут троллинг?

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

Сообщение отредактировал twix - Apr 24 2018, 16:44

[jcxz]

А уж валить в ПО данные случайно сгенерированные максимальным потоком стандартная процедура вообще. Где тут троллинг?

1) С чего Вы вообще решили что у девайса автора есть экран?
2) Окей - записали Вы неделю 4 осциллограммы, потом ещё сели сами и за пару месяцев их всё просмотрели и.... ничего не нашли. Дальнейшие действия?
А за эти 2 месяца уже могли бы весь быдлокод переписать. И был бы гарантированный результат.

Стоит это копейки по любому.

Ваша зарплата за 2 месяца сидения у экрана - это копейки? Хммм... может Вам лучше поискать другую работу?

3) Отдельный канал логов на RS-232 - это конечно отдельная песня!!!

входа выхода во все подпрограммы

Что именно писать? Для каждой п/п просто определённых два числа? Предположим, что для такого числа достаточно 16 бит (по общему кол-ву функций).
И предположим что среднее время выполнения всех функций == ~72 такта.
Итого имеем: 16*2*1МГц - т.е. необходим RS-232 с битрейтом 32Мб/сек. Не кажется Вам что это черезчур для RS-232-а?
Ну ладно - ок, допустим - нашёл ТС такой RS-232. Считаем далее:
2*2*1e+6*60*60*24*7 = ~ 2.4e+12 байт - итого через неделю работы получаем 2.4 Терабайта таких чисел.
Теперь осталось Вам просто сесть и разобраться в этом месиве из малоосмысленных чисел! И я думаю этой работы не только Вам до самой пенсии хватит, но и внукам и правнукам в наследство останется К тому времени уже сам девайс прахом пойдёт, а может и предпрятие - тоже, где сей глючный девайс эксплуатируется.
Это ещё даже не говоря о том, что проявление бага во время работы некоей функции совсем не говорит о том, что проблема именно в ней. А не в другой функции, за несколько тысяч тактов до неё порушившей память. Или функции в ISR или в другой задаче ОС или....
Т.е. - потребуется многократная фиксация бага. И кратное увеличение количества поколений ваших потомков для анализа нагенерённого добра.
В то время как один нанятый за нормальный деньги грамотный программист уже давным-давно переписал бы весь студенческий колхоз на вменяемый код.

Особенно если виновато железо, вот взяла вся память и обнулилась.

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

Скорости конечно у RS232 невысокие, ну так писать то можно точки, которые умещаются в его производительность.

Исходя из вышеизложенного примем, что каждую секунду девайс совершает примерно 2e+6 входов-выходов в функции, которые надо писать.
А писать мы могем только 115200 бод. Т.е.: 32e+6/115200 = ~278 - это значит записываться будет только каждый 278-й вход или выход.
И соответственно остальные 277 останутся за бортом. Надеетесь, что автор - счастливчик, ему повезёт и баг случится именно в этом 278-м вызове, а не остальных 277 ?

[twix]

1) С чего Вы вообще решили что у девайса автора есть экран...

И так далее по тексту, что сказать, тяжелая у вас жизнь