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

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

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

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

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

Беру свои слова обратно. Проверил. Действительно в мелких проектах r12 почему-то не задействован под IAR.

А вот ещё какой вопрос возникает.
Все предложенные способы тестирования памяти и регистров не проверяют изменение данных со временем. Если через несколько секунд (или миллисекунд) информация изменится, то быстро пролетающие тесты ошибок не обнаружат. В конце 80-х годов мы разрабатывали промышленные контроллеры на КР580, и встретилась фантастическая неисправность процессора - регистр "Е" терял данные через несколько секунд. Если оператор вводил данные с кнопок быстро, то всё было ОК, а если задумывался, то в память записывались нули. А остальные функции прибор выполнял безукоризненно. Так как КР580 выполнен на динамических регистрах, то видимо были проблемы с их регенерацией. Контороллеры AVR вроде-бы статические, хотя где-то я читал что это не совсем так, МК плохо работали на очень низких частотах.
В нашем контексте, IMHO, необходимо осуществлять очень тщательную проверку МК и системы после изготовления, причём проверять ещё и сохранность информации во времени. А в готовом изделии тесты могут быть и простыми.

интересно, это как ?

Очень просто. Статические регистры выполнены на обычных триггерах, а динамические на конденсаторах, примерно так-же, как и RAM. Этим, кстати, и объясняется минимальная тактовая частота процессора КР580ИК80А - 500 КГц. Об этом я читал в старом журнале по электронике.

2Nanobyte

Незнаю как РОН ,но SRAM в AVR указано явно хотя КР580ИК80А для меня загадка природы

2all

Теперь насчет целесообразности
Вот у меня такое неподобство - за день трижды слетела прошивка EEPROM в AVR,ну вот и какой толк от этого тестирования ?
Лично для меня ответ только один - если в нем хранятся ответственные данные , изменение которых может привести к физической поломке МК ,периферии или механического устройства которым управляет МК и т.д., но в любом случае или мы вынуждены устройство останавливать ,весело могая лямпочкой или оно само по себе уйдет в ступор- ситуации это особо не меняет ,полюбому нужно ремонтировать или что боллее актуально - задумываешся над способами как можно увеличить надежноть работы.
Тоесть думаеш уже над переносом данных во ФЛЕШ ,помехозащищеностью и написанию промежуточных технологических прошивок для настроек и калибровок ну на крайняк уже камни другие пробовать ,что меня особо не радует

Ну, хоть и написано SRAM, на самом деле может быть и псевдо-SRAM. По крайней мере очень многие современные RAM построены на конденсаторах, но имеют встроенную схему регенерации содержимого и внешний интерфейс обычной статической памяти.


О-о-о, вы много потеряли Всё познаётся в сравнении. Со слезами вспоминаются те трюки, котрые приходилось делать, используя этот CPU, чтобы получить эквивалент нескольких команд AVR. А уж ввод/вывод был просто Но до сих пор использую некоторые собранные на этом CPU приборы. А некоторые УФ ПЗУ (573РФ1, 573 РФ2) записаны 22 года назад (200 000 часов), и еще нормально работают. Вот это была надёжность!!!

Ну я все свои изделия не вижу . Для встроенной RAM никогда лично не видел, а для внешней, когда завод производитель укомплектовал 5V вместо 3V памятью девайсы работали до нескольких часов, но сбоили. Попадалась опять-таки партия чипов которые с ADSP жить не хотели без глюков.

Разумеется нет, но некоторое приближение получить можно.

Тестирование там начинается примерно на 4-5 команде (первые там запрет NMI), когда генерится импульс старшим битом 60h порта после чего там остается "1". Дальлее инициализация Video, периферии, таймеров (у первых IBM регенерация памяти была софтовая по таймеру), DMA.. между всеми этими операциями наращивался счетчик в 60h порту. После инициализации второго канала таймера уже можно было и попищать. И где-то уже потом-потом тестировалось 16K памяти, инициализация стека и понеслось... Причем 16K были выбраны не как минимально необходимые для тестирования, а как минимально гарантированные в наличии (во времена были!).

