Тестирование работоспособности контроллера

[niXto]

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

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

[testerplus]

Если в рабочем режиме жизненного цикла устройства у контроллера возможны "электромиграция, инжекция горячих носителей в диэлектрик, температурные деформации, брак производства, утечка заряда" - его применять категорически НЕЛЬЗЯ!!! Нужно применять те, у которых такое невозможно, если таковых не существует - делать на жесткой логике.

Да, таких не существует. А у жесткой логики довольно ограниченное применение (габариты все-таки, да и остальное). Всем неприятностям подвержен любой МК. Сейчас на сахаре обсуждают новинку от Атмеля: не только радиационная стойкость, но даже аппаратное троирование всех модулей. Но такие монстры не для бытовухи (Сам с подобными МК пока дел не имел).

Но, собственно, дело не столько в стойкости МК, сколько в способностях разработчика учесть то, что Вы сказали. Российские программисты в этом деле очень уперты и слышать ничего не хотят про такие вещи, как, например, залипание (stuck-at fault).

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

В большинстве случаев чаще и не надо. (Кстати, почему Вы не взяли другое семейство МК, где потеря памяти невозможна? ).

В обычных применениях проверки - лишние понты.

Чьи понты-то? И перед кем? Никто этого и не заметит, т.к. все эти защиты работают скрыто, а большинство ошибок исправляют на лету.

[testerplus]

2 kudryvzev99: со сторожевым таймером все не так просто. Он, конечно, будет ресетить МК, но толку от этого не будет никакого (разве что наглухо не даст зависнуть).

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

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

Ну и напоследок: WDT - не панацея, т.к. в своем составе также имеет генератор (который может сбойнуть), триггеры, которые могут изменить состояние и все такое прочее. Во многих случаях предпочтение следует отдавать внешним специализированным микросхемам WDT (их многие производят), т.к. они выполнены по более грубой технологии и менее подвержены внешним воздействиям.

[niXto]

(Кстати, почему Вы не взяли другое семейство МК, где потеря памяти невозможна?)

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

А переходить на масочные чипы (где потеря памяти невозможна) мне ещё рано)))

В обычных применениях проверки - лишние понты.
Чьи понты-то? И перед кем?

Нужно много лет изучать особенности чипа, чтобы знать Где и Как нужно поставить ловушку. А если с наскоку - методом тыка ("мне кажется..."), то смысла от такой проверки ноль. В конце концов неправильная подпрограмма обработки модуля I2C (если в проводах интерфейса гуляют косяки) мега48 подвесит чип так что только ресет спасет... А у мега8 старых ревизий (где-то до 2007 года) этот модуль в режиме слэйв вообще могли запустить только истинные гуру

[testerplus]

Нужно много лет изучать особенности чипа, чтобы знать Где и Как нужно поставить ловушку.

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

[you_go]

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

К сожаленью, жизнь заставила - кому же было бы охота зазря огород городить? Не только флеш, но и епром и даже срам, бывает, сбойнет. Представьте себе, стони контроллеров, работающие практически без выключения по нескольку лет подряд в разных городах на территории постсоветского пространства и в совершенно разных помеховых условиях - и несмотря на аппаратную защиту (полные оптические развязки входных и выходных цепей и всевозможные защиты и супервизоры по питанию), раз в несколько месяцев кое-где случались сбои данных. Как в этом случае искать причину? Ведь, в 99,9% случаев все работало нормально, а требовалось все 100%. Вот тогда и пришла мысль резервировать и защищать данные в памяти, а их изменения производить транзакциями, чтобы всегда оставалась "нетронутая" копия. Только так в результате удалось сделать бессбойную систему. От случайных сбоев (тем более таких редких), пожалуй, никак больше не избавиться. Кстати, недаром, к примеру, Атмеловская продукция не сертифицирована для применения в системах жизнеобеспечения.

[der_student]

А у мега8 старых ревизий (где-то до 2007 года) этот модуль в режиме слэйв вообще могли запустить только истинные гуру

Позвольте не согласиться. У меня в дипломной работе (2005г.) мега8 контролировала клавиатуру. Данные мега выдавала другому мк (какая-то мега, не помню) по TWI. К гуру выпускника ну никак не причислишь

[vlpasha]

скептикам и "умникам" с прямыми руками и прочим посвящается:

представьте на минуточку ситуацию - контроллер управляет синхронным двигателем мощностью 10-12 МВт. Двигатель крутит компрессор от которого запитан металлургический комбинат и его техпроцессы. Контроллер отлажен, и за 5 лет работы глюков и проблем с ним не было. В машзале электрики в один прекрасный день ставят рядом с контроллером панель, с десятком контакторов и реле 380В, 220В и т.д на разные токи, от 10 до 400А. Которые начинают весело и часто клацать. Контроллер в итоге как-то ночью зависает так, что часть прерываний продолжают крутиться как и раньше, часть разваливается, внутренний вачдог контроллер не сбрасывает, на сигнал сброса он тоже не реагирует (такие ситуации наблюдал лично, контроллер оживал только после полного снятия и повторной подачи питания). Регуляторы разваливаются, двигатель вываливается из нормального режима работы, сигнализации о неисправности система не дает, так как находится в одном ей известном состоянии. В итоге - крупная авария с отключением оборудования по релейным защитам (это в лучшем случае), нарушение техпроцесса комбината и соответственно исходящие из этого всего убытки. В худшем случае, кроме всего перечисленного еще и выход из строя двигателя ценой в несколько сотен тысяч долларов. А дальше
комиссии, проверки, суды, и прочее-прочее-прочее.

Интересно "грамотная" разводка платы, "правильные" программы или "правильный" контроллер дали бы Вам 100% уверенность того, что контроллер не зависнет никогда? Или все таки, имея возможность, лучше дополнить схему контролем работоспособности, пусть косвенным и не гарантированным, но в 1-2% случаев эффективным?

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

[st_1]

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

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

Защёлкнулся МК... Причины??? Неграмотная разводка, неграмотная схемотехника... И может быть... попытка сэкономить...

Интересно "грамотная" разводка платы, "правильные" программы или "правильный" контроллер дали бы Вам 100% уверенность того, что контроллер не зависнет никогда?

100% никто не даст... но если делать изначально правильно, то 99,9999% получить можно...

Или все таки, имея возможность, лучше дополнить схему контролем работоспособности, пусть косвенным и не гарантированным, но в 1-2% случаев эффективным?

"Поздно пить Боржоми..."...
О надёжности и возможных последствиях нужно было думать сразу... И никто не говорит, что внешний контроль не нужен никогда... Только... и постоянный ресет девайса из-за ошибок разработки есть не айс...

[vlpasha]

Защёлкнулся МК... Причины??? Неграмотная разводка, неграмотная схемотехника... И может быть... попытка сэкономить...

возможно великий "гуру" в состоянии предсказать все нештатные ситуации и помехи, которые могут возникнуть на объекте эксплуатации за 25 лет непрерывного использования оборудования, повторить эти помехи в лабораторных условиях и устранить причины возникновения раз и навсегда?
и потом после аварии сказать заказчику, что

99,9999% получить можно...

но вот ваш случай попал как раз в 0,00001%...ну так получилось...

"Поздно пить Боржоми..."...
О надёжности и возможных последствиях нужно было думать сразу... И никто не говорит, что внешний контроль не нужен никогда... Только... и постоянный ресет девайса из-за ошибок разработки есть не айс...

предложите более правильный вариант. вроде в теме это и просят сделать.