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

Теперь хочу высказать свои мысли по этому поводу. Одним из главных требований выдвигаемых к программному обеспечению (ПО) для встраиваемых систем, это – контроль и проверка правильного функционирования рабочего окружения программы. К этому набору относятся, касательно микроконтроллеров AVR, регистры общего назначения (РОН), оперативно запоминающее устройство (ОЗУ), регистр состояния выполнения программы (SREG), память хранящая код программы (FLASH) и устройства с которыми работает программа (USART, ADC, TWI и т.д.).
Так что в независимости от того хочешь ты этого или не хочешь, твоя программа помимо того что должна соответствовать требованиям выдвигаемым “техническим заданием”, дополнительно должна выполнять все требования предъявляемые к ПО для встраиваемых систем.

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

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

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

В серии есть сбои в работе мк. раньше основная проблема была с данными в EEPROM. Кто с AVR знаком давно тот знает об этой проблеме. Решение этой проблемы программным путем особых успехов не имело. Данные в EEPROM, это заводские предустановки (калибровка) и чтобы их восстановить нужно технологическое оборудование.
Стали писать во Flash. модифицировалась базовая прошивка под конкретный прибор. Проблемы с распрограммированием ушли.
Но есть и другие отказы мк: битые порты и хрен знает что. не можем мы в него заглянуть. Думаем CRC прошивки проверять и конфигурации.
А теоритически повреждение РОНов, и пр. памяти должны вызвать сбои в алгоритме и пес не будет сбрасоваться, а мк будет.
Вопрос интересный. Кто что скажет?

Приходилось сталкиваться, начиная с 8080.
Контроль РОН и АЛУ был прописан тщательно и ни разу не дал ошибку.
Мои убеждения по обычным приборам (не спец применения):
Имеет смысл только контроль внешних устройств.
Проверка внутреннего ОЗУ невозможна в случае необходимости сохранять его содержимое или быстрого восстановления после сброса.
Проверка внутренней памяти программ имеет мало смысла поскольку программа должна работать. Статистика очень хорошая по последним 10 годам. Контрольная сумма используется только при программировании бутлоадером.
Проверка EEPROM проводится с помощью контрольной суммы блоков информации в "пользовательcком приложении".
Прибор должен иметь светодиод ошибки/индикации шевеления.

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

МК достаточно сложное устройство и полноценная проверка его сделает алгоритм еще более сложным, а систему соответсвенно еще более ненадежной.
Поэтому лучшим выходом является не контроль элементов системы, а контроль ее общей работоспособности.
Для этого существуют три способа.
1. Контороль целостности критических данных - CRC etc.
2. Борьба с зависанием - ватчдоги внутренние и внешние
3. Борьба с запрещенными состояниями - всевозможные аппаратные взаимоблокировки исключающие выполнение противоречивых команд даже в случае полной неработоспособности микропроцессорного модуля.

я не вижу смысла проверять целостность внутренних блоков контроллера ( используем AVR)... кроме eeprom кажется, ничего не портится

поэтому у нас "внутренние" проверки нацелены в основном на проверку целостности eeprom ( совпадения контрольной суммы) и проверку источника сброса ( в основном для детектирования аварии по питанию)

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

Проверка работоспособности МК самим МК, работоспособность которого под сомнением, является прекрасным примером логического абсурда. Мало того, примитивные проверки типа 0х55-0хАА не выявят ровным счетом ничего. Если уж так хочется, то проверять нужно всю систему вместе с подключенными к ней устройствами - убедиться в целостности внешних интерфейсов, соответствия измеренных значений их областям допусков, корректности CRC/CS Flash/EEPROM. Тест, который проверит И ВЫЯВИТ некорректность функционирования ЛЮБОГО узла МК, можно попытаться написать и запускать в порядке входного контроля (отбраковки), а в рабочие системы уже ставить те МК, которые таковую отбраковку прошли, но это тоже малополезно. Грамотно и тщательно проведенное ВЫХОДНОЕ тестирование системы гораздо более эффективно, чем написание/проведение никому не нужных "академических" тестов голого МК

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

А вот у меня был реальный случай в ATMega8515 5 бит в регистре R12 (или R14 не помню точно). не всегда устанавливался в еденицу. а использовался этот регистр в прерывании там сохранялся указатель на очередь клавиатуры. Так вот глюк был совершенно смешной нажимаешь 16 раз на клавиатуре, а потом она сама еще 16 раз нажимает, и так далее...
Я запарился искать, потом когда в очередной раз поменял код все регистры сохранял в стеке и не использовал этот все работало. Написал простой тест регистров, так вот на всех платах кроме одной тест проходил.
Но такой контроллер мне попался один из нескольких тысяч.

Тоже очень больной вопрос....
У меня в одном проекте иммется тестирование сначала регистров потом озу.
кристалл м16
если косяк - зажигаю группу светодиодов
И что характерно....
наблюдал очень непонятный момент...
во первых... сколько не шил партий всегда все гладко запускалось
т.е тест проходил без ошибок
но тем не менее на одном из объектов произошел отказ
ну то се... вообщем взял конроллер на исследование..
действительно, наблюдал непрохождение теста, причем самое непонятное то, что при внешнем ресете проц запускался и работал какое то время без сбоев там 3-4 часа
потом чувствовался ватч дог или переполнение стека и проц шел на вектор ресета...
так вот...
если процу щелкнуть питанием то тест озу не проходил...
причем это наблюдалось в 100%
ну естествеено храню этот камень как дорогую реликвию - для опытов :-)
посему считаю что тест флеша и тест регистров и озу очень желеательным.

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

