RAM, ROM & MCU tests in embedded applications

Привет!

Fri Mar 11 2005 09:32, Rifkat Abdulin wrote to Alexander Golov:

RA>>> У меня есть статистика по 876-877м пикам - по 200-300 шт в устройствах. RA>>> ПЗУ не крошилась. EEPROM крошилась в 877х - при исследованиях RA>>> выяснилось, что падали начальные ячейки EEPROM при сильных помехах по RA>>> первичке 220В - работала болгарка. Хотя были и керамические емкости, и RA>>> кренки, и дросселя, и супервизоры питания. В этих же условиях EEPROM в RA>>> 876х не крошилась.

AG>> Традиционно у Microchip кристалл в 28- и 40-выводных МК один и тот же. AG>> Так что твои 876 и 877 это в сущности один и тот же МК.

RA> Статистика - вещь сильная, однако. Может - играла роль длина RA> проводников от чипа к пинам?

Например, ты заявил, что имел такую вот проблему с PIC16F876, люди прочитали и подумали: "А вот однако не очень надёжный этот МК 876-й, нужно его избегать". А потом, скажем, через некоторое время всплывает, что в таких же эксплуатационных условиях (но очевидно в несколько ином устройстве) у PIC16F877 проблем нет. Все сделали вывод -- 877-й устойчивее 876-го. А позже нам становится известно, что 877-й и 876-й это один и тот же МК, в разных корпусах. Ну и что показала эта твоя статистика? По-моему то, что проблемы в каких-то других узлах устройства.

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

Александр Голов, Москва, snipped-for-privacy@mail.ru

Привет!

Fri Mar 11 2005 04:31, Maxim Polyanskiy wrote to Alexander Golov:

...

AG>> Традиционно у Microchip кристалл в 28- и 40-выводных МК один и тот же.

MP> Типа и device id и revision number один и тот-же...

И портов столько же...

AG>> Так что твои 876 и 877 это в сущности один и тот же МК.

MP> А в реальности - разные.

Честное слово, мне лень заниматься растворением пластмассового корпуса, чтобы убеждать тебя в этом натурно. В старых с окном всё было на поверхности: кристаллы как две капли воды и неиспользованные площадки у 28-выводных -- налицо. Какую-нибудь перемычку удаляют перед приёмкой и вот уже и лишние порты не отзываются и id поменялся...

Александр Голов, Москва, snipped-for-privacy@mail.ru

DO> Hello, Dmitry Kuznetsov ! DO> DO>>>> В каких-то случаях это допустимо, в каких-то лучше ничего не DO>>>> делать, чем делать не пойми что. DO>>>

DO>>> Если у тебя слетел флеш программ, да не весь, а какие-то биты, у тебя DO>>> нет возможности контролировать что делает твоя программа, так как DO>>> делать не то она может начать сразу вместо процесса самопроверки. DO> DO>> Вероятность "сразу вместо" можно сделать намного меньше 100%...

DO> Hу если вероятность слета 100%,

А это ты уже сам придумал... от страха пролета мимо самоконтроля...

DO> менять надо что-то в консерватории.

DO> > Если же произойдет вылет из тестирующего кода, то должен сработать DO> > вотчдог (лучше внешний). Есстно, не 100%, но вероятность высока... DO> DO> Вопрос ее оценки достаточно неочевиден.

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

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

DO> Может это повышает вероятность правильной работы, а может и нет

Меня интересует не повышение вероятности правильной работы, которая в какой-то мере скорее снизится, а снижение вероятности неправильной работы. Просто существует класс задач, где это очень существенно. Для промоборудования допустима (дешевле) контролирумая остановка производства, чем незамеченный вовремя бесконтрольный перевод сырья в брак (дороже).

DO>> Естественно, если в конкретном случае высокая надежность важна... DO>> Впрочем, в таких случаях можно исскуственно завысить долю тестов. DO> DO> Думаю, что в таких случаях надо не долю тестов завышать, DO> а железо дублировать.

1) Это еще один класс задач с более дорогими решениями. 2) С каких пор системы с дублированием стали работать без диагностики? Отказавшие части уже не надо заменять?

<< Поцелуй мой *б*л*е*с*т*я*щ*и*й* зад... << ... (c) Bender [8E] Dmitry Kuznetsov, Moscow,

Беговая Черепаха] [Team LEXX]

*

AT> DK> Есть много реальных задач, где требуется относительно редкая, но очень AT> DK> быстрая реакция на события. Приходиться ставить более производительный AT> DK> процессор, который на основную задачу тратит лишь малую часть от своей AT> DK> полной производительности. AT> AT> Как только зашла речь о фоново самопроверке, - я сразу вспомнил незебвенной AT> памяти Электронику HЦ-31.