Как следует из вышеизложенного тесты у IBM идут и до "появления" RAM.

Можно проверить CRC EEPOM и FLASH, как самые вероятные причины отказов. Остальное проверить сложно и малополезно и нет 100% вероятности выявления неисправности. И вообщем то с переходом на импортные микросхемы дефекты стали настолько редки, что про тестирование процессора можно и забыть. Лучше обратить внимание на качество остальных элементов, особенно электролитических конденсаторов. Нонэйм электролиты, качество пайки, тепловые и электрические режимы - вот теперь на что смотреть надо.

Совершенно согласен. Безусловно если есть внешние элементы (в том числе и память) то проверять можно и даже нужно. Желательно тесты памяти использовать как предлагалось. То есть динамический тест с записью данных в ОЗУ по определённому алгоритму а потом сравнение. Ну и диагональные. Статические тесты, как правило показывают только полную неработоспособность памяти в целом.

Я, если есть возможность, и при сложной задаче, иногда её разбиваю на модули. Каждый со своим МК. Связь по последовательному интерфейсу. Как правило такие системы работают надёжнее чем один МК со сложной обвеской. (если не использовать ПЛМ). Да и разрабатывать полегче.

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

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

Для средненькой прооверки памяти AVR польззовал следующий тест:
1. Все 0
2 Все 1
3 Шагающая 1
4 Шагающий 0
5 Random

Вроде как работало неплохо.

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

Для любой встроенной системы, имеет смысл тестировать EEPROM(для AVR), так как в ней наиболее часто происходят сбои, тестировать регистры(таймеры, АЦП, USART и т.п.) не имеет смысла потому, что с нерабочими регистрами устройство просто не пройдёт выходной контроль. В процессе работы есть смысл проверять связь с внешними устройствами (хотя это происходит само собой, если не использовать задержку вместо ожидания готовности устройства). Гораздо важнее обеспечить "Безопастное состояние" устройства после/вовремя сбоя. Например в случае выхода из строя источника тактирования процессора никакие тесты не помогут, а установка второго МК для контроля основного приводит к вопросу "Кто будет сторожить сторожей?".
Последнее не относится к задачам где требуется резервирование, это отдельная и сложная тема.

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

Как Вы считаете, что более надёжно:

1) Вероятность сбоя устройства равна 10 в минус 9 степени; вероятность того, что этот сбой система не обнаружит (не зарегистрирует) и соотвтетственно не предпримит ни каких мер равна 50%
2) Вероятность сбоя устройства равна 10 в минус 3 степени; вероятность того, что этот сбой система не обнаружит (не зарегистрирует) и соотвтетственно не предпримит ни каких мер равна 0,0000001%

И что более надёжно? "Надёжная" система, сбои которой просто не обнаруживаются
или "ненадёжная" система, у которой 99,99999999% сбоев обнаруживаются и предпринимаются соответствующие меры по устранению их последствий


Как говорится: лучше перебдеть, чем недобдеть

Насчёт тестов считаю, что они полезны, но не особо. Хотя сам во время работы CRC32 программы всё время считаю (в фоновом режиме).
Но вот то, что интересно:
Никто из авторов про ЛОГ-и даже и не упомянул! А без логов все эти тесты - фикция.
Тест только во время работы полезен. На производстве выходной контроль д.б., а это почище любого теста будет!
Ну так вот - произошло что-то во время работы . Тест там что-то накопал, или просто процессор по собаке перезапустился, и снова все работает. Никто об этом и не узнал! Ну, может оператор нецензурно выругался, питание выключил-включил и забыл об этом. В худшем случае питание само выключилось (может по всему городу). И всё - все концы в воду!
Некоторые горе-разработчики этому даже рады будут! Они ничего не докажут - мы ни в чём не признаемся!
Так вот я считаю - тесты только тогда полезны, когда логи есть. А вот логи - они и без тестов полезны. И заменяют их во многих случаях (если не во всех).

Но насчёт логов - это уже другая тема. Может организуем? Я бы поддержал.