Характер неисправности. После запуска ПРЦ не выдавал никакой информации. Однако, судя по сигналу ВРК, ПРЦ запускался, но на каком то этапе самопроизвольно останавливался. В то же время, судя по тому, что после запуска с ПО сбрасывалась случайная информация, ПРЦ доходил по крайне мере до ПОС 255 и ПОС 256 (см. листинг РПТ) – п/п обнуления РИД и РИЦ.
Для поиска точки произвольного останова можно использовать команду СТОП - код 174764. Перемещая данную команду сверху вниз по программе (т.е. в порядке ее выполнения), можно выяснить какой точки программы ПРЦ достигает. Однако самой по себе ее недостачно, т.к. невозможно установить произошел ли останов самопроизвольно (в момент, когда ПРЦ еще не дошел до команды СТОП) или же вследствие выполнения команды. Для выхода из положения я составил программу «пробку»:
160200 загрузка 070400 в Р0
070400
170721 пересылка из Р0 в РБД1
160200 загрузка 073567 в Р0 (073567 соответствует 7777 на РИЦ)
073567
030040 пересылка из Р0 в 170440 (РИЦ)
174764 стоп
Данная программа зажигает на левом РИЦ ПО код 7777 и затем происходит останов. Эта программа, однако, слишком громоздка для «передвижения» ее по РПТ, т.е. для многократной записи - перезаписи вручную. Поэтому я разместил ее в том месте ПЗУ, которое не занято РПТ (например, с адр. 000002), тогда по РПТ достаточно перемещать лишь БП на эту программу, т.е. одну команду
161520
000002
Используя этот прием я выяснил, что основ происходит при выполнении ПОС 253 – п/п распаковки восьмеричного кода для вывода информации на РИЦ, а именно после (или во время) выполнения команды по адр. 17517. Однако немедленно обнаружилось затруднение. Оказалось, что если по адр. 000001 записать 17517, т.е. вынудить тем самым ПРЦ после запуска сразу перейти к выполнению команды по адр. 17517 минуя все промежуточные этапы, то останова не происходит. Это означало, что для появления неисправности самой по себе указанной команды недостаточно, что она возникает лишь в комбинации данной команды с какими то другими командами. Тогда я стал уменьшать адрес первого БП, т.е. последовательно уменьшать 17517 (по адр. 000001) на 1. Выяснилось, что останов возникает, начиная с адр. 17515, т.е. при выполнении трех команд с адр. 17515, 17516, 17517 (коды команд соответственно 070144, 116543, 174226).
Выделив эту группу команд отдельным фалом и загрузив в СП-НЦ-31 (адреса 000000, 000001, 000002) я уже при помощи осциллографа обнаружил, что останов действительно возникает при выполнении комбинации из этих команд - во время выполнения команды 174226. А именно, останов происходил момент попытки ПРЦ загрузить следующую команду: ПРЦ выдавал адр.000003 (правильный) и получал ответ от ПЗУ, что адрес принят (сигнал ПМ). Затем ПЗУ выставлял данные и сигнал ВМ. В ответ процессор должен был считать данные и выставить ПМ, но этого не происходило – возникало зависание и останов.
При просмотре сигналов БИС 588ВУ1 обнаружилось, что уже после останова УПО (101 и 102 прошивки) продолжают безостановочно генерировать микрокоманды – явная неисправность. Выяснить какая именно из прошивок (они включены параллельно) генерирует эти микрокоманды было несложно – по сигналам Ф2 (они не объединены). «Виновной» оказалась прошивка 588ВУ1 – 102. После ее замены работоспособность ПРЦ восстановилась.
После запуска ПРЦ выдавал на ПО 0101 и… более ничего. Судя по некоторым признаком можно было предположить, что ПРЦ начинает проверку «подсчет КС ПЗУ» и затем зацикливается где-то «на стороне». Так оно и оказалось: при помощи описанной выше программы – «пробки» я выяснил, что ПРЦ действительно входит в цикл подсчета КС, но не выходит из него. Оформив указанный цикл в виде отдельной программы, я убедился, что сбой возникает именно в ходе ее выполнения.
После этого я начал последовательно сокращать и упрощать указанный цикл и, наконец, пришел к результату несколько неожиданному. А именно: цикл на рис 1 ПРЦ выполнял нормально, в то время как при выполнении цикла на рис. 2 возникали сбои.
Рис.1
000000/162200 : 4000 в Р4
000001/004000 :
000002/160200 : 70400 в Р0
000003/070400 :
000004/170721 : Р0 в РБД1; т.е. 70400 в РБД1
000005/174203 : ИНК Р3
000006/031462 : Р3 в 170462; вывод содержимого Р3 на индикацию, в качестве индикатора
000007/061776 : БП на 000005 блок нагрузок КЭ
Рис.2
000000/162200 : 4000 в Р4
000001/004000 :
000002/160200 : 70400 в РБД1
000003/070400 :
000004/170721 :
000005/174203 : ИНК Р3
000006/031462 : Р3 в 170462
000007/070000 : ПЕР Р0 в Р0 = NOP
000010/061775 : БП на 000005
То есть, во-первых, оказалось, что сбой не связан ни с арифметическими командами, ни с перебором адресного пространства ПЗУ, ни с командами ветвления, как можно было предположить в начале. Во вторых второй цикл отличается от первого только наличием «пустой» команды 70000 (ПЕР Р0 в Р0). Вообще то она появилась можно сказать случайно: в ходе «секвестирования» первоначально цикла я ее использовал вместо команды «нет операции» (поскольку этой команды, как таковой, нет в системе команд ПРЦ). Заменив эту команду на 70063 (ПЕР Р3 в Р3), я обнаружил, что сбои продолжаются, хотя характер их несколько меняется. В общем, стало ясно, что сбой возникает при выполнении некоторых регистровых операцией. Все РОНы находятся в ОАУ 588ВС1. С другой стороны, при выполнении команд 70000 и 70063 выполняется ОДНА И ТА ЖЕ микропрограмма, а характер сбоев, как я сказал, был различен. Отсюда можно предположить, что неисправно не УПО, а именно ОАУ. После замены этой м/с ПРЦ начал нормально работать.
Уникальная неисправность. РПТ (369-370) проходит нормально, но при нажатии клавиш «выход из РПТ» или «выход на КВП» ПРЦ останавливается; при этом на ПО не выдается никакой информации (помимо той, которая была на момент нажатия клавиш). При помощи описанного выше приема с «пробкой» установил, что останов происходит при выполнении комбинации команд:
017332/161700 : ПЕР РУС в Р0
017333/161200 : ПЕР 200 в Р2
017334/000200 :
По осциллографу было видно, что первая команда как будто выполняется, а во время выполнения второй происходит останов.
На этой стадии натолкнулся на неприятную особенность работы ПРЦ. Как оказалось проследить по осциллографу выполнение команды ПЕР РУС в Р0 трудно или невозможно (по крайней мере мне не удалось). Такое впечатление, что после загрузки соответствующего кода команда выполняется в произвольный момент времени (в каких то пределах конечно), поэтому вразумительной картинки на осциллографе не получается. Я, однако, ясно увидел, что по первому (после загрузки кода) сигналу ВМ выдается явно не тот адрес (должен, как я понимаю выдаваться адрес РУС-170022), к тому же он еще и самопроизвольно изменялся. Адрес выставляет ОАУ (588ВС1), а отвечать на него должна ААУ (в ней находится РУС). Значит, неисправна была одна из 3 м/с: или УПО1, или УПО2, или ОАУ.
По «науке» я конечно должен был проследить процесс на уровне микрокоманд и установить какая именно из перечисленных микросхем неисправна. Однако безрезультатно промучившись с описанной выше проблемой с синхронизацией осциллографа, я бросил «науку» и решил действовать методом ненаучного «тыка»… Попал со второго раза: неисправной оказалась УПО1 (588ВУ1-101).
Должен заметить, что описанные выше в первых двух примерах ситуации, когда мне удалось «красиво» выйти на неисправную БИС являются скорее исключением, а нормой – третий случай, когда локализовать неисправность до уровня конкретной м/с трудно или невозможно. В любом случае, прежде чем выкусывать «подозрительную» БИС необходимо самым тщательным образом проверить ВСЕ сигналы ОБ – работа трудоемкая и кропотливая (это если неисправен ОБ, если же неисправна периферия, то здесь, как правило, все проще). Я, таким образом, не утверждаю, что ремонт при помощи СП-НЦ-31 простой и легкий, я утверждаю лишь, что благодаря названному устройству он становится ВОЗМОЖНЫМ.
