[ViKo 1]

Вот столкнулся с некачественной пайкой шин адреса (18 битов) или данных (16 битов), я так думаю. Не вижу, где. Тот тест, что имелся, просто сигналит, что не пройден. У меня просто младшая часть адреса записывалась, а потом читалась. В-общем, если все нормально, то тест проходил. Примитивно. Хочу сделать правильный тест, более информативный. Определить, где адрес или данные неправильные и выдать текстом в последовательный порт. Кто-нибудь делал подобное? Поделитесь соображениями или ссылками.

 

 

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

[Raven 8]

Тема практически необъятная, но для начала разговора:

 

Простой, быстрый, но хорошо проверяющий "на элементарную вшивость" тест памяти - адресный тест. В ячейку памяти с адресом "ADDR" пишется значение самого этого адреса (значение "ADDR"). После write-прохода делается read-проход и контроль. Неплохо выявляет залипания/неконтакты линий адреса (в первую очередь).

 

А дальше - тесты с паттернами данных 0x0, 0xFF, 0x55, 0xAA, марш 1, марш 0 и т.д. и т.п. (разных тестов уйма).

[ViKo 1]

Адрес я и писал. Нужно проверять не просто совпадение записанного и прочитанного, но выдавать, в чем не совпало и почему.

[Raven 8]

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

- адрес ячейки;

- ожидаемое значение;

- актуальное значение.

 

Тестирующий далее включает устройство под названием мозг (или "моск" - это уж у кого как :-)), анализирует и делает выводы. Возможно, еще что-то допроверяет-дотестирует. Или у вас задача стоит - пусть "вкалывают роботы, а не человек" ? :)

[ViKo 1]

Да, второго хочу. :-) Раз напрячься, потом гуляючи...

[AnatolyT 0]

тут контроль шины, устанавливаем все биты шины адреса в 1, последовательно переводим в 0 каждый бит шины, проверяем состояние шины;

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

[ViKo 1]

Да, правильно, не память проверяется, а шины, в первую очередь.

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

[k155la3 26]

тут контроль шины, устанавливаем все биты шины адреса в 1, последовательно переводим в 0 каждый бит шины, проверяем состояние шины;

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

(+)

я подобным образом проверял подключенность шины I2C.

Если в контроллере есть возможность включения pull up/down подтяжек по входам,

то легко организуетя (само)проверка на замыкания линий шины между собой и на другие проводники.

[_Thomas_ 0]

Кто-нибудь делал подобное?

Делал так: пишем везде 0x0000... (по размеру слова) проверяем, потом с 0xffff, потом 0x5555, потом 0xaaaa, 0x55aa, и запись псевдо-случайной последовательности и потом её же, но инвертированной

 

[ViKo 1]

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

[iosifk 3]

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

Если у того, кто подключен к памяти, есть порт JTAG, то посмотрите на тему "JTAG-сканирование"... Например, программы от jtag-технолоджи не только покажут "что", но и на чертеже платы покажут "где"... И эти тесты действительно проверяют только припайку. А если у ОЗУ есть JTAG, то это вообще влет...

 

[ViKo 1]

Если у того, кто подключен к памяти, есть порт JTAG, то посмотрите на тему "JTAG-сканирование"... Например, программы от jtag-технолоджи не только покажут "что", но и на чертеже платы покажут "где"... И эти тесты действительно проверяют только припайку. А если у ОЗУ есть JTAG, то это вообще влет...

Да, спасибо, это тоже имею в виду на будущее. Но шинах есть STM32, но его JTAG-сигналы я на разъем не выводил.

[_Thomas_ 0]

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

Я это понял. При логировании ошибок (что должно быть, что на самом деле, адрес) и небольшом анализе логов нескольких прогонов - выявление коротышей/непропая задача довольно-таки тривиальная.

[ViKo 1]

Я это понял. При логировании ошибок (что должно быть, что на самом деле, адрес) и небольшом анализе логов нескольких прогонов - выявление коротышей/непропая задача довольно-таки тривиальная.

Пока одна закоротка - да. А если две - уже не так просто.

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

[iosifk 3]

Пока одна закоротка - да. А если две - уже не так просто.

Ну тогда берем "Адрес" и в эту ячейку пишем "Данные". А "Данные" вычисляем как код Хемминга, дополняющий "Адрес"... Тогда можно прочесть из "откуда-то" либо полностью неправильные данные, если есть ошибка в "Адресе", либо неправильные "данные", но из требуемой ячейки. И по ним можно вычислить ошибку в битах шин данных. Соотв. можно записать такие же данные, но по "Адресам", имеющим ошибку. Тогда при чтении из этих адресов, можно вычислить ошибку шины адреса. Ну например, можно предположить, что А1 будет замкнут на 1. Тогда записывая коды в адреса с А1=0, мы при чтении, предполагая, что А0=0, на самом деле прочитаем эти коды из ячеек у которых А0=1. И вот тут если шины данных исправны, можно вычислить неисправность адреса....