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

[manul78]

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

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

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

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

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

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

[Kabdim]

Постараться делить неопределенность на малые куски. Есть подозрение на питание - проверяйте на стенде с хорошим источником. Есть/нет? Есть подозрение на свою криволапость - подробные логи и отдавать их наружу. Думаете что срабатывает внешняя собака - сделать технический бутлоадер, который отдает содержимое рам наружу. Думаете про стеки - сделайте их защиту или вычислите их максимальное значение для каждой задачи. И т.д. А в аппаратные сбои блоков процессора без наличия проблем с питанием, я простите не верю.
Ну и банальщина - все предупреждения, компиляция с макс оптимизацией.

А эта темпа предметная или пофлудить об абстракте?

[manul78]

Постараться делить неопределенность на малые куски.

Есть такая мысль. Решил слизать с промышленных контроллеров. Там один 8-ми битный порт отдают на real-time bug catcher.
его подключают к прозрачному регистру-защёлке типа 74HC573 а выходы на 7 светодиодов. 7-бит "красный", 6-й "зелёный", остальные "жёлтые"
Суть такая: Присваиваются номера. Процедурам на вход и на выход и нее, и прерываниям на вход и на выход.
Например: Процедура A (0x01 -IN, 0x02 - OUT) , Процедура B (0x03-IN, 0x04 - OUT)..... и т.д.
Прерывание A (0x41 -IN, 0x42 - OUT) , Пррерывание B (0x43-IN, 0x44 - OUT)..... и т.д.
При прирывании по WWDT перед сбросом в информационном байте устанавливается 7-й бит в 1, это чтобы после сброса
при начальных установках не скинуло содержимое регимтра-защёлки подключенной к bug-catcher порту.

Процедуры и прерывания пишут свои номера при входе и выходе в порт. Регистр-защёлка их запоминает. В случае ступора или сброса,
на светодиодах видно - где споткнулся МК.

А эта темпа предметная или пофлудить об абстракте?

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

А вообще - то, мне тема интересная. Я большой любитель ловли "багов", и пофлудить не прочь. В любом случае это - ОПЫТ.

[juvf]

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

нувыблиндаёте!!! Вы же нашли, можно сказать, багу и продолжаете гадать на кофейной гуще.

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

[AlexandrY]

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

Хотя звучит умно, но по факту это немного глупо.
На кой нагружать трафиком если известно, что дивайс или система наверняка заглохнет при превышении определенного уровня?
Что вам даст если вы зафиксируйте несколько раз этот уровень?
Ошибка конечно проявится, но это будет не та ошибка!
А чтобы была та, нужно именно тот трафик смоделировать. А если вы знаете именно тот трафик, то знаете и ошибку.
Так что "стресс-тест" это просто семантический плеоназм в данном случае.

[novikovfb]

На кой нагружать трафиком если известно, что дивайс или система наверняка заглохнет при превышении определенного уровня?

Дивайс должен уйти во вполне определенное состояние при превышении определенного уровня и выйти из него в рабочее после нормализации обстановки.
Например, пропускать только те пакеты, на которые хватает производительности канала, а в слове состояния выставить признак проблем с подключением.
Или при превышении частоты ошибок прекратить общение до паузы в сигнале или появлении корректного сообщения.
Почитайте описание протокола CAN, например.

[AlexandrY]

Дивайс должен уйти во вполне определенное состояние при превышении определенного уровня и выйти из него в рабочее после нормализации обстановки.

В CAN-е это аппаратно сделано, поэтому я только CAN везде и применяю.
И да логируется у меня достаточно счетчиков относящихся к работе CAN.
Но если я сделаю некий "стресс-тест" с хаотичными командами, то система подвиснет, лог будет переполнен, даже могут возникнуть конструктивные повреждения, сработает WDT
И че я выясню в результате?
Попробуйте "стресс-тест" провести где нить в сети промышленных логических контроллеров. Тоже получите катастрофу.

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

[jcxz]

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

