[manul78 4]

Как поймать "Баг" на скорости 72 МГц ?

(тема для обсуждения и поиска решения)

 

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

В процессе длительной работы (неделя) систематически происходит сбой. Зацикливание, спонтанный неконтролируемый сброс МК и т.д.

Всё это возможно по ряду причин: Сбой по питанию, переполнение стека или "кучи", кривой арбитраж шин или прерываний, неисправность МК. Причин масса.

 

Вопрос: Как поймать сбой происходящий в периоде довольно длительного отрезка времени?

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

Log-и, а потом отрядом в 50 человек анализировать их.

 

Стало быть нам придётся думать самим. Что у нас есть? Есть отладочная система CoreSight.

Есть две "собаки" WatchDog таймера. Внутренний, зависимый от периферии и независимый автономный.

Внутренний оконный WWDT, перед командой Сброса МК может сгенерировать прерывание. Данная опция специально разработана инженерами из STM для того, чтобы иметь возможность сделать дамп данных (память, состояние регистров, состояние периферии и т.д) перед сбросом системы МК.

Что может быть проще? Написали в обработчике прерывания от "собаки" процедуру инициализации SPI,UART

или I2C и выплюнули в внешнюю Флэш-память дамп всей оперативной памяти + состояние регистров.

Далее считал с флэши и сиди анализируй - где споткнулся или завис МК. Бинго !

 

Это я описал самое очевидное и "тепличное" развитие событий. ТАК бывает... Но редко... :)

А если контроллер прерываний "упал" или зациклился в одной точке? Если вообще ядро АРМ "упало" или

зациклилось? А может вообще - стек налетел на "кучу" и управляющая программа рандомно пошла вразнос и

остановила генераторы шин или периферии? В данном случае "собака" WWDT бессильна. Она мертва.

Есть конечно ещё независимый IWWDT - но он не генерит прерываний - тупо сбрасывает контроллер.

Есть отладочное CoreSight - до которого тоже ещё надо уметь достучаться.

 

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

 

[Kabdim 0]

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

Ну и банальщина - все предупреждения, компиляция с макс оптимизацией.

 

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

[Mareng 1]

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

[AVI-crak 0]

Скорми проект бешеной лошади. Уверен что она найдёт огромное количество ошибок.

Потому как проектов без ошибок не существует. (Если проект не содержит ошибок - значит сам проект ошибка.)

[iosifk 3]

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

Я только немного добавлю...

Есть сокращение DFT. Там много чего написано, но это надо изучать ДО ТОГО КАК аппаратура сделана...

 

https://www.google.ru/search?q=Design+For+T...ameter}ie=UTF-8

 

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

 

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

[HardEgor 87]

Как поймать "Баг" на скорости 72 МГц ?

Сделать 10 одинаковых устройств, функционал распределить между ними. Там где сломается - там проблема.

Вообще тема тестирования бесконечна.

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

 

[jcxz 242]

Как поймать "Баг" на скорости 72 МГц ?

Элементарная обработка исключений хотя-бы сделана?

[manul78 4]

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

 

Есть такая мысль. Решил слизать с промышленных контроллеров. Там один 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-ми "слейвами". Протоколы разные.

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

Вот такая штука из "говна и палок", работает... Но с глюками. Спонтанными. Может долго работать без сбоев. Но иногда частит. Суть в том,

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

 

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

[Kabdim 0]

При такой постановке - устроить флуд по каналам. Скорее всего либо проблемы на каком-то протоколе, либо при флуде вообще - всплывут.

[manul78 4]

Сделать 10 одинаковых устройств, функционал распределить между ними. Там где сломается - там проблема.

Вообще тема тестирования бесконечна.

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

 

Я уже писал в начале. С крутым отладчиком, в тёплой лаборатории и при достаточном бюджете...

 

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

Глюки спонтанны, но как заметили связаны с увеличением траффика передаваемых данных.

 

 

[AlanDrakes 1]

После перезапуска проверять состояние регистров причины и отсылать сообщения / писать их в логи?

Ну это как вариант.

А вообще - хороший вариант - внутренняя же трассировка проблемного события.

Это когда код вместо резкой перезагрузки сохраняет состояние системы и пишет в консоль (или файл, а лучше в два) сообщение о том что произошло, когда, почему и дампы, дампы, дампы...

[jcxz 242]

Глюки спонтанны, но как заметили связаны с увеличением траффика передаваемых данных.

Внимательное ревью кода и обработка исключений творят чудеса даже при самых спонтанных багах :laughing:

[manul78 4]

Внимательное ревью кода и обработка исключений творят чудеса даже при самых спонтанных багах :laughing:

 

Если честно - "Это не моя война..." (с)

 

Софт писали какие-то студенты на Cube-HAL-е... Потом они уволились, допиливали другие... и т.д.

 

Я привёл данный случай как пример. Но если софт писали дилетанты - это не значит, что не глючит софт написанный профессионалами,

по всем канонам и со всеми ритуалами.

 

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

нет, но поределённые базовые шаги и грабли думаю будут интересны всем.

 

А вообще - хороший вариант - внутренняя же трассировка проблемного события.

Это когда код вместо резкой перезагрузки сохраняет состояние системы и пишет в консоль (или файл, а лучше в два) сообщение о том что произошло, когда, почему и дампы, дампы, дампы...

 

Построить "своречник" вокруг столба с "девайсом", поставить там ноутбук и жить там-же... круглосуточно... :)

 

Это устройство не в процессе разработки и не на стадии тестирования. Оно уже в сети, и на нем завязано производство.

 

Я понимаю Вас. Меня интересуют "методы", пусть даже нестандартные. Возможно даже кто-то здесь имеет в своём распоряжении

самопальные компактные супервазеры для STM32, я-же не прошу схему, код и готовые решения на халяву. Я ищу ВЕКТОР направления

в котором двигаться.

[AlexandrY 3]

Что может быть проще? Написали в обработчике прерывания от "собаки" процедуру инициализации SPI,UART

или I2C и выплюнули в внешнюю Флэш-память дамп всей оперативной памяти + состояние регистров.

Далее считал с флэши и сиди анализируй - где споткнулся или завис МК. Бинго !

На самом деле это будет только началом. Дампы дают очень мало информации.

Берите в качестве примера лучшие практики.

А лучшие практики можно найти в методах отладки стека протоколов поверх TCP.

Издревле там люди применяют счетчики и статистики.

Скажем счетчики SNMP. Там на одном только MAC уровне их несколько десятков.

В хороших чипах эти счетчики сделаны аппаратно.

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

 

Дальнейшими шагом было бы применить RTOS с автодиагностикой стеков, задач и объектов синхронизации.

Дальше можно было бы применить визуализаторы типа https://www.segger.com/products/development...ols/systemview/

 

Эффективный поиск багов всегда должен включать рефакторинг, а не ревью.

[iosifk 3]

Это устройство не в процессе разработки и не на стадии тестирования. Оно уже в сети, и на нем завязано производство.

 

Я понимаю Вас. Меня интересуют "методы", пусть даже нестандартные. Возможно даже кто-то здесь имеет в своём распоряжении

самопальные компактные супервазеры для STM32, я-же не прошу схему, код и готовые решения на халяву. Я ищу ВЕКТОР направления

в котором двигаться.

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

Если разработку рассматривать как переходный процесс, то за 3 "тау" мы придем к уровню 5% ошибок. И для кого-то этого будет вполне достаточно, т.к. для этого типа аппаратуры 5% ошибок будут не критичны. Ну например домофон или аэрогриль. Ну, сбойнут или зависнут. Не так страшно. А если аппаратура работает долго, и ошибки фиксируются как нарушение работы, то тогда и 1% ошибок будет неприемлем. Да вот только для 1% а уж про 0,1% нужно столько этих "тау", да еще не в лаборатории, а в труднодоступном месте.

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

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

 

И эта фраза:"Построить "своречник" вокруг столба с "девайсом", поставить там ноутбук и жить там-же... круглосуточно..." Говорит о том, что ТС еще не натрахался "в поле"...