Цитата(juvf @ May 8 2018, 18:36) 
сработает раньше - перезапуститься полностью исправная система.
Но она не зависнет
Полная версия этой страницы: Как поимать "баг" в STM32 на скорости 72 MHz?
Но она не зависнет
QUOTE (yuri_t @ May 8 2018, 23:31)
просто поменяет значение счетчика WDT, что некритично(ну сработает раньше/позже, ну и что?)
Эта частица также может поменять и бит включения в регистре управления WDT
Цитата(haker_fox @ May 10 2018, 05:29)
Эта частица также может поменять и бит включения в регистре управления WDT
Т.е. отключит сторожевой таймер? И как этот одиночный сбой повлияет на работоспособность системы? А чтобы словить пару таких частиц на кристалл в космосе, надо ждать недели в худшем случае.
К тому же, для критичных применений есть процессоры с троированием регистров (и мажоритарным парированием ошибок) и защитой памяти кодами Хемминга или просто четности (если содержимое памяти легко восстановить).
QUOTE (yuri_t @ May 8 2018, 23:31)
Посмотрите в Интернете, как, например, устроены
системы управления в Boeing 777 и Airbus A320.
системы управления в Boeing 777 и Airbus A320.
Вы бы не могли поделиться ссылками. Я, конечно, нашёл кое-что, но вдруг ваш материал будет более информативен. Т.к. тема для меня в целом очень интересная.
QUOTE (novikovfb @ May 10 2018, 12:20)
И как этот одиночный сбой повлияет на работоспособность системы?
Никак. Вы просто лишитесь сторожевого таймера. И уже не надо ждать неделю частицы. Достаточно произойти более вероятной ошибке (например в ПО, либо в железе). И тут мы приплывём.
QUOTE (novikovfb @ May 10 2018, 12:20)
К тому же, для критичных применений есть процессоры с троированием регистров (и мажоритарным парированием ошибок) и защитой памяти кодами Хемминга или просто четности (если содержимое памяти легко восстановить).
Это очевидно, более того можно резервировать блоки управления.
Вообще, тема про частицу довольно обособленная, т.к. вероятность такого события крайне низка (имхо).
Цитата(haker_fox @ May 10 2018, 07:28)
Никак. Вы просто лишитесь сторожевого таймера. И уже не надо ждать неделю частицы. Достаточно произойти более вероятной ошибке (например в ПО, либо в железе). И тут мы приплывём.
В таких случаях надо ставить внешний WDT
QUOTE (sidy @ May 10 2018, 13:29)
В таких случаях надо ставить внешний WDT
Посмотрел бегло микросхемы внешних псов, да, должно работать, т.к. отключить их невозможно.
Дизайн WDT должен отвечать (как минимум) следущим трбованиям
- Иметь независимый от CPU генератор
- Не иметь run-time точек конфигурации (как, например PIC WDT)
Этим требованиям НЕ отвечают 99% встроенных в CPU WDT;
Fault tolerant: 2 документа обзорного типа attached
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
- Иметь независимый от CPU генератор
- Не иметь run-time точек конфигурации (как, например PIC WDT)
Этим требованиям НЕ отвечают 99% встроенных в CPU WDT;
Fault tolerant: 2 документа обзорного типа attached
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
QUOTE (yuri_t @ May 10 2018, 17:34)
Fault tolerant: 2 документа обзорного типа attached
О! Спасибо! Почитаем!!!
Цитата(manul78 @ Apr 24 2018, 14:55)
50/50... 
Есть проект "маршрутизатор-переводчик" промышленный. По 485-му "мастер" разговаривает с 232-ми "слейвами". Протоколы разные.
они известны, но изменить их нельзя. Данный девайс получает пакеты, переводит их в нужный формат и отдаёт "слейвам", получает от них ответ, опять переводит в другой протокол и отправляет "мастеру".
Вот такая штука из "говна и палок", работает... Но с глюками. Спонтанными. Может долго работать без сбоев. Но иногда частит. Суть в том, что глюки начинают вылазить при оживленном траффике по сети, если запросов-ответов мало может неделями работать без проблем.
Есть проект "маршрутизатор-переводчик" промышленный. По 485-му "мастер" разговаривает с 232-ми "слейвами". Протоколы разные.они известны, но изменить их нельзя. Данный девайс получает пакеты, переводит их в нужный формат и отдаёт "слейвам", получает от них ответ, опять переводит в другой протокол и отправляет "мастеру".
Вот такая штука из "говна и палок", работает... Но с глюками. Спонтанными. Может долго работать без сбоев. Но иногда частит. Суть в том, что глюки начинают вылазить при оживленном траффике по сети, если запросов-ответов мало может неделями работать без проблем.
Это вообще не проблема, и решается очень "плоско и дубово": система обвешивается логическими анализаторами, которые пишут канал связи и некоторые тестовые пины. Для отладки еще полезно завести специальный канал для сигнализации ошибки, и по нему разбираться в гигабайтах логов.
Я такое делал на системах до полсотни устройств с непонятными глюками по связи, применял наверное до десятка 8-канальных китайских анализаторов в параллель (именно сигналы отслеживать, а не данные!). Все писалось на комп сутками. Ничего сложного в разборках, обычная рутина.
Однажды в систему, которую физически нельзя отлаживать на столе, просто встроили такой логический анализатор и снабдили ноутбуком в качестве регистратора на время отладки. Просто пришлось специально разрабатывать железо, инструкции, оснастку и прочее.
Логический анализатор- это "абсолютное оружие" при отладке.
Обычно больше сложности в правильном планировании таких эксперимента, чем в разборке результатов.
Цитата(manul78 @ Apr 24 2018, 14:58)
Девайс работает на отшибе на территории завода. К нему лишний раз не набегаешься, и лабораторию измерительную не соорудить вокруг.
Ну это вообще тепличные условия.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.