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

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

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

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

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


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

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

Вот именно.

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

какой ужас

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

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


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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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