AT> Да, о чем это я? Так вот в приснопамятной HЦ-31, вся основная программа сидела AT> в этом прерывании, а в фоне - гонялся тест, весьма крутой (подробности, увы, AT> 20-летней давности, я помню не все). AT> Особенно мне нравилоь, что она гоняла и тест ОЗУ тоже.

AT> И вот все это супервоенное чудо, с Хемингом в ОЗУ, с фоновой проверкой, и AT> прочия прочия прочия, было самым большим кошмаром, из всех стоек ЧПУ, что были AT> у нас. Даже Бош со своим 8-битным Z80 в главной стойке, и 16-битной NOVA в AT> программоконтроллере - с ней не мог сравнится, разве что Э-60 в одесской AT> сверлилке, с заводским номером "2".....

1) Сравнение продукции стран с различными пол.-экон. системами. 2) Сравнение устройств разных поколений развития эл. техники. Объективно уж на пол-поколения разницы явно. 3) Уверен, что в боше и в нове не было самоконтроля ???

Я тоже в разной мере знаком по крайней мере с 4-мя типами "чудес":

1) ПК серии "микродат" (киев). Я не помню, чтоб с этим чудом что-нибудь работало у нас, но слухи разные были. Hаши эксперименты имели отрицательный результат. Повисало от каждого чиха... Корзина с модулями ходила буквально ходуном. Очень сырая была поделка... Впрочем, на нем даже малость заработали. Модифицировали ПО егойного программатора для вывода РКС на принтер и продали через HТТМ паре заводов, у которых тоже дальше экспериментов вряд ли продвинулось, но надеюсь, что с наши усовершенствованием они это раньше поняли ;) 2) ПК фирмы "фэсто" (австрия). Проблем не было, кроме дороговизны в инвалютных рублях и министерским распределением... 3) ПК серии "ПРОКОН" (болгария) - это было основным приложением моих рук и ума. Вполне работоспособная техника. Хоть и не такая крутая и разнообразная, как "фесто". 4) ЧПУ (питер) 2С42 чтоли (в цифрах могу соврать) на базе Э-60. Управляла фигурным фрезерованием на поверхности каких-то дверей. Периодически останавливалась, но двери портила редко.

Во всем перечисленном присутствовала встроенная диагностика.

Пока! << А что-нибудь разве русское обычное бывает? << Я что-то не понимаю... (c) БАБ Dmitry Kuznetsov, Moscow,

Беговая Черепаха] [Team LEXX]

*

AT>AT>> Да, о чем это я? Так вот в приснопамятной HЦ-31, вся основная AT>AT>> программа сидела в этом прерывании, а в фоне - гонялся тест, весьма AT>AT>> крутой (подробности, увы, 20-летней давности, я помню не AT>AT>> все). Особенно мне нравилоь, что она гоняла и тест ОЗУ тоже.

AT>AT>> И вот все это супервоенное чудо, с Хемингом в ОЗУ, с фоновой AT>AT>> проверкой, и прочия прочия прочия, было самым большим кошмаром, из AT>AT>> всех стоек ЧПУ, что были у нас. Даже Бош со своим 8-битным Z80 в AT>AT>> главной стойке, и 16-битной NOVA в программоконтроллере - с ней не AT>AT>> мог сравнится, разве что Э-60 в одесской сверлилке, с заводским AT>AT>> номером "2".....

AT>DK> 1) Сравнение продукции стран с различными пол.-экон. системами. AT> Я вовсе не собирался сравнивать продукцию разных стран, иначе сравнил бы HЦ31 AT> с Алан Бредли и Фануком, я говорил лишь то, что при наличии ОЗУ с Хеммингом, и AT> фонового теста в самом компьютере - проблемы с этими компами были по нескольку AT> раз в день....

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

Сов. электроника обычно была сырой, потому как в межведомственных отношениях, регулируемых сверху, основной задачей было отделаться от очередных инициатив. В середине 80-х был такой лозунг под оригинальным названием "электронизация", типа, если хоть 5 реле есть, то вместо них должна стоять электронная дурка.

AT> Э-60 во фрезерных, токарных и обрабатывающих центрах - работала при этом на AT> порядок лучше.

Это и я отметил при упоминании ЧПУ, но она именно останавливалась по сбою, а не превращала фрезу в таран. И требовала перезапуска со всеми прелестями перфосчитывателя и после этого ручной коррекции нескольких регистров.

AT>DK> 2) Сравнение устройств разных поколений развития эл. техники. AT>DK> Объективно уж на пол-поколения разницы явно. AT> Да, Hова наверное на поколение отстала от Э60 и HЦ31, а уж Z80....

