Просмотр полной версии : Тестовое ПЗУ
Привет всем.
Есть ли для "Вектор-06Ц" тест для ПЗУ, устанавливаемого вместо загрузчика и способного протестировать память и другие узлы и, при невозможности увидеть результаты на экране, сообщающего состояние звуковым сигналом и/или миганием светодиода?
С уважением, Алексей.
Подниму старую тему.
В общем вопрос тот же, есть ли тест для записи в ПЗУ вместо штатнойго?
Нашел этот тест http://sensi.org/scalar/ware/622/ я так понимаю для записи в ПЗУ нужна версия, которая располагается с адреса 0000h? Тогда зачем версии с адресами 2000h,4000h и 6000h?
Эти тесты не для работы из пзу. Не знаю тестов для вектора работающих из пзу
А как тогда память протестить?
- - - Добавлено - - -
Воостанавливаю комп, при сбросе на белом экране характерные вертикальные полосы...
А как тогда память протестить?
Воостанавливаю комп, при сбросе на белом экране характерные вертикальные полосы...
Воюю с шиной разъёма "ВУ", конкретно с RAS/CAS.
Пытаюсь подключить на эту шину внешнее ПЗУ, в котором находится тест всего адресного пространства ОЗУ.
Для этих целей переписал один из тестов ОЗУ. Убрал из него все команды, требующие использования ОЗУ. Типа вызов подпрограмм и сохранение результата тестирования очередного банка ОЗУ.
Сама программа работает (на эмуляторе), а вот из Внешней ПЗУ на реальном Векторе сопротивляется.
Если не держать на шине сигнал "БЛК", то на шину не попадает CAS - внешняя ПЗУ не получает адрес.
Если держать "БЛК" постоянно, то заблокирована работа с ОЗУ Вектора...
Есть очередная идея, на днях буду пробовать реализовать.
Для вывода результата без ОЗУ экрана, одного светодиода может быть маловато.
Как вариант, можно подключить матрицу светодиодов к "ПУ".
И показывать на них отдельно состояние каждого банка ОЗУ.
Можно ещё результат на бордюр выводить, выделяя цветом или шириной полос.
Надо ещё думать.
Главное пока ПЗУ запустить.
Кстати, идея внешнего ПЗУ с тестом ОЗУ, это для тестирования Вектора, на котором ПЗУ загрузчика впаяна.
Если уже есть возможность переставить ПЗУ, то мой тест будет работать и вместо ПЗУ загрузчика.
Вечером выложу сам тест.
Не, на бордюр выводить не получится, для стабильной картинки на бордюре, нужно разрешать прерывания, а ими пользоваться нельзя, так как это гарантированное использование ОЗУ, а им пользоваться нельзя..
Выкладываю тест ОЗУ.
Тестирует адреса ОЗУ 8000h-FFFFh, работает при установке на место штатного загрузчика Вектора.
В текущей версии есть вывод маски микросхем в порт "ПУ":
"А" - маска микросхем (старший бит порта соответствует нижней микросхеме на плате);
"В" - номер банка (два младших бита, нумерация банков слева на право, от 0 до 3).
"0" на выходе порта - микросхема исправна.
Порт "В" выход инвертирован, банк 0 = 03h (подключенные к порту светодиоды НЕ горят).
Перед тестированием памяти реального Вектора, лучше сначала запустить тест в эмуляторе, что-бы иметь представление как ведёт себя тест в штатных условиях.
Alex_LG, есть конкретные идеи, как обозначить не исправные микросхемы памяти без использования экранной памяти?
По ходу обсуждения, появился тест верхней части ОЗУ и шины адреса ОЗУ.
Тест работает из ПЗУ (вместо штатного загрузчика).
По ссылке сообщение с тестом.
https://zx-pk.ru/threads/30914-testovoe-pzu.html?p=1156693&viewfull=1#post1156693
Alex_LG, есть конкретные идеи, как обозначить не исправные микросхемы памяти без использования экранной памяти?
Я, хоть и другой Alex, но предложу :)
Думаю, самый очевидный способ индикации - светодиод РУС/ЛАТ. Номер неисправной микросхемы можно закодировать в сериях вспышек с разделением их длительной паузой. Параллельно, на всякий случай, можно выводить номера на параллельный порт. 8 бит - более, чем достаточно, а там их 3х8. Подключил светодиоды и смотришь. Можно и на звук дублировать. Но микросхема таймера может быть неисправна, как и порт принтера. А порт светодиода, скорее всего, будет исправен, во всяком случае, без него, всё равно, кнопки клавиатуры не нажмёшь...
KTSerg уже упоминал бордюр, а что касается конкретики можно взять идею из амстрадовского теста (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/quick-and-dirty-ram-test-for-cpc/msg106676/#msg106676)
ivagor, а что там за идея?
Я долго переводить буду, не уверен, что уловлю суть.
Можно конечно подумать, и сделать адаптивный тест.
К примеру, сначала тестируются все банки ОЗУ - экранной области.
Если найдена хотя-бы одна область без сбоев, то программа настраивается на вывод результатов именно в эту область.
Иначе сообщает, что "всё плохо"...
Что-нибудь в таком духе.
Improver
09.11.2020, 18:19
Вообще, это крайне полезная задача, я тоже думал о таком тесте, но только в виде одной из функций штатного загрузчика ПЗУ Вектора, подключение же к шине ВУ имеет ещё больше плюсов.
Вот что мне лично хотелось бы увидеть в таком тесте:
1. Да, абсолютно важно тестировать Вектор "в слепую", т.к. даже для подключения телевизора требуются доработки, которых может и не быть.
2. Не помешает, чтобы этот тест выводил сигнал 1кГц (ну или 10кГц) на динамик для проверки частотометром и контроля работы тактового генератора и процессора. С той же целью можно вывести какую-нибудь мелодию, проверить "на слух".
3. Диагностические данные можно выводить на ВУ, на линии ШД, через отправку данных в порт FFh -- это можно выловить логическим анализатором, и, в тоже время, не даст сбоя при неисправности микросхемы ВВ55А на порту ПУ.
4. Тестирование памяти можно разбить на два этапа, например, верхние 32кб тестировать из ПЗУ, потом туда записать тестовый модуль и протестировать нижние 32кб. Результат можно выводить индикатором рус/лат например, так: при удержании кнопки УС индикатор мигает номер столбца, а при СС -- номер неисправного чипа в этом столбце. Если с памятью всё ок, то можно, опять же, проиграть мелодию...
А если клавиатура не исправна, то битый чип памяти можно обозначить также тональностью сигнала и миганием РУС/ЛАТ.
...
1. Да, абсолютно важно тестировать Вектор "в слепую", т.к. даже для подключения телевизора требуются доработки, которых может и не быть.
2. Не помешает, чтобы этот тест выводил сигнал 1кГц (ну или 10кГц) на динамик для проверки частотометром и контроля работы тактового генератора и процессора. С той же целью можно вывести какую-нибудь мелодию, проверить "на слух".
3. Диагностические данные можно выводить на ВУ, на линии ШД, через отправку данных в порт FFh -- это можно выловить логическим анализатором, и, в тоже время, не даст сбоя при неисправности микросхемы ВВ55А на порту ПУ.
...
Если считать, что есть логический анализатор.
То можно выводить даже на магнитофонный выход, последовательность из 32-33 импульсов. А промежуток между ними - состояние микросхемы: короткий "ОК" , длинный - "брак". Или наоборот, просто длительностью самих импульсов, не важно.
Только нужно решить, а все ли смогут анализатором воспользоваться.
Лучше не надеяться на клавиатуру. Во время ремонта она мешается, и может быть отпаяна.
Alex_LG, есть конкретные идеи, как обозначить не исправные микросхемы памяти без использования экранной памяти?
Можна, как и предлагалось уже, по аналогии с тестом от "Микроши" - в порт ПУ выводить на РА номер испорченого бита, а в порт РВ или РС старший байт адреса. За одно и минимальный тест дешифрации портов...
ivagor, а что там за идея?
Микросхемам памяти можно сопоставить полоски на бордюре
Микросхемам памяти можно сопоставить полоски на бордюре
А можно-ли выводить полоски на бордюре, не пользуясь прерываниями?
Если хотя-бы один кусок памяти исправен, то можно на него указатель стека натравить. А вот если битыми окажутся хотя-бы по одной микросхеме в каждом банке, то стеком пользоваться не получится.
- - - Добавлено - - -
Можна, как и предлагалось уже, по аналогии с тестом от "Микроши" - в порт ПУ выводить на РА номер испорченого бита, а в порт РВ или РС старший байт адреса. За одно и минимальный тест дешифрации портов...
Если добавить сначала тест ПУ. Типа бегущий бит по портам. Что-бы можно было убедиться, что инфа адекватна. То можно выводить результат на ПУ.
А можно-ли выводить полоски на бордюре, не пользуясь прерываниями?
Если хотя-бы один кусок памяти исправен, то можно на него указатель стека натравить. А вот если битыми окажутся хотя-бы по одной микросхеме в каждом банке, то стеком пользоваться не получится.
Без прерываний нормально полоски не нарисуешь, но как я понял смущают не прерывания, а озу под стек. Пользоваться прерываниями можно и без работоспособного озу, нам же не обязательно возвращаться в произвольное место произвольной программы. Если вызываем только из одного места, то проблем совсем нет, если прерывания вызываются из нескольких мест, то адрес возврата придется передавать в регистровой паре.
Пример, как работает амстрадовский тест (есть проблемы (https://www.youtube.com/watch?v=LLVHJO-aj3Q&feature=youtu.be&t=276), нет проблем (https://www.youtube.com/watch?v=LLVHJO-aj3Q&feature=youtu.be&t=347)).
Без прерываний нормально полоски не нарисуешь, но как я понял смущают не прерывания, а озу под стек. Пользоваться прерываниями можно и без работоспособного озу, нам же не обязательно возвращаться в произвольное место произвольной программы. Если вызываем только из одного места, то проблем совсем нет, если прерывания вызываются из нескольких мест, то адрес возврата придется передавать в регистровой паре. ....
Что-то я не совсем понял, как это без использования ОЗУ можно вернуться из прерывания?
При переходе к прерыванию, в ОЗУ по указателю стека сохраняется адрес, куда нужно вернуться.
При возврате из прерывания из ОЗУ считывается адрес (куда вернуться), а если ОЗУ битое, то считывается мусор, и возврат из прерывания произойдёт не известно куда.
Или я что-то не так понимаю?
В предыдущем посте я вроде основную идею написал, не буду повторяться. Если смущает возврат из прерывания, то он будет не по ret, а по pchl (если возвращаемся на переданный на входе адрес) или просто по jmp (если вызов всегда из одного места)
В предыдущем посте я вроде основную идею написал, не буду повторяться. Если смущает возврат из прерывания, то он будет не по ret, а по pchl (если возвращаемся на переданный на входе адрес) или просто по jmp (если вызов всегда из одного места)
Вот сейчас дошло.
Improver
09.11.2020, 21:35
Я думаю, показывать что-то цветом бордюра -- путь в никуда. Может на амстраде это и хорошо, но не на Векторе, т.к. тут видео может быть подключено и в чёрно-белом варианте, могут бежать кадры, или не работать вовсе. Лучше уж просто моргать РУС/ЛАТом.
У меня на машине, например, при отсутствии обд-сканера, можно считать коды ошибок по миганию всего одной лампочки, и разных кодов ошибок почти сотня. Десятки обозначаются длинными морганиями, единицы -- короткими, все накопленные ошибки отмаргивают последовательно при замыкании диагностического разъёма. Сделать то же самое на Векторе будет намного проще, чем цветовыми полосками на бордюре.
Я думаю, показывать что-то цветом бордюра -- путь в никуда. Может на амстраде это и хорошо, но не на Векторе, т.к. тут видео может быть подключено и в чёрно-белом варианте, могут бежать кадры, или не работать вовсе. Лучше уж просто моргать РУС/ЛАТом.
У меня на машине, например, при отсутствии обд-сканера, можно считать коды ошибок по миганию всего одной лампочки, и разных кодов ошибок почти сотня. Десятки обозначаются длинными морганиями, единицы -- короткими, все накопленные ошибки отмаргивают последовательно при замыкании диагностического разъёма. Сделать то же самое на Векторе будет намного проще, чем цветовыми полосками на бордюре.
При отсутствии возможности использования ОЗУ, накапливать коды ошибок негде.
Значит сообщать нужно будет при появлении первой-же ошибки и фактически останавливать тест, так как вставлять функцию вывода ошибки после проверки каждого банка - раздует программу.
Либо извращаться с вызовами из подпрограмм, с выходом из них по jmp/pchl.
Сейчас добавил тает ПУ, и вывод на него маски микросхем проверенного банка, и номера проверяемого банка. Всего получилось 10 светодиодов.
Тест циклический, банки последовательно тестируются. Должно получиться.
Завтра (или уже сегодня) попробую протестировать.
Адаптировать тест для работы из ПЗУ загрузчика возможно. Но нужно понимать, какая доработка сделана на Векторе при замене ПЗУ загрузчика.
Если ПЗУ загрузчика увеличено до 32КБ, то будет возможен тест ТОЛЬКО экранной области ОЗУ.
Версия теста для тестирования ОЗУ в диапазоне адресов 8000h-FFFFh.
Должна работать при запуске из ПЗУ загрузчика.
Выложена в сообщении на первой странице темы.
Improver
10.11.2020, 07:28
При отсутствии возможности использования ОЗУ, накапливать коды ошибок негде.
Значит сообщать нужно будет при появлении первой-же ошибки и фактически останавливать тестА почему бы и не остановить тестирование? Если есть ошибка, то спешить уже некуда, нужно о ней как-то сообщить, а потом можно будет продолжить.:)
А почему бы и не остановить тестирование? Если есть ошибка, то спешить уже некуда, нужно о ней как-то сообщить, а потом можно будет продолжить.:)
Отказ от использования ОЗУ для хранения значений переменных, стековых операций, и прочих плюшек (связанных с наличием ОЗУ), приводит к резкому сокращению функционала.
Регистров катастрофически не хватает (для реализации идей, порождённых буйной фантазией).
Классический вызов подпрограмм не возможен. Можно выделить подпрограмму, только если она не будет использовать одну из регистровых пар (чтобы вернуться из функции в основную программу), и не нарушит содержимое регистров с нужными данными (сохранить то их негде).
Вероятно есть возможность сделать вывод каждой ошибки, но это если функция вывода будет использовать минимум регистров.
Я вот думаю, может к РС подключить, и ему передавать ?
Появится адекватная интерпретация результата теста, а не подсчёт морганий светодиода.
Improver
10.11.2020, 08:40
А почему не сделать простой вывод в порт, как я предложил выше? Если уж делать внешнее тестовое ПЗУ, то там можно на шину данных повесить восемь триггеров, на выходе светодиоды, это добавит в схему всего-то три микросхемы (триггер + пару штук на логику для выделения порта, как в схеме квазидиска).
Ещё есть такой вариант алгоритма тестирования: можно сначала оттестить, например 8000h-8100h, и если там всё ок, то использовать её как стек, или для хранения результатов. Если в этой области ошибка всплыла, показать миганием и протестить следующие 256 байт, пока не будет найден исправный блок. Нет исправных блоков -- полный "систем еррор"...
А почему не сделать простой вывод в порт, как я предложил выше? Если уж делать внешнее тестовое ПЗУ, то там можно на шину данных повесить восемь триггеров, на выходе светодиоды, это добавит в схему всего-то три микросхемы (триггер + пару штук на логику для выделения порта, как в схеме квазидиска).
В версии теста для 32КБ есть вывод результата тестирования банка микросхем в порт ПУ.
В порт 07 выводится маска наличия ошибок микросхем.
В порт 06 (два младших бита) номер банка микросхем.
"0" на выходе ПУ должен зажигать светодиод. Погасший светодиод в маске означает брак данной микросхемы в данном банке.
Ещё есть такой вариант алгоритма тестирования: можно сначала оттестить, например 8000h-8100h, и если там всё ок, то использовать её как стек, или для хранения результатов. Если в этой области ошибка всплыла, показать миганием и протестить следующие 256 байт, пока не будет найден исправный блок. Нет исправных блоков -- полный "систем еррор"...
Про адаптивность теста я уже писал.
Надо думать над этой темой.
У вектора 4 линейки озу и в идеале желательно выдавать данные о каждой из них. Если через ПУ, то можно мультиплексировать результаты по времени, например некоторое время в A и B выдаются данные по 8000-9FFF и A000-BFFF, потом зажигается РУС/ЛАТ (можно выдать и в C при желании) и выдаются данные C000-DFFF и E000-FFFF, потом все по кругу.
Радиолюбителям я не указ, но если без телевизора, то самый простой способ выдачи результатов - через магнитофонный выход. Правда он прост только для пользователя, т.к. требует минимума телодвижений - записать wav через шнурок, а для разработчика теста без использования озу он сравнительно сложен.
Заменил ПЗУ загрузчика на ПЗУ с тестом ozu_m_32.
Тест запустился. Резать дорожки не очень хочется, для проверки обнаружения ошибок ОЗУ.
Правда я при инициализации портов забыл отключить ВИ53... пищит зараза...
Improver
11.11.2020, 09:39
У вектора 4 линейки озу и в идеале желательно выдавать данные о каждой из них. Если через ПУ, то можно мультиплексировать результаты по времени, например некоторое время в A и B выдаются данные по 8000-9FFF и A000-BFFF, потом зажигается РУС/ЛАТ (можно выдать и в C при желании) и выдаются данные C000-DFFF и E000-FFFF, потом все по кругу.Можно существенно сократить объём выводимых данных, если передавать номер бита, на котором произошёл сбой в памяти (0..7) и номер банка памяти (0..3), для этого хватит всего пяти линий одного порта ПУ, оставшиеся три линии можно использовать для вывода какого-нибудь кода ошибки. Или, практически то же самое, можно выводить номер сбойной микросхемы памяти (в формате строка/столбец), если это рассчитать будет не сложнее. Таких данных будет более чем достаточно для локализации проблемы в ОЗУ Вектора.
Можно существенно сократить объём выводимых данных, если передавать номер бита, на котором произошёл сбой в памяти (0..7) и номер банка памяти (0..3), для этого хватит всего пяти линий одного порта ПУ, оставшиеся три линии можно использовать для вывода какого-нибудь кода ошибки. Или, практически то же самое, можно выводить номер сбойной микросхемы памяти (в формате строка/столбец), если это рассчитать будет не сложнее. Таких данных будет более чем достаточно для локализации проблемы в ОЗУ Вектора.
Это для приёма логическим анализатором?
Для него можно: 3 бита - положение сбойной микросхемы и 2 бита номер банка. Ещё один бит на импульс синхронизации, шоб было понятно, что полезная инфа именно тута.
Итого 6 бит - для анализатора вполне приемлемо.
Если задействовать весь ПУ, то такого способа хватит максимум на 4 сбойные микросхемы + 4 бита для индикации того, что есть еще ошибки или их нет. Мой вариант универсальнее, но с другой стороны вряд ли часто бывает больше 4 плохих озушек сразу или их можно отлавливать и заменять не одномоментно, а в несколько приемов.
Если задействовать весь ПУ, то такого способа хватит максимум на 4 сбойные микросхемы + 4 бита для индикации того, что есть еще ошибки или их нет. Мой вариант универсальнее, но с другой стороны вряд ли часто бывает больше 4 плохих озушек сразу или их можно отлавливать и заменять не одномоментно, а в несколько приемов.
Это если без логического анализатора.
Для этого есть другой вариант. Кому сильно нужно, можно к ПУ подключить 4 микросхемы регистров, а к ним любые светодиодные матрицы.
Например: на порт "А" выводить байт маски ошибок, а 4 бита порта "С" использовать для импульсов "запись" (по одному биту на каждый регистр).
Получим картинку как на экране (по информативности).
Желательно одновременно знать состояние всех 32 микросхем.
Так как сообщение о 8 неисправных микросхемах в одном ряду может натолкнуть на мысль, что где-то в этом ряду дорожка отгнила.
А если этого не видеть, можно начать выкусывать ОЗУшки, и это ни к чему не приведёт, кроме потери времени и порчи потенциально рабочих микросхем.
Все зависит от потребностей и возможностей конкретного наладчика, но мне как не любителю рукоделия больше нравятся варианты с минимальными аппаратными вложениями. Фактически таким является вышеупоминавшийся вариант с выдачей результата через магнитофонный порт. Там сложно писать программу, но если есть логический анализатор, то для последовательной передачи через ПУ вполне можно ограничиться двумя пинами - данные и "клок", это проще сделать
Немного оптимизации в тесте ОЗУ. Заметил, что при первом запуске на реале палитра не прописывалась, а повторный ВВОД+БЛК её лечил. Это исправил. Оказалось снова пропустил при старте инит очередного порта. Интересно, что большинство эмуляторов этого не видели, и прощали такую небрежность.
Тестирует адреса ОЗУ 8000h-FFFFh, работает при установке на место штатного загрузчика Вектора.
В текущей версии остался вывод маски микросхем в порт ПУ: А - маска микросхем (старший бит порта соответствует нижней микросхеме на плате), В - номер банка (два младших бита, нумерация банков слева на право, от 0 до 3).
Удалил промежуточные версии.
В сообщении на первой странице темы, версия заменена на актуальную.
Improver
25.12.2020, 13:12
Сделал альтернативный тест для Вектора с запуском из ПЗУ. В отличие от теста KTSerg, тестирование производится не только памяти и без вывода какой-либо полезной информации на экран, работает тест так:
1. Тестирование процессора с генератором, клавиатуры и ВИ53. На этом этапе, сразу после запуска, просто мигает индикатор "РУС/ЛАТ" с выводом щелчка при переключении, если нажать на клавишу "СС", "УС" или "РУС/ЛАТ", то через ВИ53 выводятся частоты 3, 2 или 1 кГц соответственно. При этом ОЗУ Вектора не используется совсем, только ПЗУ.
2. Тестирование верхней памяти (8000h-FFFFh). Запуск тестирования выполняется после одновременного нажатия "УС" и "СС". Тестирование выполняется три раза, заполнением памяти значениями 55AAh, AA55h и 0000h, каждый проход сопровождается выводом звука через ВИ53, тоже 1, 2 и 3кГц. В случае обнаружения первой ошибки в памяти, в порт В на "ПУ" выводится сбойные биты, в 5-4 битах порта C на "ПУ" -- номер банка памяти ("11" -- банк 8000h-9FFFh; "10" -- банк A000h-BFFFh; "01" -- банк C000h-DFFFh; "00" -- банк E000h-FFFFh), после чего сразу идёт возврат к п.1. По сохранившейся тональности можно определить, на каком проходе была выявлена ошибка памяти.
3. Тестирование нижней памяти (0000h-7FFFh). Если предыдущий тест не обнаружил сбоев в верхней памяти, то туда копируется содержимое ПЗУ и ожидается нажатие БЛК+СБРОС для его отключения. Если в этот момент нажать "РУС/ЛАТ", то произойдёт возврат к п.1 и можно будет запустить тест снова. В случае наличия автозапуска, как на 02-м Векторе, вторая часть теста стартует автоматически. Тестирование нижней памяти выполняется аналогично, как и верхней, в три прохода. В случае обнаружения ошибок, они также выводятся в ПУ и после нажатия "РУС/ЛАТ" идёт повтор теста нижней памяти.
4. Дополнительные тесты. Если во время всех тестов ошибок не было обнаружено, то всё, что было записано ПЗУ после тестов, копируется в память с адреса 0100h и запускается на исполнение. Т.е. к файлу "BLINK.EPR" в конец можно (и нужно) дописать любую программу до 32кБ, и эта программа будет запущена сразу после теста памяти. Это могут быть тесты устройств, квазидиска или даже некая оболочка с выбором последующего теста из нескольких -- всё, что поместится в 32Кб минус 593 байта. Для примера, в архиве в файл "BLINK.r0m" дописан стандартный тест техпрогона.
Архив с прошивкой для ПЗУ и исходниками: 74323
Проверил работу в эмуляторах и на живом Векторе (не из ПЗУ). Да, мой тест несколько хуже в плане информативности по ошибкам, т.к. останавливается на первой же найденной ошибке, но какое-то заключение по работе Вектора с ним можно получить. Кроме того, он может работать с полностью неисправным ОЗУ, без вывода на ТВ, а также не использует прерывания и не программирует палитру. Пусть будет как альтернатива.
Сделал альтернативный тест для Вектора с запуском из ПЗУ.
...
3. Тестирование нижней памяти (0000h-7FFFh).
...
По идее, если в верхней части ошибок нет, и дело дошло до тестирования нижней части памяти, то результат можно и на экран вывести.
Improver
25.12.2020, 14:21
По идее, если в верхней части ошибок нет, и дело дошло до тестирования нижней части памяти, то результат можно и на экран вывести.Можно, но для этого нужно в начале записать палитру, для чего потребуется разрешить прерывания, а чтобы этого не делать при неизвестном состоянии памяти, а также возможно нерабочем состоянии вывода на экран, я решил пойти по простому пути, тестировать тем же алгоритмом. Ну в крайнем случае, после этого ведь можно запустить любой другой тест и проверить всё более наглядно. :)
В продолжение разговора про тестирование ОЗУ при замыкании разрядов шины адреса ОЗУ...
Я говорил, что можно мультиметром составить таблицу сопротивлений между адресными входами микросхемы ОЗУ, по принципу "всех со всеми".
Возможна более сложная альтернатива поиска проблем с шиной адреса.
Например, заполнение ОЗУ Вектора некой инфой, и выгрузка содержимого всех 64КБ памяти в файл на внешний носитель через разъём ПУ, так как шина адреса потенциально неисправна, то адекватная выгрузка на КД невозможна. И дальнейший анализ содержимого, уже на РС.
Анализ замыкания разрядов сложен, но возможен. Там-же будет очевидным замыкание разрядов шины данных. Хотя замыкание разрядов шины данных и на обычных тестах выявится, как неисправность микросхем одного разряда во всех банках (скорее всего).
Кстати, я прикинул... При замыкании разрядов шины адреса, мой "модуль внешнего ПЗУ" для тестирования ОЗУ - бесполезен, так как не будет работать. Для формирования адреса на своей ПЗУ, он использует ту-же шину, что и ОЗУ Вектора. При замыкании разрядов, программа в ПЗУ просто не будет работать.
Остается возможность запустить тест только заменив ПЗУ штатного загрузчика, на ПЗУ с тестом ОЗУ.
Можно ещё попробовать сделать более простой тест именно для тестирования разрядов шины адреса, и выводить результат на какой-то простой дисплей подключенный к ПУ. Поскольку шина адреса потенциально искажена, то при выводе на экран Вектора так-же возможно искажение результата.
По поводу дисплея... минимальный результат, это адрес по которому обнаружен сбой, значит на дисплее достаточно использовать четыре 7-ми сегментных разряда, в формате FFFFh.
В голову приходят минимум три варианта, которые может потянуть разъём "ПУ":
1. четыре 7-ми сегментных индикатора.
2. какой-то готовый дисплей из таких индикаторов.
3. ЖК-дисплей типа LCD1602.
Какой вариант Пробовать?
Мне проще LCD1602.
Процесс идёт.
Дисплей на ПУ работает.
Схема подключения очень простая, 4 диода и 4 резистора.
Осталось в тест ОЗУ его интегрировать, результаты на нём отображать.
Накатал тест ОЗУ из ПЗУ установленной на место штатного загрузчика, для анализа замыкания разрядов шины адреса ОЗУ.
Анализировать приходится данные из ОЗУ по адресам 8000-FFFF, так как на Векторе возможна доработка для расширения ПЗУ загрузчика до 32К.
Сначала у меня крыша поехала от результатов, так как мультиплексирование и запутанность разрядов шины адреса ОЗУ, и тут дают значительную путаницу.
Но вроде почти со всем разобрался...
Замыкание любых двух разрядов шины адреса с А0 по А5, дают однозначный результат с указанием, что замкнуты именно те разряды которые нужно.
А вот замыкание разряда А6 с любым другим (от А0 до А5), даёт дополнительно замыкание ещё и с разрядом А4.
Думал ошибка в анализе, выгрузил содержимое памяти Вектора, для посмотреть самому... точно, и на разряде А4 данные замусорены... хотя этот разряд не замыкался.
С участием А6, только замыкание А4 и А6 даёт верный результат.
Понять причину пока не могу...
На текущий момент, при интерпретации результатов теста, можно сделать оговорку: если указано, что замкнуто 3 разряда, и среди них есть А6, А4 и Ах, то скорее всего А4 - фантомное замыкание, и закорочены А6 с Ах...
Правда я не наглел, и более двух разрядов шины адреса пока не коротил на своём компе...
- - - Добавлено - - -
Кстати, ещё размышления по поводу теста...
Если есть "битые" микросхемы ОЗУ, то не корректным будет и анализ на замыкание разрядов шины адреса.
Результат анализа 7 бит, так как шина адреса на микросхемах всего 7 разрядов.
Результат можно спокойно выводить на разъём "ПУ", достаточно одного порта 7 бит.
А если обнаружатся проблемы при предварительной проверке на исправность ОЗУ, то обозначить это индикатором РУС/ЛАТ.
Пробую вывести результат теста ОЗУ, который предшествует тесту на замыкание разрядов шины адреса.
Поскольку на рабочее поле выводить результат бесполезно, подумал вывести положение "битой" микросхемы на бордюр.
Во вложении скриншот (из эмулятора) симуляции наличия "битой" микросхемы: четвёртая снизу, второй банк (колонка).
Из за ограниченного количества свободных регистров, и отказа от использования ОЗУ для хранения данных, получается вывести инфу только на один банк микросхем.
Т.е. при наличии "битых" микросхем в разных банках (колонках), за один тест можно отобразить найденную проблему только в одном банке, после устранения проблемы, повторный тест покажет "битые" микросхемы другого банка.
Хотя наверное можно например опрашивать клаву, и нажимая клавиши "1", "2", "3", "4" - перезапускать тест с проверкой конкретного банка и соответственно поочерёдно увидеть состояние всех банков микросхем.
Надо это переварить.
Пока так как есть. по одному банку за раз.
Добавил в тест опрос клавы.
Получилось два варианта поведения, даже три.
1. Тестируется первый банк ОЗУ, тест прекращается и выводится результат, не зависимо от того, были обнаружены ошибки или нет.
Далее по нажатию клавиш "1", "2", "3", "4" - можно запустить отдельно тест каждого из банков микросхем.
При этом по клавише "0" начнётся тестирование разрядов шины адреса ОЗУ только после проверки всех банков микросхем и при отсутствии проблем.
2. Тестируются все банки микросхем последовательно, при отсутствии проблем, сразу переходит на тест разрядов шины адреса.
При обнаружении проблем в тесте одного из банков микросхем, тест прекращается, выводится результат тестирования проблемного банка.
Далее по нажатию клавиш "1", "2", "3", "4" - можно запустить тесты других банков. Если при тестировании выбранного банка нет проблем, сразу тестируется следующий банк, и так до последнего. Не зависимо от результата тестирования 4го банка, тест останавливается, так как в предыдущих тестах были обнаружены проблемы.
3. Аналог второго варианта, только тестирование банков зациклено.
Если к примеру, во 2ом банке микросхем была проблема, и был запущен тест 3го банка, то при положительных результатах тестирования 3го и 4го банка, тест снова начнет проверку 1го банка, затем 2го - на нём снова остановится.
Вот сижу, думаю, какой вариант понятнее, удобнее...
Если кому-то интересно, запустить тесты, покрутить, помочь решить, какой удобнее, то могу выложить эти варианты, в тестовых версиях, для запуска в эмуляторе, с симулированными ошибками ОЗУ, и без них.
Удобнее был бы автоматический тест всех банков, но очевидно не хватает регистров и озу нельзя использовать. Можно сделать полный автоматический тест с использованием 15 состояний.
0. Тестируем банк 1, если нет ошибок - переход в состояние 1, если есть - в состояние 2.
1. Тестируем банк 2, если нет ошибок - переход в состояние 3, если есть - в состояние 4.
2. Тестируем банк 2, если нет ошибок - переход в состояние 5, если есть - в состояние 6.
...
7. Все банки работают правильно.
...
14. Все банки работают неправильно.
Нумерация состояний конечно может быть другая.
Т.е. тут информацию о состоянии теста несет адрес выполняемой части программы.
Удобнее был бы автоматический тест всех банков,
...
7. Все банки работают правильно.
...
14. Все банки работают неправильно.
Нумерация состояний конечно может быть другая.
Т.е. тут информацию о состоянии теста несет адрес выполняемой части программы.
А что потом с этими состояниями делать?
Сейчас, при обнаружении сбоя, бордюром указывает на конкретные микросхемы, из которых считалось не то, что в них записывалось.
А номер состояния, что покажет?
Фактически 15 состояний это 4 бита, банков тоже 4. У меня сейчас итак есть флаги для каждого банка, указывающие проверен он или нет, есть в нём сбой или нет. На основании анализа этих флагов, принимается решение, тестировать разряды шины адреса, или это бесполезно, так как с ОЗУ обнаружены проблемы.
Кстати, в доках на ВВ55 прочитал, что при настройке портов на выход, у них есть регистры-защелки, т.е. что записал в порт, то из него и прочитаешь.
В эмуляторе это работает, осталось на реале испытать. ;)
Если использовать порты ВВ55 для хранения результатов тестирования банков, то вполне можно иметь в наличии инфу о сотоянии всех 32ух микросхем. Только как их отобразить, на экран нельзя, бордюром получается только один банк за раз. Либо полоски будут слишком мелкие, считать и идентифицировать микросхемы замаисся.
Я пытался выводить на левый бордюр один банк, на правый другой... но в 192 такта не укладываюсь, у меня получается перебор примерно на 16 тактов.
Да и толку с вывода на экран двух банков, нужно ведь выводить инфу о 4ёх.
Думал, что проблема больше в сохранении информации об ошибках до момента отображения. Если проблема больше в отображении, то можно чередовать отображение ошибок, например показывать каждый банк по 5 (или не 5, а сколько удобнее) секунд, потом следующий и потом по кругу. Еще можно цветом, но это, понятное дело, только для подключения в цвете.
Порты ВВ55 настроенные на вывод читаются, почему же не будут, это проверяли.
Думал, что проблема больше в сохранении информации об ошибках до момента отображения. Если проблема больше в отображении, то можно чередовать отображение ошибок, например показывать каждый банк по 5 (или не 5, а сколько удобнее) секунд, потом следующий и потом по кругу. Еще можно цветом, но это, понятное дело, только для подключения в цвете.
Порты ВВ55 настроенные на вывод читаются, почему же не будут, это проверяли.
Ну так первый вариант, это и обеспечивает. Какую кнопку нажал, состояние того банка и увидел. И не моргает, есть время записать, отметить.
Про ВВ55, хорошо, что проверяли и работает, значит есть запас ещё два регистра/байта. :)
есть запас ещё два регистра/байта.
По максимуму можно использовать 4 порта: порт C системной ВВ55 и порты A, B, C ПУшной. Порты A и B системной придется оставить, чтобы нормально показывать на экране (и опрашивать клавиатуру).
- - - Добавлено - - -
Хотя пожалуй я погорячился, если опрашивать клавиатуру, то порт C системной отпадет (т.к. при смене режима ВВ55 он будет обнуляться) и останется 3 ПУшных.
По максимуму можно использовать 4 порта: порт C системной ВВ55 и порты A, B, C ПУшной. Порты A и B системной придется оставить, чтобы нормально показывать на экране (и опрашивать клавиатуру).
Хотя пожалуй я погорячился, если опрашивать клавиатуру, то порт C системной отпадет (т.к. при смене режима ВВ55 он будет обнуляться) и останется 3 ПУшных.
Да, точно, спасибо за напоминание, если клаву не опрашивать, значение скролинга в данной ситуации не актуально, и системный порт скролинга вполне сойдёт для хранения данных.
Если использовать порты для хранения результатов тестирования банков, то похоже укладываюсь по тактам, чтобы отобразить на бордюрах одновременно все 4 банка, два справа, и два слева.
Буду пробовать.
Засунул состояние банков микросхем ОЗУ в порты, вывел одновременно все четыре банка на бордюры. Отпала необходимость сканить клаву.
Можно сказать, что определился с выводом на экран результата тестирования.
Сейчас нужно вырезать из теста весь дебагерный код, не повредив основной.
В прицепе картинки, вывод банков на бордюры при (эмулированом) наличии "битых" микросхем ОЗУ.
Положение "битой" микросхемы в банке снизу, соответствует номеру банка микросхем.
Если с ОЗУ проблемы не выявлены, то выполняется тест разрядов шины адреса.
И вторая картинка, это разряды шины адреса, по идее А0-внизу, А6-вверху. На картинке проблем с шиной нет, по идее, замкнутые между собой разряды будут отмечены чёрным цветом.
Тут бордюры равны по значению, хотя для приколу, можно выводить результат теста шины адреса только на один бордюр.
На всякий случай еще стоит проверить в начале минимальную исправность ВВ55, читается ли из порта записанное значение.
На всякий случай еще стоит проверить в начале минимальную исправность ВВ55, читается ли из порта записанное значение.
Конструктивное замечание.
Добавил тест портов: 3h, 5h, 6h, 7h.
Как обычно, при обнаружении проблем, вывод результата на бордюр.
Расположение соответственно: нижняя полоса для 3h, верхняя - 7h.
Во вложении скриншот с эмуляцией обнаружения проблемы у порта 5h.
Наконец подобрал алгоритм идентификации замыкания разрядов шины адреса.
Корректно определяет замкнутые разряды.
Замыкал 2, 3, 4 разряда шины адреса ОЗУ... хоть в кучу, хоть парами, результат корректный.
Осталось убедиться, что первичный тест ОЗУ, корректно указывает "битую" микросхему (при её наличии) на плате. Но уж очень не хочется дорожки резать. :(
Может у кого-то на реале есть микросхемы ОЗУ в панельках, для проведения полевых испытаний теста?
И так как тест работает из ПЗУ, кроме ОЗУ в панельке, должно быть ещё и ПЗУ загрузчика сменное. ;)
Для случая, когда нет изображения или синхры, добавил вывод результатов на магнитофонный выход.
С самого магнитофонного выхода не пробовал смотреть, но с 14 вывода ВВ55 логером инфа снимается.
Вывод в виде импульсов разной ширины.
Широкий (24мкс-26мкс) - к элементу претензий нет.
Узкий (14мкс-17мкс)- обнаружена ошибка.
4 импульса в пакете - неисправен ВВ55, порты с номерами 5h,6h,7h,3h.
В примере - ошибка при тестировании порта 6h.
4 пакета по 8 импульсов - обнаружена ошибка при тестировании ОЗУ. Каждый из пакетов - банк ОЗУ, первый импульс в пакете - нижняя микросхема в банке.
В примере - ошибка микросхем в каждом банке, в первом - нижняя, во втором - вторая снизу, и т.д.
7 импульсов - обнаружено замыкание разрядов шины адреса. Первый импульс - А6, последний А0. Разряды соответствующие коротким импульсам, скорее всего, замкнуты между собой, или на сторонние сигналы.
В примере - замкнуты разряды шины адреса А1 и А2.
Во вложении архив с описанием получившегося теста (портов, ОЗУ, шины адреса ОЗУ) и подборкой скриншотов, с примерами ошибок при тестировании.
Ещё раз обращаю внимание, тест предназначен для работы только из ПЗУ, установленной на место ПЗУ загрузчика.
Сама программа теста в файле с расширением ".epr"
Для реальщиков должен быть очень полезный тест, здорово. Немного моего обычного занудства - "Если тесты прошли без оштбок, на бордюре будет 6 светлых (желтых) полос." - все же 7 полос.
Возможно в будущем его стоит дополнить. Можно протестировать еще 2 порта системной ВВ55 (1-2) и таймер и тогда практически полный охват основных БИС. Кстати, еще можно считать контрольную сумму или CRC пзу.
... 6 светлых (желтых) полос." - все же 7 полос.
Спасибо. Исправил, заменил.
Возможно в будущем его стоит дополнить. Можно протестировать еще 2 порта системной ВВ55 (1-2) и таймер и тогда практически полный охват основных БИС. Кстати, еще можно считать контрольную сумму или CRC пзу.
Пока о таком не думал. Тут главный тест самого критичного - шины адреса ОЗУ, и сопутствующего.
Тест и так уже потянул на 1.5Кило, хорошо, что влез в размер стандартного (для .02) ПЗУ. ;)
Первые боевые испытания теста шины адреса на Векторе .02.
Откопал Вектор, который был в ремонте ещё со средины 90-ых. Состояние страшное, я в те времена уже поменял на нём несколько микросхем.
Поменял ПЗУ, запустил тест. После обновлений экрана, фон остался светлым, на бордюре ни одной полосы, пищалка - нудно скулит.
А по идее фон должен быть чёрным и на бордюре полосы.
Осциллогафом глянул вывод 14 ВВ55, и увидел 7 "широких" импульсов... значит сам Вектор работает и ошибок ОЗУ не находит.
Замкнул на ОЗУшке разряды шины адреса, перезапустил тест и на бордюре появились чёрные полосы (без светлых).
После размышлений, дошло, что "видеоконтроллер" Вектора просто не отображает одну из плоскостей...
Дошел осликом до одной из ИР10, заменил её и полосы на бордюре появились, и фон почернел.
Хоть по прямому назначению тест ничего не нашел, но навёл мысль о причине неисправности.
Получается, что импульсы на ВВ55 (результаты тестов) можно и осликом посмотреть. Правда в случае проблем с микросхемами ОЗУ, там будет 32 импульса, возможно отличить "короткий" от "длинного" на экране ослика будет сложно.
Тест очень крутой. Предыстория. Вектор 06ц.02, перестал работать. При включении вот такая картинка:
https://pic.maxiol.com/thumbs2/1708410328.3568328436.whatsapp2024022009.jpg (https://pic.maxiol.com/?v=1708410328.3568328436.whatsapp2024022009.jpg&dp=2)
Тестирование показало битую рушку, заменил, стало останавливаться на ошибке на ША по линии А4. При тестировании вот такая картинка (в процессе):
https://pic.maxiol.com/thumbs2/1708410419.3568328436.whatsapp2024022009.jpg (https://pic.maxiol.com/?v=1708410419.3568328436.whatsapp2024022009.jpg&dp=2)
Методом научного тыка и изучения схемы набрел на 155КП2, которую заменил и Вектор завелся!!! правда у этого вектора настолько безобразная плата, что дорожки отскакивают не то что от температуры, а от одного вида паяльника, и пришлось несколько раз пропаивать, ставить МГТФ вместо 2х отлетевших дорожек.
Комп проработал где-то полчаса, был замечен в нестабильной работе по портам ПУ, но это другая история... и опять показал картинку выше!!! Еще раз внимательно под лупой изучил место замены КП2, еще раз пропаял - работает! буквально несколько минут и опять не работает... Основная сложность в том, что осциллографом я не вижу проблемы в сигнале А4 - визуально он такой же, как и все остальные адресные линии... Вопрос - как тестируется ША? какой порядок диагностики?
чую, что там сопля или непропай, потому что плохо верю, что вторая 155КП2 умерла в прямом эфире с такими же симптомами, да и второй замены КПшки эта плата если и переживет, то будет вермишель из МГТФа как на макетке(((
... Вопрос - как тестируется ША? какой порядок диагностики?
чую, что там сопля или непропай, потому что плохо верю, что вторая 155КП2 умерла в прямом эфире с такими же симптомами, да и второй замены КПшки эта плата если и переживет, то будет вермишель из МГТФа как на макетке(((
Точки на экране второго скрина, вроде такого не должно быть.
Тест ША: по "ключевым" адресам записываются "маркеры", для каждого разряда есть своя пара "маркеров", а потом маркеры считываются и анализируются.
Если из "ключевого" адреса считан чужой "маркер", который должен находиться по другому адресу, то есть замыкание между разрядами ША.
Если "маркер" из пары конкретного разряда шины, но не на своём месте, то этот разряд шины:
1. в обрыве.
2. замкнут на "+" питания.
3. замкнут на "общий" питания.
Замыкание на питание, может быть не полным, достаточно "подтяжки". На осциллогафе это видно как не характерная амплитуда, "максимум" чуть не дотягивает до напряжения питания, или "минимум" не достаёт до "0".
На скринах, экран разделён на 4 горизонтальных полосы. Я бы предположил, что это разряд ША А6 (общей шины) подтянут к "1". Хотя я сейчас не помню, объединяется ли А6 мультиплексором с каким-то другим разрядом, или нет. Надо схему смотреть.
Глянул схему, А6 (общей шины) как-раз соответствует А4 ША ОЗУ.
Значит скорее всего А4 ША ОЗУ подтянута к "+" питания. Нужно искать "соплю" между "А4" и "+".
Есть сомнения по поводу моих выводов.
Так как А4 ОЗУ, это А6 и А12 общей шины, то при замыкании А4 на "+", скорее всего картинка на экране будет другая.
Получается, что А6 не доходит до КП2.
Можно попробовать, кинуть перемычку D1 32 нога - D8 3 нога.
Да, проблема была в том, что A6 общей шины не доходила до КП2... исправил, заработало)) спасибо))
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot