реклама на сайте
подробности

 
 
8 страниц V   1 2 3 > »   
Reply to this topicStart new topic
> Как поимать "баг" в STM32 на скорости 72 MHz?, методы поиска и устранения спонтанных и редких сбоев в работе МК
manul78
сообщение Apr 24 2018, 12:09
Сообщение #1


Местный
***

Группа: Участник
Сообщений: 403
Регистрация: 14-05-07
Из: Россия, г.Пенза
Пользователь №: 27 719



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

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

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

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

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

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


--------------------
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
Go to the top of the page
 
+Quote Post
Kabdim
сообщение Apr 24 2018, 12:25
Сообщение #2


Местный
***

Группа: Свой
Сообщений: 480
Регистрация: 26-11-14
Из: Зеленоград
Пользователь №: 83 842



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

А эта темпа предметная или пофлудить об абстракте?
Go to the top of the page
 
+Quote Post
Mareng
сообщение Apr 24 2018, 12:25
Сообщение #3


Участник
*

Группа: Участник
Сообщений: 52
Регистрация: 19-02-07
Пользователь №: 25 487



Обычно помогало постепенное упрощения функционала до момента когда перестает "зацикливаться, перзагружаться, вешаться", а дальше логическая цепочка и высшие силы)
Go to the top of the page
 
+Quote Post
AVI-crak
сообщение Apr 24 2018, 12:29
Сообщение #4


Частый гость
**

Группа: Участник
Сообщений: 161
Регистрация: 16-10-15
Пользователь №: 88 894



Скорми проект бешеной лошади. Уверен что она найдёт огромное количество ошибок.
Потому как проектов без ошибок не существует. (Если проект не содержит ошибок - значит сам проект ошибка.)
Go to the top of the page
 
+Quote Post
iosifk
сообщение Apr 24 2018, 12:33
Сообщение #5


Гуру
******

Группа: Модераторы
Сообщений: 3 870
Регистрация: 8-09-05
Из: спб
Пользователь №: 8 369



Цитата(Mareng @ Apr 24 2018, 15:25) *
Обычно помогало постепенное упрощения функционала до момента когда перестает "зацикливаться, перзагружаться, вешаться", а дальше логическая цепочка и высшие силы)

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

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

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

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


--------------------
www.iosifk.narod.ru
Go to the top of the page
 
+Quote Post
HardEgor
сообщение Apr 24 2018, 12:36
Сообщение #6


Гуру
******

Группа: Свой
Сообщений: 2 018
Регистрация: 3-03-06
Из: Tomsk
Пользователь №: 14 925



Цитата(manul78 @ Apr 24 2018, 19:09) *
Как поймать "Баг" на скорости 72 МГц ?

Сделать 10 одинаковых устройств, функционал распределить между ними. Там где сломается - там проблема.
Вообще тема тестирования бесконечна.
Если время=деньги, тогда надо брать крутой отладчик типа ULINKpro и через него писать лог в компьютер.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Apr 24 2018, 12:43
Сообщение #7


Гуру
******

Группа: Свой
Сообщений: 4 501
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(manul78 @ Apr 24 2018, 15:09) *
Как поймать "Баг" на скорости 72 МГц ?

Элементарная обработка исключений хотя-бы сделана?
Go to the top of the page
 
+Quote Post
manul78
сообщение Apr 24 2018, 12:55
Сообщение #8


Местный
***

Группа: Участник
Сообщений: 403
Регистрация: 14-05-07
Из: Россия, г.Пенза
Пользователь №: 27 719



Цитата(Kabdim @ Apr 24 2018, 15:25) *
Постараться делить неопределенность на малые куски.


Есть такая мысль. Решил слизать с промышленных контроллеров. Там один 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... sm.gif Есть проект "маршрутизатор-переводчик" промышленный. По 485-му "мастер" разговаривает с 232-ми "слейвами". Протоколы разные.
они известны, но изменить их нельзя. Данный девайс получает пакеты, переводит их в нужный формат и отдаёт "слейвам", получает от них ответ, опять переводит в другой протокол и отправляет "мастеру".
Вот такая штука из "говна и палок", работает... Но с глюками. Спонтанными. Может долго работать без сбоев. Но иногда частит. Суть в том,
что глюки начинают вылазить при оживленном траффике по сети, если запросов-ответов мало может неделями работать без проблем.

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


--------------------
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
Go to the top of the page
 
+Quote Post
Kabdim
сообщение Apr 24 2018, 12:57
Сообщение #9


Местный
***

Группа: Свой
Сообщений: 480
Регистрация: 26-11-14
Из: Зеленоград
Пользователь №: 83 842



При такой постановке - устроить флуд по каналам. Скорее всего либо проблемы на каком-то протоколе, либо при флуде вообще - всплывут.
Go to the top of the page
 