Это только говорит о том, что данное устройство неправильно спроектировано.
Никакая комбинация входных данных (валидных или просто мусора) с любой частотой повторения на внешних интерфейсах не должна вводить устройство в состояние ступора либо любое другое нерабочее состояние. Если это не так - это кривое устройство и надо переделывать.
Как то так. Всегда следую данному правилу.
Да и по внутренним интерфейсам устройства - например если у меня есть SPI-FLASH в устройстве, но обращение к ней идёт не часто, то для теста (обнаружения редко проявляющихся непериодических сбоев как у ТС), я нагружаю данный интерфейс транзакциями чтения/записи по самое нехочу. Например - создаю несколько задач ОС, которые параллельно обращаются к этому интерфейсу со случайными запросами чтения/записи случайной длины и адресом, так чтобы загрузка CPU при такой работе была близка к максимальной. Гоняю этот тест несколько часов с общим объёмом траффика во много ГБ. И одновременно с этим устройство должно продолжать выполнять свои штатные функции.
Вот если за время такого теста сбоев не было - значит всё ок. Иначе - разбираюсь, пока не устраню причину.

[juvf]

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

ППКС

В CAN-е это аппаратно сделано

нет там этого аппаратно. там транспортный уровень аппаратный, а протокольного нет. Например преобразователь протоколов CAN-USART (кан в любой серийный... Modbus, Гранит, МЭК-101, Лисна-Ч....) По кану от датчика приходят данные, их надо передать по МЭК-101 на OPC-сервер. Раз в секунду датчик передает пакет, преобразователь преобразовывает и передает дальше. Если пакеты от датчика пойдут 100 раз в сек.... - преобразователь может не успеть их обрабатывать... Если пакеты от датчика буферезировать, то может переполниться буфер. Ни какой аппаратный кан не поможет.

Попробуйте "стресс-тест" провести где нить в сети промышленных логических контроллеров. Тоже получите катастрофу.

Делаем. Нет катастрофы. Например эл.счетчик. Запрос-ответ, запрос-ответ. Начинаем часто запрашивать - тот отвечает или пропускает запросы, но не виснет. Можно послать запрос и не дожидаясь ответа послать ещё запрос - счетчик не должен зависнуть.

сделать грамотное нагрузочное тестирование очень сложно

Легко. На китах типа дискавери, на китах ПЛИСовых, на ПК.

во вторых оно не для выявления ошибок

Если система легла - то в ней ошибка. Не важно от чего она зависла, от стрес-теста, от действия оператора или от положения звёзд на небе. Как мою плату положет тестировщик - мне не важно. Мне важно, чтобы я мог повторить эти действия и плата легла. Если стрестест её положит за минуту - это замечательно. Попробую под дебагом положить плату, буду смотреть почему лежит, буду смотреть стек вызовов. Либо без дебага, но с дебажними вставками и журналированием. Вобщем если раз в минуту я могу положить плату, то бага находиться быстро.

ps

сработает WDT

в один прекрасный момент отказался от WDT. Эта штука как минимум не нужна, как максимум опасна. Если плата зависла - в программе есть ошибка, нужно её устранять. WDT пересбросит плату и ни кто не узнает о проблеме, пока гильотина не отрежет руку или не упадет самолёт не случиться непоправимое. Если плата работает круглые сутки, годами, без зависаний и без WDT - для меня это показатель, что ошибок нет.

[mantech]

в один прекрасный момент отказался от WDT. Эта штука как минимум не нужна, как максимум опасна. Если плата зависла - в программе есть ошибка, нужно её устранять.

Ну вот и зря. Кроме программных ошибок, от которых кстати собака не всегда "спасает", есть еще и аппаратные проблемы, слишком плавное нарастание питания, дребезг в цепях питания и т.п. с которыми собака хорошо справляется, поэтому никогда от нее не отказываюсь, а программные баги отлавливаю логированием в критических к зависаниям функциях...

[juvf]

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

какой ужас

[mantech]

какой ужас

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