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

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

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

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

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

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

Стек "растёт" в сторону младших адресов - убираете его в начало ОЗУ: уберёте один пункт головной боли и получите один чёткий индикатор, когда стек достигает "дна". Куча и статическая память из причин "головняка" устраняются.

Сообщение отредактировал Obam - Apr 24 2018, 14:30

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

А какой смысл отлаживать чьё-то гумно, на которое даже смотреть противно? Пишите своё.

Еслиб Вы поподробнее расписали что-есть-девайс, в смысле структуры периферии (внешней) и софта, могобыть и решение упростилось бы.
Если "слет" вызван мощной помехой - то при чем тут софт и железо ?
Это можно ловить долго и с туманной перспективой. Если есть возможность поставить "подменку" - это самый правильный ход.
Проверьте "окружение" девайса, питание, помехи на линиях связи итп.
По софту - извиняюсь, конечно, проверьте потенциально-вечные while(). Если таковые имеются (а вдруг, если не в своем коде, то в подулючаемом чужом), замените на

ps
особенно в таком контексте

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

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

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

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

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

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

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

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

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

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

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

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 или в другой задаче ОС или....
Т.е. - потребуется многократная фиксация бага. И кратное увеличение количества поколений ваших потомков для анализа нагенерённого добра.
В то время как один нанятый за нормальный деньги грамотный программист уже давным-давно переписал бы весь студенческий колхоз на вменяемый код.


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


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

Учащение сбоев при увеличении трафика почти однозначно говорит о ситуации называемой "race condition"
Если нет RTOS, то надо досконально перетрясти все прерывания на предмет использования глобальных переменных.
Проще всего автору взять и искусственно увеличить частоту прерываний относящихся к интерфейсам.
Особенно хорошо бывает когда частоты прерываний очень близки.
Либо близки частоты главного цикла и прерываний.
Тогда точки прерываний плавно проходят абсолютно по всему рабочему коду не оставляя белых пятен с возможными гонками.

"Знали-бы где упасть - соломку подстелили-бы..." (с)

Тут я полностью согласен. Быдлокодерство не подразумевает ни ведение грамотной документации, ни специальных программных вставок-решений для отладки. Слепили из "говна и палок" - заработало кое-как и ладно... А там хоть не рассветай...




Второе грамотное предложение.

Действительно, надо было сделать хотя-бы пару идентичных устройств, дабы в процессе тестирования и работы отсечь аппаратные неисправности, как-то битый МК, обвязка, комплектующие и пр. То есть чётко отделить железо от софта




Время - есть. Денег - нет....

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

Я уже отвечал выше. "Это не моя война..." (с)

Меня интересуют методы. Данный девайс и его глюки приведены как пример.

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



Извините, но очень смешно...

По питанию проблем нет и быть не может. Автомобильный аккумулятор и два линейных регулятора на 5 и 3.3 Вольта. Никаких импульсников и пр.



Вот здесь уже теплее... Человек, который давно уже бьётся с данным устройством связывает сбои именно с этим.

Дело в том, что пакеты отправляемые "мастеру" фиксированной величины. Этим спокойно занимается DMA.
А вот пакеты поступающие от "мастера" разной величины, поэтому разработчик сделал прием на прерываниях.
Так как "мастеров" несколько, я также думаю что проблема в одновременном получении пакетов от нескольких "мастеров" сразу.

Арбитраж видимо был не предусмотрен...



Немножко об отладочной системе CoreSight...

Кто-то тут писал про Segger-овский ULINK 2, так вот, у STM32 урезаная версия CoreSight, которая не поддерживает ETM

Так что с трассировкой прерываний через крутой ULINK 2 пролёт...

Сообщение отредактировал manul78 - Apr 24 2018, 20:56

Ну ладно, не вопрос, когда переберете все варианты, посмеемся вместе

Это как????
Один драйвер - много физики, одна физика с миксом на внешние каналы, или фулл эмуляция на железе не предназначенном для этих целей?

Не всё так однозначно.
Интерфейсы есть какие-нибудь, на них защитные диоды есть, высоковольтный импульс диоды замкнут на питание, стабилизатор не успел отработать - питание подпрыгнуло.
А например RS485, на КЗ в линии, может отдавать ток до 250 мА - при кратковременном КЗ можно получить кратковременную просадку питания.