Я имел в виду, что Z80, 6800, 6502 уж явно на шаг впереди многокристальных (иногда секционированых) наборов типа 581 (Э-60), 588 (НЦ-31) или 580ВМ80 с его тремя питания и высоковольным (12В) ядром. В общем, того что иногда перепадало пром. автоматике после оборонки и самопотребления самого МЭПа. AT>DK> 3) Уверен, что в боше и в нове не было самоконтроля ???

AT> Дак дело-то вовсе не в этом...

Тогда про НЦ-31 буду считать лирическим отступлением...

Пока! << А что-нибудь разве русское обычное бывает? << Я что-то не понимаю... (c) БАБ Dmitry Kuznetsov, Moscow,

Беговая Черепаха] [Team LEXX]

*

DO> Hello, Dmitry Kuznetsov ! DO> DO>>>>> Если у тебя слетел флеш программ, да не весь, а какие-то биты, у тебя DO>>>>> нет возможности контролировать что делает твоя программа, так как DO>>>>> делать не то она может начать сразу вместо процесса самопроверки. DO>>>> Вероятность "сразу вместо" можно сделать намного меньше 100%... DO>>> Hу если вероятность слета 100%, DO>> А это ты уже сам придумал... от страха пролета мимо самоконтроля... DO> Чего?

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

DO>>> менять надо что-то в консерватории. DO> DO>>>> Если же произойдет вылет из тестирующего кода, то должен сработать DO>>>> вотчдог (лучше внешний). Есстно, не 100%, но вероятность высока... DO> DO>>> Вопрос ее оценки достаточно неочевиден. DO> DO>> Для меня очевидно, что контрольная задача имеет однозначное поведение, DO>> а поведение рабочей задачи часто лежит в довольно широком диапазоне, DO>> и из этого также очевидна большая вероятность обнаружения отклонения DO>> в поведении при решении контрольной задачи. DO>> И я не зря ранее упомянул внешний вотчдог. Если ты ненароком подумал, DO>> что я предлагаю использовать его для перезапуска, то явно не угадал... DO> DO> Я вообще ничего не предполагал. Ты говоришь о каком-то весьма частном случае, в DO> котором, возможно твой подход и улучшает ситуацию (хотя мне это по-прежнему не DO> очевидно).

Да все случаи частные. Единый подход не всегда правилен.

DO>> Любая оценка приблизительна. Я абсолютно уверен, что если процессор DO>> работает неправильно, но его работа как-то похожа на нормальную, то DO>> сбойное место локализовано.

DO> Hичего не понял. Какое сбойное место и как локализовано?

От бита в ЗУ до зависшего внешнего контроллера... DO>>> Может это повышает вероятность правильной работы, а может и нет DO> DO>> Меня интересует не повышение вероятности правильной работы, DO>> которая в какой-то мере скорее снизится, а снижение вероятности DO>> неправильной работы. Просто существует класс задач, где это очень DO>> существенно. DO> DO> Если это _очень_ существенно, то и решаться должно соответственно. DO> Обычно это дублирование (мажоритирование) и/или различные внешние DO> блокировки неправильных комбинаций сигналов.

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

И часто пром. автоматика дублирована ??? Обычно просто останавливается. Еще может включить сигнализацию. Кто-то в то время (15-20 лет назад) нахваливал какой-то Фанук вроде, с несколькими процессорными модулями, типа он мог исключать из работы отказавшие процессоры, правда не интересовался как там устроено. Впрочем, наверняка по результатам контроля, как перекрестного, так и самоконтроля. Обычно же все в 1 экземпляре, как то, что упоминается в переписке с Торресом.

DO>> 1) Это еще один класс задач с более дорогими решениями. DO> Это еще один класс решений той же задачи.

Как-то раз для котла ставили такое решение с двумя PLC, но вышло дороже не вдвое, а втрое, так как и на перекрестный контроль число модулей разрослось еще раза в полтора... А обычно мы ограничивались контролем срабатывания выходов по силовой части, поскольку чаще там реле и пускатели отказывали. Входных модулей добавлялось, но по накопленному опыту (далеко не только моему) это себя оправдывало. DO>> 2) С каких пор системы с дублированием стали работать без DO>> диагностики? Отказавшие части уже не надо заменять?

DO> Кто сказал, что без диагностики? А что делать с отказавшими DO> частями - сильно зависит от задачи. Иногда да, не нужно.

Если это спутник или имплантант.

ЗЫ: вот опять таки если судить по ТЗ с которыми приходилось сталкиваться, про дублирование-резервирование нигде ничего, а про необходимость самодиагностики - почти всегда.

<< Поцелуй мой *б*л*е*с*т*я*щ*и*й* зад... << ... (c) Bender [8E] Dmitry Kuznetsov, Moscow, Беговая Черепаха] [Team LEXX] *