2. Автоматизация программирования мпс.

Программы самоконтроля.

Увеличение сложности МПС потребовало включение в них программ самоконтроля или диагностики. Тестовые программы можно поместить в начальной области системного ПЗУ, находящегося в адресном пространстве памяти, там, куда переходит программный счетчик при включении питания, или осуществить отдельный специальный модуль тестового ЗУ, которое подключается вместо первого системного ПЗУ и переход к которому осуществляется при сбросе вручную.

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

Основные диагностические тесты:

• тест системного ядра

• тест ПЗУ

• тест ОЗУ

• тест УВВ

Существует ли отказ в действительности?

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

ОШИБКА

неисправность → дефект

субъективная неисправность

Рекомендации по «А может дефекта нет?»

• Изучить описание и проверить тест-программы на еще работающей МПС:

когда подозревается отказ, часто много информации о системе можно получить, не снимая крышек оборудова­ния, однако очень вероятно, что «тщательный осмотр» не покажет причину отказа, и исследователю придется глубже разби­раться в системе. К сожалению, многие в этой ситуации. следуют правилу: «если что-то неисправно, надо посмот­реть описание системы». Такой, в принципе, плохой, но широко распространенный подход для микропроцессор­ных систем имеет еще меньше смысла, чем для обычных цифровых систем. В описании обычно есть целый набор тестовых процедур, специальные переключатели, пере­мычки и индикаторы, которые только и ждут, чтобы ими воспользовались. Персонал должен познакомиться со все­ми этими средствами до возникновения в системе каких-либо отказов и опробовать тест-программы на исправной системе, чтобы знать возможные реакции. Все микросхе­мы похожи друг на друга, и исследователь должен узнать из описания системы по руководству пользователя, где находятся такие важнейшие компоненты, как микропро­цессор, ЗУПВ, ПЗУ, ВВ, дешифраторы адреса, генератор синхронизации и контроллер прерываний.

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

• Произвести внешний осмотр (разъемы), грязные пе­чатные платы и кабельные соединения вызывают в сис­теме чрезмерный шум (обычно низкочастотный). Эти дефекты обычно можно обнаружить внешним осмотром или прикосновением. Целесообразно с известной осто­рожностью осуществить проверку, называемую странным термином «калиброванный кулак», при которой произво­дится легкое постукивание по механическим узлам системы (покачивание, изгибание платы поможет обнаружить плохой контакт в разъеме, неплотно вставленные БИС в панельки и разорванные печатные проводники). Большинство таких отказов быстро устраняет­ся. Описанные приемы надо Использовать осторожно, чтобы не усугублять ситуацию.

• Рекомендуется вести журнал проверок МПС, в котором указывается характер отказа и его причина. В случае повторения отказа по журналу быстро устанав­ливается его причина. Журнал особенно полезен, если эксплуатируется несколько аналогичных систем, в которых обычно возникают одни и те же отказы.