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

[manul78]

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

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

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

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

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

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

[Kabdim]

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

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

[Mareng]

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

[AVI-crak]

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

[iosifk]

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

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

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

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

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

[HardEgor]

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

Сделать 10 одинаковых устройств, функционал распределить между ними. Там где сломается - там проблема.
Вообще тема тестирования бесконечна.
Если время=деньги, тогда надо брать крутой отладчик типа ULINKpro и через него писать лог в компьютер.

[jcxz]

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

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

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

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

[Kabdim]

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

[manul78]

Сделать 10 одинаковых устройств, функционал распределить между ними. Там где сломается - там проблема.
Вообще тема тестирования бесконечна.
Если время=деньги, тогда надо брать крутой отладчик типа ULINKpro и через него писать лог в компьютер.

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

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

[AlanDrakes]

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

[jcxz]

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

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

[manul78]

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

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

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

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

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

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

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

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

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

[AlexandrY]

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

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

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

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

[iosifk]

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

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

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

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

[Obam]

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

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

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

[-= Александр =-]

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

[jcxz]

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

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

[k155la3]

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

Код

int MaxCount = 10000;
while(. . . )
{
. . . .
MaxCount--;
if(MaxCount == 0)
{
     while(1) { ногодрыг на LED, вывод на терминал __LINE__, __FUNCTION__ итд}
}

}

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

на Cube-HAL-е...

[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 ?

[AlexandrY]

Вероятность виноватости железа по описанию проблемы автором тут видится примерно на уровне ноль целых хрен десятых процента.

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

[manul78]

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

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

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

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

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

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

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

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

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

[twix]

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

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

[manul78]

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

[twix]

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

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

[AVI-crak]

Так как "мастеров" несколько, я также думаю что проблема в одновременном получении пакетов от нескольких "мастеров" сразу.

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

[HardEgor]

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

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

[AlexandrY]

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

Чтобы подпрыгнуло питание от высоковольтного импульса он должен по энергии превосходить все что упоминается в стандартах на ЭМИ.
Обычных конденсаторов хватает чтобы сгладить все реальные импульсы.
А от нереальных уже что-то должно было бы сгореть.
Да и быстрая просадка питания вызовет всего лишь сброс.
Если копать в питании, то надо искать медленную просадку, а потом ее причину.

В криво сделанных проектах обычно сидит по нескольку ошибок. Исходить надо из этого.
Автомобильный аккумулятор эт кстати отличная причина сбоев.
Потому что это хорошая толстая антенна для FTB импульсов.
Тут на форуме для некоторых разработчиков плат FTB настоящая мистика, которую они не могут постичь годами.
Так что не удивлюсь если после замены аккумулятора на обычный изолированный DC/DC проблемы пропадут (вернее снизится их вероятность).

[amiller]

Кстати а сама постановка вопроса в теме предполагает, что баг проявляется только на частоте 72МГц?
А на частоте, например 60 МГц, всё хорошо?
Может в этом направлении надо копать?

[jcxz]

Кстати а сама постановка вопроса в теме предполагает, что баг проявляется только на частоте 72МГц?
А на частоте, например 60 МГц, всё хорошо?

Я так понимаю, что сама постановка вопроса говорит о том, что для того чтобы код перевести на частоту 60МГц, его надо полностью переписать. Естественно тогда баги могут и пропасть.

[manul78]

Добрый день !

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

А вопрос-то изначально был простой, но со сложными ответами. Попытка собрать в один список алгоритм действий для разработчика,
у которого нет дикого бюджета, из аппаратуры только пара хороших компов, ноутбук, ST-Link, J-Link, цифровой осциллограф и простой
недорогой логический анализатор. Устройство которое он делает не серийное, их может быть от силы пару штук, и оно заточено под
конкретные цели - штучный товар.


Дельные ответы изо всей "воды" здесь вылитой я всё-же получил:

1. Делать как минимум два экземпляра, дабы исключить глюки с железом из-за некачественной пайки, компонентов и пр. Также это пригодиться
в процессе отладки, когда один экземпляр работает "в поле" а с другим можно заниматься в лаборатории на столе.

2. Сразу-же вести записи и документацию. Эдакий "бортовой журнал". Всё записывать и документировать.

3. В процессе разработки сразу предусмотреть как минимум один порт и интерфейс (UART,SPI,I2C) для отладки. Если нет места и ног - брать
более функциональный чип из серии МК.

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

5. ......


Далее прошу продолжить участникам данной темы, если не лень конечно...

[adnega]

Далее прошу продолжить участникам данной темы, если не лень конечно...

5. В каждом устройстве иметь светодиод мигающий раз в секунду если все ок.
3`. В каждом устройстве иметь отладочную консоль UART.

[jcxz]

5. ......

Как я уже писал: во все программы на Cortex-M обязательно добавлять обработку fault-ов. Это часто существенно сокращает время поиска багов в проблемах с указателями, разрушением памяти, стеков и т.п.
Также - в обязательном порядке использовать MPU по-максимуму. А на более жирных камнях - MMU. Для защиты памяти и выявления несанкционированных доступов к регионам.
И если устройства единичные и бюджет на отладочные средства ограничен, то использовать более жирные МК, например имеющие поддержку ETB. Когда из-за разрушения чего-либо выполнение программы улетело по недопустимому адресу, то с обычным J-Link найти точку в прошлом где "свернули не туда" поможет только ETB.

[Сергей Борщ]

Всегда делаю отладочный вывод через свободный УАПП. В зависимости от #define включается более или менее подробный вывод (есть два класса debug и ndebug с одинаковыми интерфейсами):

CODE

#ifndef DEBUG_H__
#define DEBUG_H__
#include <ndebug.h>

#ifndef NDEBUG

#include <console.h>
extern console & Debug_console;
#define Debug_on Debug_console

#else
#define Debug_on Debug_off
#endif

#define Debug_CID Debug_on
#define Debug_panel Debug_on
#define Debug_panel_stream Debug_off
#define Debug_tcp Debug_off
#define Debug_lwip Debug_off
#define Debug_usb_irq Debug_off
#define Debug_usb Debug_off

#endif // DEBUG_H__

......
for(;;)
{
Debug_panel.timestamp();
Debug_panel.printf("%s panel selected\r\n", name(Panel_type));
switch(Panel_type)
{
default:
pPanel = new(&Memory_pool.Disabled) disabled_panel<input::SAMPLE_PERIOD>;
break;

Коллегам недавно понадобилось отлавливать редкий глюк в автомобильном устройстве, которое катается вместе с автомобилем и программиста-наблюдателя с ноутбуком держать круглосуточно в этом автомобиле оказалось невозможно. Сделали простейшее устройство, которое тупо весь поступаующий в его УАПП текст пишет на SD-карточку, предваряя каждую строку текста меткой времени (время считает встроенные в проц часы с батарейкой). Этот "накопитель" катается вместе с устройством, после возникновения ошибки из него извлекается SD-карточка и программист спокойно за чашечкой кофе анализирует все, что оно записало. Метки времени позволяют быстро отыскать нужное место в файле.

[AlexandrY]

3. ... Если нет места и ног - брать более функциональный чип из серии МК.

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

Отладочный вывод в UART плохой вариант, получив два образа, один отладочный, а другой релизный только добавите себе работы по поиску отличий если ошибка будет появляться только в одном из них.
Вывод лучше делать в RTT. Тогда он может оставаться в релизном варианте и не надо будет множить образы.

[ViKo]

Далее прошу продолжить участникам данной темы, если не лень конечно...

Систему контроля версий применять. Я пользуюсь TortoiseHg.

[-= Александр =-]

Систему контроля версий применять. Я пользуюсь TortoiseHg.

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

[AlexandrY]

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

Так это контроль истории, а не версий.
Контроль истории есть во всех продвинутых редакторах.

[HardEgor]

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

[AVI-crak]

Так это контроль истории, а не версий.
Контроль истории есть во всех продвинутых редакторах.

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

[AlexandrY]

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

RAD Studio, Android Studio, Sysmac Studio, IntelliJ IDEA....
Это только те с которыми я работаю прямо сейчас.

[Kabdim]

Да, в андроид студии такое есть...

[twix]

RAD Studio, Android Studio, Sysmac Studio, IntelliJ IDEA....
Это только те с которыми я работаю прямо сейчас.

Справедливости надо таки да сказать что Android Studio и Intellij IDEA это одна и та же среда

[AlexandrY]

Справедливости надо таки да сказать что Android Studio и Intellij IDEA это одна и та же среда

Если еще справедливей, то Android Studio идет со своими addon-ами для рефакторинга, а Intellij IDEA со своими.

[k155la3]

>> Назовите такой продвинутый редактор, в котором можно посмотреть состояние проекта неделю назад?

RAD Studio, Android Studio, Sysmac Studio, IntelliJ IDEA....
. . .

RAD Studio . . . редактор, а особенно броузер .... "не-дай-бог". Тупило и глюкало. Структура и состав контекстного меню - тоже
"оригинально" сделана. Явно не для отладки и чтения чужого кода.
IMHO.
Контроль версий - Git+Tortoise (вполне комфортно работать и без Tortoise - из командной строки).
Недостаток - нет сплошной номерации ревизий, как в SVN. На мой взгляд - единственный.
(не столько недостаток, сколько "шаг назад", чтобы сделать несколько вперед).

[AlexandrY]

>> Назовите такой продвинутый редактор, в котором можно посмотреть состояние проекта неделю назад?

RAD Studio . . . редактор, а особенно броузер .... "не-дай-бог". Тупило и глюкало. Структура и состав контекстного меню - тоже
"оригинально" сделана. Явно не для отладки и чтения чужого кода.

Так ставьте расширения GExprets, AQtime, CodeSite... и будет счастье. Все равно под десктоп ничего лучшего нет.

[k155la3]

. . . . а-а-а-а. В ЭТОМ смысле.

. . . .
Дельные ответы изо всей "воды" здесь вылитой я всё-же получил:
12345. . . .
5. ......
Далее прошу продолжить участникам данной темы, если не лень конечно...

5. Для поиска очень редких сбоев, полуаппаратный метод. В том числе в среде RTOS.
Используете лог. анализатор (онлайновый, с возможностью просмотра движущейся "ленты". У меня - встроенный в осц-ф, 16 каналов).
В критические участки кода (вектора прерываний, планировщик RTOS, флаги ошибок) ставите "ногодрыг". Если необходимо поймать комбинацию флагов, можно линии "ногодрыга" подключить на внешние схемы "И".
Развертка ставится самая медленная. Если в осц-фе есть память - это также можно использовать (но это "не про меня").
Далее писать алгоритм "отлова" нет смысла, все очень индивидуально.
Эта метода поможет "засечь" состояние первого сбоя, который в любом случае придется ловить вручную или наполовину вручную.
При появлении сбоя - жмем на осциллографе "Stop/Freeze" и не спеша рассматриваем предисторию вылета.

Так ставьте расширения GExprets, AQtime, CodeSite... и будет счастье. Все равно под десктоп ничего лучшего нет.

Спасибо за инф. Посмотрим что за звери.

[juvf]

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

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

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

[jcxz]

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

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

[AlexandrY]

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

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

[jcxz]

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

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

Так что "стресс-тест" это просто семантический плеоназм в данном случае.

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

[novikovfb]

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

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

[jcxz]

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

Вот именно.

[juvf]

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

Чтобы попадать в баг не раз в месяц, а раз в 1 минуту (или хотя бы раз в час, как можно чаще). Чем чаще бага проявляется, тем легче её найти.

Ошибка конечно проявится, но это будет не та ошибка!
А чтобы была та, нужно именно тот трафик смоделировать.

Согласен. Но как стоит условие задачи - "глюки начинают вылазить при оживленном траффике". Нужно на столе смоделировать оживленный трафик, а также стресс-тест. Если бы было в условии "глюки начинают вылазить при ОПРЕДЕЛЁННОМ оживленном траффике, а при другом оживленном трафике нет баги", то тут сложнее, тут да, лови и моделируй нужный трафик.

[AlexandrY]

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

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

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

[x893]

Это может означать, что плохо или спроектировано или реализовано, а может и то и другое.

[jcxz]

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

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

[AlexandrY]

например если у меня есть SPI-FLASH в устройстве, но обращение к ней идёт не часто, то для теста (обнаружения редко проявляющихся непериодических сбоев как у ТС), я нагружаю данный интерфейс транзакциями чтения/записи по самое нехочу.

Как то не верю.
Файловые системы и я тестирую. Не раз тут выкладывал результаты максимальной производительности.
И сколько же времени вы тестируете. Берете время c потолка? Какое количество файлов? А количество директорий? А количество одновременно открытых файлов?
И любой джуниор вам скажет что при достаточно долгом тесте файловой системы на Flash носителе у вас 100% случится сбой, так как есть такое явление как износ.
Чел более опытный намекнет, что у вас там со стеком и динамической памятью может быть нехватка и отказ в обслуживании.
Короче в любом случае получаете отказ. То что вы назовете это не отказом, а переходом в известное состояние (состояние аварии ) ничего не меняет.
Короче аргумент с FS не валидный.
Дайте че нить другое.

[jcxz]

Как то не верю.

Да конечно! Если Вы допускаете что в Ваших изделиях "даже могут возникнуть конструктивные повреждения" или оно может просто повиснуть просто из-за того что помеха проскочила по интерфейсу - понятно, что для вас являются фантастикой любые устройства которые не виснут.

Файловые системы и я тестирую. Не раз тут выкладывал результаты максимальной производительности.

Не понял..... а где я писал про "файловые системы"??
Пример я привёл для SPI-FLASH. Только как пример. В остальном - поступаю аналогично.
Что такое износ - знаю, и он тут как бы совсем не при чём (размер чипа ==128МБ, читайте характеристики современных SPI-FLASH).

И сколько же времени вы тестируете. Берете время c потолка?

"сколько времени" я вроде написал в своём посте.

Короче в любом случае получаете отказ.

Вы читать вообще умеете??? Запускал тесты на несколько часов, и не один раз - ни одного сбоя.

PS: То файловую систему какую-то увидели в моём сообщении, то динамическую память, то какие-то износы и отказы.... Вы мой пост-то прочитали? Поняли?

[AlexandrY]

Вы мой пост-то прочитали? Поняли?

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

Несколько часов на тестирование файловой системы...? Вы меня хотите рассмешить?
Я файловые системы тестирую неделями. Трачу на написание тестов кучу времени и все равно не знаю все их метрики и все их поведение.

За свои несколько часов вы узнаете только характеристики износа только одного конкретного чипа.
С другой стороны если у вас не файловая система, а несколько процедурок записи в физические сектора, то че там тестировать?

[KnightIgor]

50/50... Есть проект "маршрутизатор-переводчик" промышленный. По 485-му "мастер" разговаривает с 232-ми "слейвами".

Шота мне подсказывает, а не на 5V ли эти все внешние чипы работают? F103 хоть и якобы на многих ногах 5V "терпимый", но не верю я в эти маркетинговые сказки. Если 5V по пину рубит регулярно через диоды на его 3.x вольт, могут быть самые непредсказуемые результаты.

[juvf]

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

ППКС

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

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

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

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

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

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

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

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

ps

сработает WDT

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

[AlexandrY]

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

Спецы из NXP дискуссию с вами на этом и закончили бы. Потому как в i.MX RT уже четыре! WDT аппаратных реализовано.
WDT к вашему сведению абсолютно нужен для контроля риалтайма. Если вам не нужен значит вы просто не разрабатываете под риалтайм, т.е. вам пока что его просто не доверяют.

[haker_fox]

Эта штука как минимум не нужна, как максимум опасна.

Я тоже так раньше думал Но со временем пришёл к выводу, если она есть, то почему бы и не использовать? Ведь WDT не просто перезагрузит плату, он ещё и выставит флаги статуса в специальном регистре, что позволит залогировать это событие. А главное, устройство хоть и зависнет, но всё же продолжит работу спустя таймаут.

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

[juvf]

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

Кто и что мне чего то там доверяет или не доверяет? У вас это из темы в тему. Это вам кроме красной кнопки похоже чего-то не доверяют, вот вы и считаете, что кому-то что-то кто-то должен доверить.

Спецы из NXP дискуссию с вами на этом и закончили бы.

Как обычно - пустослов. Говорите за себя. А по теме ни чего не сказали..... хотя судя по вашим высказываниям про стрес-тест - с вам говорить дальше не о чем.

Ведь WDT не просто перезагрузит плату

готов подискутировать, но не в этой теме.

[haker_fox]

готов подискутировать, но не в этой теме.

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

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

Расскажите, пожалуйста, как вы тестируете ФС? И почему неделями? Какие тесты требуют такого длительного времени?

[Rst7]

Если 5V по пину рубит регулярно через диоды на его 3.x вольт, могут быть самые непредсказуемые результаты.

Шутите, какие защитные диоды? Там же по другому все сделано, совсем другая схемотехника этих выводов. Там нет защитных диодов в привычном для CMOS понимании в p-канальном плече.

[mantech]

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

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

[haker_fox]

Ну вот и зря.

Интересно, а в критических приложения (зависит жизнь человека) собака допускается (кроме резервирования системы)?

[mantech]

Интересно, а в критических приложения (зависит жизнь человека) собака допускается (кроме резервирования системы)?

Думаю, она там обязательно должна быть включена, как доп. элемент надежности системы.

[AlexandrY]

Расскажите, пожалуйста, как вы тестируете ФС? И почему неделями? Какие тесты требуют такого длительного времени?

В моем тулбоксе около 10 разных файловых систем.
Большинство я тестировал. Тесты охватывают основные сервисы файловой системы.
Но главное это степень детерминированности файловых операций.
Чтобы набрать надежную статистику на уровне 0.98 пары часов конечно недостаточно.
Причем тесты надо повторять при смене платформы, компилятора и даже опции оптимизации в компиляторе.
А еще же есть десятки параметров в самой файловой системе которые тоже надо все перебрать.

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

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

[mantech]

В моем тулбоксе около 10 разных файловых систем.

Это для коллекции или тут какой-то практический смысл, но что-то не могу придумать такового

[one_eight_seven]

Это для коллекции или тут какой-то практический смысл, но что-то не могу придумать такового

[haker_fox]

В моем тулбоксе около 10 разных файловых систем.
Большинство я тестировал. Тесты охватывают основные сервисы файловой системы.

Вы тестируете какими-то скриптами? Они выполняются на платформе конечного устройства, или на внешнем процессоре (например на ПК)? Если так, то как они получают доступ к ФС устройства?

[AlexandrY]

Вы тестируете какими-то скриптами? Они выполняются на платформе конечного устройства, или на внешнем процессоре (например на ПК)? Если так, то как они получают доступ к ФС устройства?

Вот один из примеров - https://geektimes.com/post/274416/

[mantech]

Вот один из примеров - https://geektimes.com/post/274416/

Это обычные тесты скорости, надежность и "безглючность" ФС не тестируется.

[AlexandrY]

Это обычные тесты скорости, надежность и "безглючность" ФС не тестируется.

Во! И это только тесты скорости.
А теперь покажте мне героя который еще добавит сюда еще тесты надежности и безглючности.

[mantech]

Во! И это только тесты скорости.
А теперь покажте мне героя который еще добавит сюда еще тесты надежности и безглючности.

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

[AlexandrY]

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

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

[mantech]

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

Причем тут сд-карты, проверялось, что будет, если внезапно удалить карту во время операций инита, чтения или записи. При первых проверках выяснилось, что драйвер зависает, ФС работает неадекватно, при посл. вставлении карты и пр... Температура - это как доп. испытание МК, карты и платы...
В подавляющем большинстве демок и проектов такое тестирование не проводится.

[AlexandrY]

Причем тут сд-карты, проверялось, что будет, если внезапно удалить карту во время операций инита, чтения или записи. При первых проверках выяснилось, что драйвер зависает, ФС работает неадекватно, при посл. вставлении карты и пр... Температура - это как доп. испытание МК, карты и платы...
В подавляющем большинстве демок и проектов такое тестирование не проводится.

Ну и при чем тут тестирование все таки?
Это обычная итерационная процедура разработки.
Файловая сложная, вы ее до конца конечно не изучили и методом тыка вот так добивались работы при извлечении карты.
Нормальный подход, сам так делаю.
Но это не то тестирование, которое тут воспевают.

[mantech]

Ну и при чем тут тестирование все таки?

Но это не то тестирование, которое тут воспевают.

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

[juvf]

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

какой ужас

[mantech]

какой ужас

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

[AlexandrY]

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

Нет это я бы назвал "перегрузочное" тестирование.
Т.е. тестирование чего угодно: там климатики, износа карты, каких то экстремальных механических вмешательств, даже может влияние ядерного взрыва,
но только не того что реально помогает выявить глубокие баги.

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

А теперь догадайтесь зачем все таки 4-е! WDT ставят, причем оконных.
За сбои питания отвечает не WDT, а brownout детектор.
А если вам нужно привлекать к этому WDT, то у вас точно не все в порядке с тестированием на программные зависания.

[haker_fox]

А теперь догадайтесь зачем все таки 4-е! WDT ставят, причем оконных.

А зачем? Я полагаю, что WDT это абсолютно независимый (ну кроме питания, одного корпуса) счётчик от процессора и его периферии. Который в любом случае сбросит процессор, если за время таймаута, не будет сброшен. Для повышения надёжности? Или каскадирования? Т.е. сработал 1-й пёс - предупреждение, второй - серьёзное предупреждение и т.п.? Или на каждое ядро свой пёс?

[AlexandrY]

А зачем? Я полагаю, что WDT это абсолютно независимый (ну кроме питания, одного корпуса) счётчик от процессора и его периферии. Который в любом случае сбросит процессор, если за время таймаута, не будет сброшен. Для повышения надёжности? Или каскадирования? Т.е. сработал 1-й пёс - предупреждение, второй - серьёзное предупреждение и т.п.? Или на каждое ядро свой пёс?

Так для контроля реалтайма. Не на ядро, а на задачу.

[mantech]

Так для контроля реалтайма. Не на ядро, а на задачу.

И каким образом сие работает?

[Kabdim]

А теперь догадайтесь зачем все таки 4-е! WDT ставят, причем оконных.

Даже залез в документацию. Докладываю. Один - обычный, второй - для трастзоны, третий- специальный, для реалтайм задач. А четвертый -... а четвертого нету (если конечно не считать за таковой таймер в квадратурном декодере, который умеет только прерывания).

[mantech]

третий- специальный, для реалтайм задач.

Вот про это мне и интересно, что он там может сделать, пересбросить конкретную задачу, или сбросить проц, если время выполнения этой задачи затянулось?

[Kabdim]

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

[haker_fox]

Так для контроля реалтайма. Не на ядро, а на задачу.

Надо ещё один добавить, для контроля за остальными WDT. для надёжности

[yuri_t]

Если говорить о fault tolerant системах (медицина, авиация)- только многоканальные системы могут обеспечить необходимую надежность.
Очень часто каждый канал делается на процессорах разных компаний и софт пишется разными группами разработчиков(по единой спецификации).
Что касается WDT - то он нужен, т.к. такая, например, вещь как обычное космическое излучение, может привести к зависанию даже очень хороший CPU.

[AlexandrY]

Если говорить о fault tolerant системах (медицина, авиация)- только многоканальные системы могут обеспечить необходимую надежность.
Очень часто каждый канал делается на процессорах разных компаний и софт пишется разными группами разработчиков(по единой спецификации).
Что касается WDT - то он нужен, т.к. такая, например, вещь как обычное космическое излучение, может привести к зависанию даже очень хороший CPU.

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

Я тут показывал Safety контроллер по требованиям SIL 3.
Он был сделан на 2-х абсолютно одинаковых STM32.

Даже залез в документацию. Докладываю. Один - обычный, второй - для трастзоны, третий- специальный, для реалтайм задач. А четвертый -... а четвертого нету (если конечно не считать за таковой таймер в квадратурном декодере, который умеет только прерывания).

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

[haker_fox]

Что касается WDT - то он нужен, т.к. такая, например, вещь как обычное космическое излучение, может привести к зависанию даже очень хороший CPU.

А если космическое излучение приведёт к зависанию очень хорошего WDT?

Смысла делать на разных процессорах не улавливаю.

Но системы авионики вроде так и делают. Разные процы, разные команды (в идеале не знающие друг друга), разные компиляторы, языки программирования, страны-производители, и т.д. и т.п.

Я тут показывал Safety контроллер по требованиям SIL 3.
Он был сделан на 2-х абсолютно одинаковых STM32.

Покажите ещё раз (дайте ссылку), пожалуйста, я не видел.

[yuri_t]

По поводу WDT - чтобы нарушить работу CPU, достаточно альфа-частице поменять любой бит в CPU register или CPU RAM, в WDT такое изменение просто поменяет значение счетчика WDT, что некритично(ну сработает раньше/позже, ну и что?)
Что касается дублирования в Fault Tolerant System - то это упрощенный частный случай. Посмотрите в Интернете, как, например, устроены
системы управления в Boeing 777 и Airbus A320.

[juvf]

в WDT такое изменение просто поменяет значение счетчика WDT, что некритично(ну сработает раньше/позже, ну и что?)

сработает раньше - перезапуститься полностью исправная система.