Добавлю свое замечание по этому вопросу.
Из опыта, ни разу не сталкивался с битым RAM или FLASH памятью AVR-ок. EEPROM, конечно, надо писать с контрольной суммой.
А вот "частично выбитые" электромагнитным импульсом (или статикой) входы мк - это было.
К примеру, лапка мк настроена на вход. Типовой (даташит) входящий ток - мка должен быть, однако в реалии - более 2 ма, чтобы ядро поняло, что на входе - лог "1". Это было следствие электростатического разряда на лапку.

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

Конечно, возможны "глюки" и со стороны производителя мк, когда при производстве "где-то что-то пролилось не туда" или маленькая пылинка сделала свое дело.....
Но вспомним Фуджики винчестеры серии MPG320 - когда из-за активного флюса (или промывки) жидкость через выводы проникла к кристаллу и начала его разъедать.... Миллионы винтов сдохли...

Поэтому надежность - это комплексное понятие, простым тестом не отследишь...

Любой чужой опыт, хм, дополняет мои представления.

Но такой аспект. На полупроводники сильно влияют окружающие условия. У нас на заводике все приборы тестируются в предельных рабочих режимах по температуре и напряжению. Мне кажется это гораздо важнее и эффективнее, чем прогон простейшего теста компонентов при наладке.
Вы спросите - а как же диагностика и поиск неисправности?
Отвечу. Был такой опыт на заре микроконтроллерных устройств - отдали в производство прибор, с идеальной, как казалось, диагностикой - на каждом модуле был светодиодик, который гасился только в случае успешного прохождения теста этого модуля. Оказалось, что жизнь богаче, что эта классная диагностика может давать ложные ошибки, и пропускать реальные. А обыкновенный наладчик без образования находит причину отказа проще, не вдаваясь в высшие материи.

Поэтому вопрос о цене вопроса (сорри за каламбур). Ну, отказал контроллер, ну выкинули его, дальше работаем. В приведенном случае он отказал уже у клиента. И какая разница, что показала диагностика. Отказ то произошел.

НЕВЕРЮ! Ну хоть убейте не верю.

У вас выбит один бит в регистре и при этом у Вас только кнопка не работает?!!!!!!! Это чтож за программа у Вас была такая?

Если писать на ASMе и при этом программа байт 500, то тогда ещё такое возможно. Но в реальном проекте данный камень бы просто не работал! Это совершенно очевидно.



Хотелось бы услышать zltigo. Вот Вы в каждое изделие вставляете тест памяти. Сколько у вас было случаев неисправности ОЗУ? Сколько у Вас было случаев неисправности озу, при котором изделие работало, но скажем сбоило?

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



На мой взгляд, о чём я и писал в предыдущей ветке, вопрос не только в возможности, но и в целесообразности! Можно всё! Но, на мой взгляд нецелесообразно. Потому, что я, кпримеру, не возьмусь за написание такой программы, которая со 100% вероятностью при неисправности озу или регистров не выполнит ЛЮБОЕ ДЕЙСТВИЕ.

Если же мы вернёмся к IBM, то думаю zltigo Вам подтвердит, что там сначала проверяется маленький участок озу и только потом запускается дальнейшее тестирование! Если привести это грубо к какому-то знаменателю, то они не гарантируют прохождение теста если не работает маленький кусочек ОЗУ и процессор в начальный момент. Работоспособность регистров должна быть обязательно. Иначе последствия непредсказуемы. Существуют у нек. МП немаскируемые вектора по ошибочной команде, тогда в принципе возможно создать систему с защитой от таких ошибок. Но это к AVR не относится.

Долго думал участвовать в обсуждении или не участвовать...
Все-таки не удержался и решил поучаствовать

Дело в том что я достаточно много времени занимался тестированием и ремонтом
памяти для PC, по этому вопросы и проблемы поднятые в этом топике мне близки и понятны...

Попробую высказаться только по сути:
- тестировать полезно (но не всегда необходимо)
- для простых тестов типа 0X55, 0xAA мы можем получить только информацию о том
что какая-то линия данных как-то не так подключена к процессору(типа иногда сбоит,
ну или что чаще бывает на модулях памяти это банальный непропай или неправильные
подтягивающие резисторы)
- для исключения ошибок по адресным линиям нужно прописывать в память
адрес тестируемой ячейки и потом сравнивать его при чтении
- для более подробного тестирования необходимо над каждой ячейкой памяти делать
сдвиговые операции
- для еще более подробного тестирования нужно прописывать блок памяти некоторыми данными,
потом производить сдвиговые операции над всем блоком памяти а затем проверять результат

- а самый простой вариант это просто прописывать некоторые данные с заранее просчитанным
CRC16/32 а затем их просто считывать и проверять CRC (в CRC сдвигов вполне хватает)

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