+Quote Post
manul78
сообщение Apr 24 2018, 12:58
Сообщение #10


Местный
***

Группа: Участник
Сообщений: 403
Регистрация: 14-05-07
Из: Россия, г.Пенза
Пользователь №: 27 719



Цитата(HardEgor @ Apr 24 2018, 15:36) *
Сделать 10 одинаковых устройств, функционал распределить между ними. Там где сломается - там проблема.
Вообще тема тестирования бесконечна.
Если время=деньги, тогда надо брать крутой отладчик типа ULINKpro и через него писать лог в компьютер.


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

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



--------------------
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
Go to the top of the page
 
+Quote Post
AlanDrakes
сообщение Apr 24 2018, 13:03
Сообщение #11


Частый гость
**

Группа: Участник
Сообщений: 91
Регистрация: 2-05-15
Из: Россия, Омск
Пользователь №: 86 474



После перезапуска проверять состояние регистров причины и отсылать сообщения / писать их в логи?
Ну это как вариант.
А вообще - хороший вариант - внутренняя же трассировка проблемного события.
Это когда код вместо резкой перезагрузки сохраняет состояние системы и пишет в консоль (или файл, а лучше в два) сообщение о том что произошло, когда, почему и дампы, дампы, дампы...
Go to the top of the page
 
+Quote Post
jcxz
сообщение Apr 24 2018, 13:03
Сообщение #12


Гуру
******

Группа: Свой
Сообщений: 4 501
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(manul78 @ Apr 24 2018, 15:58) *
Глюки спонтанны, но как заметили связаны с увеличением траффика передаваемых данных.

Внимательное ревью кода и обработка исключений творят чудеса даже при самых спонтанных багах laughing.gif
Go to the top of the page
 
+Quote Post
manul78
сообщение Apr 24 2018, 13:19
Сообщение #13


Местный
***

Группа: Участник
Сообщений: 403
Регистрация: 14-05-07
Из: Россия, г.Пенза
Пользователь №: 27 719



Цитата(jcxz @ Apr 24 2018, 16:03) *
Внимательное ревью кода и обработка исключений творят чудеса даже при самых спонтанных багах laughing.gif


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

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

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

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

Цитата(AlanDrakes @ Apr 24 2018, 16:03) *
А вообще - хороший вариант - внутренняя же трассировка проблемного события.
Это когда код вместо резкой перезагрузки сохраняет состояние системы и пишет в консоль (или файл, а лучше в два) сообщение о том что произошло, когда, почему и дампы, дампы, дампы...


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

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

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


--------------------
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Apr 24 2018, 13:39
Сообщение #14


Ally
******

Группа: Модераторы
Сообщений: 5 856
Регистрация: 19-01-05
Пользователь №: 2 050



Цитата(manul78 @ Apr 24 2018, 15:09) *
Что может быть проще? Написали в обработчике прерывания от "собаки" процедуру инициализации SPI,UART
или I2C и выплюнули в внешнюю Флэш-память дамп всей оперативной памяти + состояние регистров.
Далее считал с флэши и сиди анализируй - где споткнулся или завис МК. Бинго !

На самом деле это будет только началом. Дампы дают очень мало информации.
Берите в качестве примера лучшие практики.
А лучшие практики можно найти в методах отладки стека протоколов поверх TCP.
Издревле там люди применяют счетчики и статистики.
Скажем счетчики SNMP. Там на одном только MAC уровне их несколько десятков.
В хороших чипах эти счетчики сделаны аппаратно.
Даже если вы не понимаете назначение многих их них один взгляд на поведение счетчиков может дать идеи где искать проблему.

Дальнейшими шагом было бы применить RTOS с автодиагностикой стеков, задач и объектов синхронизации.
Дальше можно было бы применить визуализаторы типа https://www.segger.com/products/development...ols/systemview/

Эффективный поиск багов всегда должен включать рефакторинг, а не ревью.
Go to the top of the page
 
+Quote Post
iosifk
сообщение Apr 24 2018, 13:48
Сообщение #15


Гуру
******

Группа: Модераторы
Сообщений: 3 870
Регистрация: 8-09-05
Из: спб
Пользователь №: 8 369



Цитата(manul78 @ Apr 24 2018, 16:19) *
Это устройство не в процессе разработки и не на стадии тестирования. Оно уже в сети, и на нем завязано производство.

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

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

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




--------------------
www.iosifk.narod.ru
Go to the top of the page
 
+Quote Post

8 страниц V   1 2 3 > » 
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 21st May 2018 - 20:24
Рейтинг@Mail.ru


Страница сгенерированна за 0.01085 секунд с 7
ELECTRONIX ©2004-2016