|
|
  |
Тестирование узлов микроконтроллера |
|
|
|
Apr 4 2006, 04:43
|

Знающий
   
Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206

|
Flash тестируется просто - дописываешь в конец CRC16, например, и периодически проверяешь, можно в фоне по байту добавлять, чтобы не занимать сразу много времени. ОЗУ - я делал таким образом (правда для х51, но думаю это не имеет значения): периодически запрещал все прерывания и тестировал несколько байт памяти, то есть сохранял содержимое в регистрах, записывал в память константы типа 0xAA, 0x55 , потом считывал, сравнивал, выставлял флаг. Эту функцию вызывал в 1 раз основном цикле. В результате за несколько десятков секунд вся память проверялась в фоновом режиме (я тестировал внешнюю память в 32К). По поводу АЦП, таймеров, то там по обстоятельствам, минимально тестировать наличие прерываний от соответствующих модулей.
--------------------
Пасу котов...
|
|
|
|
|
Apr 4 2006, 04:51
|

кекс
     
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326

|
Цитата(BigBolt @ Apr 4 2006, 06:15)  Заказчик проекта требует чтобы через определённые промежутки времени по ходу выполнения программы проводилось тестирование основных узлов микроконтроллера, в частности ОЗУ, таймеров, АЦП и что очень интересно Flasha. Схемотехническая часть уже сформирована и не подразумевает наличия каких либо источников тестовых сигналов. Микроконтроллер Mega64, ПО разрабатывается в среде WinAVR. Может быть кто-нибудь что-нибудь посоветует ? Помоему тривиальная задача.. RAM тестировать просто - частями. Заполнить участок кодом $FF, прочитать и сравнить с $FF, потом заполнить $00, также прочитать и сравнить. Потом смещенным кодом $80, $81, $82...$FF, 0.. также прочитать и сравнить. Флеш тоже просто. Если программа занимает меньше 50% флеша, то продублировать ее в памяти. Тест будет сводиться к сравнению рабочей части с резервной. АЦП проверить можно, сделав контрольный замер с MUX'ом настроенным на источник Vbg (внутренний ИОН). Таймеры - запустить таймер и параллельно сделать задержку на определенное число тактов. остановить таймер и сравнить значение TCNT с числом тактов, на которое осуществлялась задержка. Что вызывает у Вас затруднения?
|
|
|
|
|
Apr 4 2006, 05:43
|
Местный
  
Группа: Участник
Сообщений: 424
Регистрация: 6-03-06
Из: Н.Новгород
Пользователь №: 14 997

|
Цитата(defunct @ Apr 4 2006, 07:51)  Цитата(BigBolt @ Apr 4 2006, 06:15)  Заказчик проекта требует чтобы через определённые промежутки времени по ходу выполнения программы проводилось тестирование основных узлов микроконтроллера, в частности ОЗУ, таймеров, АЦП и что очень интересно Flasha. Схемотехническая часть уже сформирована и не подразумевает наличия каких либо источников тестовых сигналов. Микроконтроллер Mega64, ПО разрабатывается в среде WinAVR. Может быть кто-нибудь что-нибудь посоветует ?
Помоему тривиальная задача.. RAM тестировать просто - частями. Заполнить участок кодом $FF, прочитать и сравнить с $FF, потом заполнить $00, также прочитать и сравнить. Потом смещенным кодом $80, $81, $82...$FF, 0.. также прочитать и сравнить. Флеш тоже просто. Если программа занимает меньше 50% флеша, то продублировать ее в памяти. Тест будет сводиться к сравнению рабочей части с резервной. АЦП проверить можно, сделав контрольный замер с MUX'ом настроенным на источник Vbg (внутренний ИОН). Таймеры - запустить таймер и параллельно сделать задержку на определенное число тактов. остановить таймер и сравнить значение TCNT с числом тактов, на которое осуществлялась задержка. Что вызывает у Вас затруднения? Если тест проводится в начале программы до инициализации переменных то всё просто: пиши и считывай что хочешь,а что делать когда в памяти переменные, стек ?
|
|
|
|
|
Apr 6 2006, 13:41
|

Частый гость
 
Группа: Участник
Сообщений: 106
Регистрация: 4-04-06
Пользователь №: 15 783

|
Цитата(defunct @ Apr 4 2006, 08:51)  Помоему тривиальная задача.. RAM тестировать просто - частями. Заполнить участок кодом $FF, прочитать и сравнить с $FF, потом заполнить $00, также прочитать и сравнить. Потом смещенным кодом $80, $81, $82...$FF, 0.. также прочитать и сравнить. Флеш тоже просто. Если программа занимает меньше 50% флеша, то продублировать ее в памяти. Тест будет сводиться к сравнению рабочей части с резервной. АЦП проверить можно, сделав контрольный замер с MUX'ом настроенным на источник Vbg (внутренний ИОН). Таймеры - запустить таймер и параллельно сделать задержку на определенное число тактов. остановить таймер и сравнить значение TCNT с числом тактов, на которое осуществлялась задержка. ОЗУ правильно проверять бегущим нулем и бегущей единицей. Причем, после каждой записи смотреть состояние всего ОЗУ. ФЛЭШ по CRC однозначно! А если в целом, то все это бред. И саме главное... как проверить софт самотестирования?
|
|
|
|
|
Apr 6 2006, 20:29
|
Гуру
     
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521

|
Цитата(defunct @ Apr 4 2006, 08:51)  Помоему тривиальная задача.. RAM тестировать просто - частями. Заполнить участок кодом $FF, прочитать и сравнить с $FF, потом заполнить $00, также прочитать и сравнить. Потом смещенным кодом $80, $81, $82...$FF, 0.. также прочитать и сравнить. Флеш тоже просто. Если программа занимает меньше 50% флеша, то продублировать ее в памяти. Тест будет сводиться к сравнению рабочей части с резервной. АЦП проверить можно, сделав контрольный замер с MUX'ом настроенным на источник Vbg (внутренний ИОН). Таймеры - запустить таймер и параллельно сделать задержку на определенное число тактов. остановить таймер и сравнить значение TCNT с числом тактов, на которое осуществлялась задержка.
Что вызывает у Вас затруднения? Задача с ОЗУ и EEPROM отнюдь не тривиальная. В своё время я пытался её реализовать в серийном проекте, но забросил. Если это делается при сбросе или можно на время теста ПОЛНОСТЬЮ остановить работу, то тогда да. А если нет, то тестить достаточно сложно. С FLASH - всё понятно CRC16. Если он нарушился, то дублирование может не помочь. Но вот другой вопрос насколько это нужно. В том проекте о котором я писал, я просто что могу то тестирую, что не могу - то выдаю Ok.  Заказчик и не догадывается. За 4 года выпуска и более 3 тысяч изделий ни разу не было возврата по причине что тест не проходит. Вообще за 15 лет работы я сделал вывод что МП в изделии - это самая надёжная вещь.  Может накрыться кондёр кварца, но не МП. И тестить его это просто дополнительный гимор. А заказчик как правило не разбирается в таких вещах. Так зачем его огорчать. Лучше потратить силы на WDT и защиту от сбоев и помех различными протоколами. Вот это даёт значительный выигрышь в стабильности работы изделия.
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|