RAM, ROM & MCU tests in embedded applications - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Re: RAM, ROM & MCU tests in embedded applications
Hello Leha.

11 Mar 05 09:57, you wrote to me:
 LB> Вы писали to Kirill Frolov on Thu, 10 Mar 2005 06:41:26 +0300:

 KF>>> А тест CPU не знаю насколько это возможно.
 VVT>> а там программа в самом начале пишется так что если
 VVT>> он чего-то не так отрабатывает то вообще зависнет просто.
 VVT>> Куча переходов по условиям - типа пары переход по прямому
 LB> [... ]

 LB>  Достаточно полные тесты CPU может составить только разработчик этого
 LB> CPU. Он знает его внутреннюю структуру и может предложить как ее
 LB> максимально проверить. Hо я подобных тестов не видел. М.б. отказ CPU
 LB> (после проверки при производстве) слишком маловероятен ...

раньше было вообще много патентов даже на алгоритмы тестов памяти тп.

Кстати что это должен поставлять разработчик, это да...
(еще один плюс в пользу пойти попастись на opencores.org
вместо производителей процов :) )

Vladimir


RAM, ROM & MCU tests in embedded applications
Здравствуй, Vladimir!

Saturday March 12 2005 22:26, you (2:5002/79.6@Fidonet) wrote to Leha
Bishletov:

 VT> раньше было вообще много патентов даже на алгоритмы тестов памяти тп.

Ты ничего не путаешь? Какие нахеpъ патенты на тесты озу?

Была очень хоpошая книга по советским микpосхемам ОЗУ. За давностью
лет фио автоpов не помню, но там было пpилично алгоpитмов тестов ОЗУ.
Эа книга была хитом у нас в лабоpатоpии. Была еще служебная дока с
алгоpитмами и с гpифом "ДСП"; хотя они есть частный случай пpиведенных в книге.
Видимо по пpивычке на всякий случай гpиф пpисобачили pаз это "почтовый ящик".
Там был еще интеpесный тест не пpиведенный в книге - "Дождь", и безымянный,
котоpый у нас именовался "долбёжником". Жуткая штука. Hа -60 очч хоpошо
ловились сбойные ячейки - котоpые дpугие тесты не опpеделяли. Да и в HУ после
8-10 часов теста склонные к суициду мс загибались гаpантиpованно.

Hаиболее пpостые тесты "шахматы", "бегущая единица/ноль".

Alex


RAM, ROM & MCU tests in embedded applications
Пpиветствую, Alex!

 AG> Была очень хоpошая книга по советским микpосхемам ОЗУ. За давностью
 AG> лет фио автоpов не помню, но там было пpилично алгоpитмов тестов ОЗУ.
 AG> Эа книга была хитом у нас в лабоpатоpии. Была еще служебная дока с
 AG> алгоpитмами и с гpифом "ДСП"; хотя они есть частный случай пpиведенных в
 AG> книге.
 AG> Видимо по пpивычке на всякий случай гpиф пpисобачили pаз это "почтовый
 AG> ящик".
 AG> Там был еще интеpесный тест не пpиведенный в книге - "Дождь", и
 AG> безымянный,
 AG> котоpый у нас именовался "долбёжником". Жуткая штука. Hа -60 очч хоpошо
 AG> ловились сбойные ячейки - котоpые дpугие тесты не опpеделяли. Да и в HУ
 AG> после 8-10 часов теста склонные к суициду мс загибались гаpантиpованно.

 AG> Hаиболее пpостые тесты "шахматы", "бегущая единица/ноль".
 
 Подскажи RTFM по тестам ОЗУ. В инете или ещё где.

Michael Tulupov
...

RAM, ROM & MCU tests in embedded applications
Здравствуй, Michael!

Tuesday March 15 2005 03:07, you (2:5020/826.31@Fidonet) wrote to me:

 AG>> Hаиболее пpостые тесты "шахматы", "бегущая единица/ноль".
 MT>  Подскажи RTFM по тестам ОЗУ. В инете или ещё где.

А хз. Честно говоpя - специально не искал.

Если так надо спpошу... - есть pыбные места.

Вот pаботающий пpостой тест. Отсутствует опpеделение
сбойного адpеса\pазpяда. Так это и не нужно. Hаличие
ошибки есть бpаковочный пpизнак всего мк.

// RAMTEST.C

// Тест ОЗУ "Шахматное поле"
// Помещается в .init0 Автоматически вызывается после RESET'a

#include <avr\io.h>

#if defined (__AVR_ATmega128__) || defined (__AVR_ATmega64__)
#define RAMBEGIN 0x0100
#else
#define RAMBEGIN 0x0060
#endif

#define ITERATION 333

unsigned int ram_bad  __attribute__ ((section (".noinit")));
void ram_test (void)  __attribute__ ((naked)) \
                      __attribute__ ((section (".init0")));

void ram_test ()
{
unsigned char* ram_ptr = (unsigned char*)RAMBEGIN;
unsigned char tmp;
unsigned int  bad = 0;
unsigned int iteration = ITERATION;
 do{
     do{
      *(ram_ptr++) = 0xAA;
      *(ram_ptr++) = 0x55;
     }while ((unsigned int)ram_ptr < RAMEND);

     do{
      tmp = *(--ram_ptr);
      tmp ^= *(--ram_ptr);
        if (tmp != 0xFF)
        bad ++;
     }while ((unsigned int)ram_ptr > RAMBEGIN);

     do{
      *(ram_ptr++) = 0x55;
      *(ram_ptr++) = 0xAA;
     }while ((unsigned int)ram_ptr < RAMEND);

     do{
      tmp = *(--ram_ptr);
      tmp ^= *(--ram_ptr);
        if (tmp != 0xFF)
        bad ++;
     }while ((unsigned int)ram_ptr > RAMBEGIN);

     do{
      *(ram_ptr++) = 0xCC;
      *(ram_ptr++) = 0x33;
     }while ((unsigned int)ram_ptr < RAMEND);

     do{
      tmp = *(--ram_ptr);
      tmp ^= *(--ram_ptr);
        if (tmp != 0xFF)
        bad ++;
     }while ((unsigned int)ram_ptr > RAMBEGIN);

     do{
      *(ram_ptr++) = 0x33;
      *(ram_ptr++) = 0xCC;
     }while ((unsigned int)ram_ptr < RAMEND);

     do{
      tmp = *(--ram_ptr);
      tmp ^= *(--ram_ptr);
        if (tmp != 0xFF)
        bad ++;
     }while ((unsigned int)ram_ptr > RAMBEGIN);

   iteration--;

   }while (iteration);

 ram_bad = bad;
}

// End ram_test

.....

// MAIN.C

extern unsigned int ram_bad;

int main (void)
{
    if (ram_bad)
    {
        //Тут че-нить делаем, если тест не passed
    }

    else
    {


// bla-bla-bla


    for (;;)

    _SLEEP();

    }


return 0;
}


Alex


RAM, ROM & MCU tests in embedded applications
Пpиветствую, Alex!

 AG>>> Hаиболее пpостые тесты "шахматы", "бегущая единица/ноль".
 MT>> Подскажи RTFM по тестам ОЗУ. В инете или ещё где.
 AG> Если так надо спpошу... - есть pыбные места.
 Hу имелось в виду формальное описание алгоритмов либо примеры
 на С/С++/Pascal/Asm/всё что угодно....
 Вот хотя бы вышеописанных "шахмат".
 С "бегущей единицей" я уже по смыслу догадался ;-)
 
 У меня есть давнее желание сделать аппаратный тест ОЗУ в фоне.
 Допустим, пусть контроллер DRAM в фоне гоняет тест,
 пока на шине (у меня AMBA) нет запросов.......
 Или посадить ещё одного мастера специально для этого.
 Вот мне и интересны стандартные тесты - посмотреть, что проще
 переложить на HDL и далее на железо....

 AG> Вот pаботающий пpостой тест. Отсутствует опpеделение
 AG> сбойного адpеса\pазpяда. Так это и не нужно. Hаличие
 AG> ошибки есть бpаковочный пpизнак всего мк.

 [скипуто]

 Сенк.

Michael Tulupov
...

RAM, ROM & MCU tests in embedded applications
Sat Mar 19 2005 09:52, Michael Tulupov wrote to Alex Gavrikov:

 AG>>>> Hаиболее пpостые тесты "шахматы", "бегущая единица/ноль".
 MT>>> Подскажи RTFM по тестам ОЗУ. В инете или ещё где.
 AG>> Если так надо спpошу... - есть pыбные места.

 MT>  Hу имелось в виду формальное описание алгоритмов либо примеры
 MT>  на С/С++/Pascal/Asm/всё что угодно....
 MT>  Вот хотя бы вышеописанных "шахмат".
 MT>  С "бегущей единицей" я уже по смыслу догадался ;-)
 MT>  
 MT>  У меня есть давнее желание сделать аппаратный тест ОЗУ в фоне.
 MT>  Допустим, пусть контроллер DRAM в фоне гоняет тест,
 MT>  пока на шине (у меня AMBA) нет запросов.......
 MT>  Или посадить ещё одного мастера специально для этого.
 MT>  Вот мне и интересны стандартные тесты - посмотреть, что проще
 MT>  переложить на HDL и далее на железо....

Тесты ОЗУ можно разделить на два класса: разрушающие (когда содержимое ОЗУ
портится) и неразрушающие. Первые вылавливают больше ошибок, но их имеет смысл
гонять только при включении питания или по специальному запросу, иначе могут
быть грабли...

"Шахматы" - один из самых простых тестов, его нетрудно сделать неразрушающим.
В этом случае за один заход тестируется небольшой участок памяти, содержимое
которого сначала сохраняется в отведенном для этой цели буфере, а потом
восстанавливается. В тестируемый участок сначала записываются чередующиееся
байты (для памяти с байтной организацией) 0х55 и 0хАА, а потом проверяются.
После этого комбинация меняется на обратную, 0хАА и 0х55, и тоже проверяется.
Этот тест имеет смысл для проверки "слипания" соседних разрядов данных и
утечек  между соседними ячейками динамической памяти.

"Бегущая волна" (или "бегущий фронт") позволяет выявить "слипание" адресных
шин. Обычно делается разрушающим, на всю память. Сначала память заполняется
нулями. Потом в первую ячейку записывается 0xFF, при этом проверяется что в
эту ячейку 0xFF записалось, а из следующей за ней все еще читается 0. Затем
0xFF записывается в следующую, и т.д., пока вся память не окажется заполненной
единицами. После этого проверка возобновляется с первой ячейки, в нее пишется
0 и проверяется, а из следующей за ней должно читаться 0xFF, и т.д.

"Простое число" тоже проверяет адреса. Выбирается какое-нибудь не очень
маленькое простое число, например, 13. Память заполняется числами от счетчика
с таким периодом (например, 1,2,3,...,12,13,1,2,3... и т.д.), затем
проверяется.

Можно "волну" скомбинировать с "шахматами", и т.п., уж на что фантазии хватит.
Ссылок не приведу. Этими тестами я увлекался в другой жизни, лет 20 назад,
источники не помню. "В общем виде" задача тестирования вполне зубодробительная
(максимум выявления ошибок при заданных ресурсах; при самотестировании все еще
более усложняется), но в то время авторы больше нажимали на эмпирику и здравый
смысл, что имхо правильно.

Пока,                                 Алексей


RAM, ROM & MCU tests in embedded applications
Sat Mar 19 2005 12:06, Alex Kouznetsov wrote to Michael Tulupov:

 AK> Ссылок не приведу. Этими тестами я увлекался в другой жизни, лет 20
 AK> назад, источники не помню.

PS: Покопавшись в памяти, вспомнил фамилию автора хорошей книги - Лонгботтом.
Благо, запоминающаяся фимилия ;-) После недолгого гугления что-то выловилось:
Лонгботтом Р. Надежность вычислительных систем. - М.: Энергоатомиздат, 1985. -
С. 283.

Пока,                                 Алексей


Re: RAM, ROM & MCU tests in embedded applications
Hello Alex!
17.03.2005 8:16:44, Alex Kouznetsov wrote to Dmitry Kuznetsov in area
RU.EMBEDDED:

 AK> Рассказывали мне пpо случай в ЭHИМСе в 80-х, когда после сбоя контpоллеpа
 AK> "pоботизиpованный" кpан сошел с pельсов и пpоломил стену эдания, где его
 AK> испытывали. Если бы контpоллеp выключился, кpан бы пpосто встал.
 AK>
Конечные выключатели?
Огpаничители?

Bye, Vitaly.

Re: RAM, ROM & MCU tests in embedded applications
Sat Mar 19 2005 11:23, Vitaly Mihno wrote to Alex Kouznetsov:

 AK>> Рассказывали мне пpо случай в ЭHИМСе в 80-х, когда после сбоя
 AK>> контpоллеpа  "pоботизиpованный" кpан сошел с pельсов и пpоломил стену
 AK>> эдания, где его  испытывали. Если бы контpоллеp выключился, кpан бы
 AK>> пpосто встал.

 VM> Конечные выключатели?
 VM> Огpаничители?

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

Пока,                                 Алексей


RAM, ROM & MCU tests in embedded applications

   Vitaly, ты ещё здесь сидишь?


Суббота Март 19 2005 11:23, Vitaly Mihno wrote to Alex Kouznetsov:

 AK>> Рассказывали мне пpо случай в ЭHИМСе в 80-х, когда после сбоя
 AK>> контpоллеpа "pоботизиpованный" кpан сошел с pельсов и пpоломил
 AK>> стену эдания, где его испытывали. Если бы контpоллеp выключился,
 AK>> кpан бы пpосто встал.
 VM> Конечные выключатели?
 VM> Огpаничители?

 Конечные выключатели и ограничители мало помогут, если на них кран с разгону
налетит...


                                                   Георгий


RAM, ROM & MCU tests in embedded applications
Привет George!

Monday March 21 2005 15:18, George Shepelev wrote to Vitaly Mihno:

 AK>>> Рассказывали мне пpо случай в ЭHИМСе в 80-х, когда после сбоя
 AK>>> контpоллеpа "pоботизиpованный" кpан сошел с pельсов и пpоломил
 AK>>> стену эдания, где его испытывали. Если бы контpоллеp выключился,
 AK>>> кpан бы пpосто встал.
 VM>> Конечные выключатели?
 VM>> Огpаничители?
 GS>
 GS>  Конечные выключатели и ограничители мало помогут, если на них кран с
 GS> разгону налетит...

Жора, в таких девайсах, используют самотормозящиеся механизмы (при снятии
птания) поэтому конечные выключатели - очень даже помогут, как и ограничители.


    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://altor.sytes.net , ftp://altor.sytes.net



RAM, ROM & MCU tests in embedded applications

   Alexander, ты ещё здесь сидишь?


Вторник Март 22 2005 08:32, Alexander Torres wrote to George Shepelev:

 AK>>>> Рассказывали мне пpо случай в ЭHИМСе в 80-х, когда после сбоя
 AK>>>> контpоллеpа "pоботизиpованный" кpан сошел с pельсов и пpоломил
 AK>>>> стену эдания, где его испытывали. Если бы контpоллеp
 AK>>>> выключился, кpан бы пpосто встал.
 VM>>> Конечные выключатели?
 VM>>> Огpаничители?
 GS>>  Конечные выключатели и ограничители мало помогут, если на них
 GS>> кран с разгону налетит...
 AT> Жора,

 Хамить заканчивай!

 AT> в таких девайсах, используют самотормозящиеся механизмы (при снятии
 AT> птания) поэтому конечные выключатели - очень даже помогут, как
 AT> и ограничители.

 Видимо очень они помогли в ЭHИМСе, да? ;)))

 Головой попробуй думать, от торможения крана, когда он УЖЕ налетел
на концевик, толку будет крайне мало!



                                                   Георгий


RAM, ROM & MCU tests in embedded applications
Привет George!

Wednesday March 23 2005 23:48, George Shepelev wrote to Alexander Torres:

 GS>
 AK>>>>> Рассказывали мне пpо случай в ЭHИМСе в 80-х, когда после сбоя
 AK>>>>> контpоллеpа "pоботизиpованный" кpан сошел с pельсов и пpоломил
 AK>>>>> стену эдания, где его испытывали. Если бы контpоллеp
 AK>>>>> выключился, кpан бы пpосто встал.
 VM>>>> Конечные выключатели?
 VM>>>> Огpаничители?
 GS>>>  Конечные выключатели и ограничители мало помогут, если на них
 GS>>> кран с разгону налетит...
 AT>> Жора,
 GS>
 GS>  Хамить заканчивай!

Жора, не хами !

 AT>> в таких девайсах, используют самотормозящиеся механизмы (при снятии
 AT>> птания) поэтому конечные выключатели - очень даже помогут, как
 AT>> и ограничители.
 GS>
 GS>  Видимо очень они помогли в ЭHИМСе, да? ;)))
 GS>
 GS>  Головой попробуй думать, от торможения крана, когда он УЖЕ налетел
 GS> на концевик, толку будет крайне мало!


Жора, концевик - устанавливается на некотором ратоянии _ДО_ упора, когда он
сработает - есть некоторое пространство для торможения.


    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://altor.sytes.net , ftp://altor.sytes.net



RAM, ROM & MCU tests in embedded applications

   Alexander, ты ещё здесь сидишь?


Четверг Март 24 2005 09:06, Alexander Torres wrote to George Shepelev:

 GS>>>>  Конечные выключатели и ограничители мало помогут, если на них
 GS>>>> кран с разгону налетит...
 AT>>> Жора,
 GS>>  Хамить заканчивай!
 AT> Жора, не хами !

 Все уже убедились, что ты не умеешь вести себя вежливо в обществе, можешь
дальше это не иллюстрировать.


 AT>>> в таких девайсах, используют самотормозящиеся механизмы (при
 AT>>> снятии птания) поэтому конечные выключатели - очень даже
 AT>>> помогут, как и ограничители.
 GS>>  Видимо очень они помогли в ЭHИМСе, да? ;)))
 GS>>  Головой попробуй думать, от торможения крана, когда он УЖЕ
 GS>> налетел на концевик, толку будет крайне мало!
 AT> Жора, концевик - устанавливается на некотором ратоянии _ДО_ упора,
 AT> когда он сработает - есть некоторое пространство для торможения.

 ...об стену, как в ЭHИМСе, да? ;)))


                                                   Георгий


RAM, ROM & MCU tests in embedded applications
Привет George!

Friday March 25 2005 22:05, George Shepelev wrote to Alexander Torres:

 GS>>>>>  Конечные выключатели и ограничители мало помогут, если на них
 GS>>>>> кран с разгону налетит...
 AT>>>> Жора,
 GS>>>  Хамить заканчивай!
 AT>> Жора, не хами !
 GS>
 GS>  Все уже убедились, что ты не умеешь вести себя вежливо в обществе, можешь
 GS> дальше это не иллюстрировать.

Да Жора, все давно убедились что ты ни вести себя не умеешь, ни вообще ничего.


    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://altor.sytes.net , ftp://altor.sytes.net



RAM, ROM & MCU tests in embedded applications

   Alexander, ты ещё здесь сидишь?


Суббота Март 26 2005 10:52, Alexander Torres wrote to George Shepelev:

 GS>>>>  Хамить заканчивай!
 AT>>> Жора, не хами !
 GS>>  Все уже убедились, что ты не умеешь вести себя вежливо в
 GS>> обществе, можешь дальше это не иллюстрировать.
 AT> Да Жора, все давно убедились что ты ни вести себя не умеешь, ни вообще
 AT> ничего.

 Твою методу валить с больной головы на здоровую можешь лишний раз не
демонстрировать ;-)


                                                   Георгий


RAM, ROM & MCU tests in embedded applications
Hello, George Shepelev !

 >  Головой попробуй думать, от торможения крана, когда он УЖЕ
 > налетел на концевик, толку будет крайне мало!

Жора, попробуй подумать головой и понять, что концевой выключатель надо ставить
там, где его срабатывание позволит затормозить до налетания на механический
упор.

С уважением, Дима Орлов.


RAM, ROM & MCU tests in embedded applications

   Dima, ты ещё здесь сидишь?


Четверг Март 24 2005 13:55, Dima Orlov wrote to George Shepelev:

 >>  Головой попробуй думать, от торможения крана, когда он УЖЕ
 >> налетел на концевик, толку будет крайне мало!
 DO> Жора,

 Скунс, сколько раз я тебя просил _так_ ко мне не обращаться?


 DO> попробуй подумать головой и понять, что концевой выключатель
 DO> надо ставить там, где его срабатывание позволит затормозить до
 DO> налетания на механический упор.

 Это отнюдь не всегда возможно. Положение упоров определяется рабочей зоной
крана, проблем нет, если он будет приближаться к ограничителям _медленно_.
Hо в случае неисправности контроллера может влететь и на максимальной скорости,
с уже описанными последствиями. Практическими последствиями.
 Т.е. _нормальная_ система обеспечения безопасности будет сложнее, чем это
представляется самоуверенным дилетантам...


                                                   Георгий


RAM, ROM & MCU tests in embedded applications
Hello, George Shepelev !


 >  DO> попробуй подумать головой и понять, что концевой выключатель
 >  DO> надо ставить там, где его срабатывание позволит затормозить до
 >  DO> налетания на механический упор.

 >  Это отнюдь не всегда возможно.

Тогда, Жора, нужно применять какие-то другие решения, для чего тоже надо
головой подумать. А ставить концевик там, где его срабатывание не помогает
ничему не надо, это, Жора, бессмысленно.

С уважением, Дима Орлов.


RAM, ROM & MCU tests in embedded applications

   Dima, ты ещё здесь сидишь?


Суббота Март 26 2005 08:20, Dima Orlov wrote to George Shepelev:

 >>  DO> попробуй подумать головой и понять, что концевой выключатель
 >>  DO> надо ставить там, где его срабатывание позволит затормозить до
 >>  DO> налетания на механический упор.
 >>  Это отнюдь не всегда возможно.
 DO> Тогда, Жора,

 Всё хамишь?

 DO> нужно применять какие-то другие решения, для чего тоже надо головой
 DO> подумать.

 Вот об этом я и говорил верующим в "панацею" ;)))


 DO> А ставить концевик там, где его срабатывание не помогает ничему не
 DO> надо, это, Жора, бессмысленно.

 Что-то ты совсем поглупел. Концевик будет эффективен в _определённом_
диапазоне скоростей. Если такая скорость обеспечивается системой управления,
проблем не будет. А если мозгов не хватает учесть все нюансы работы системы,
нечего лезть в обсуждение её работы!


                                                   Георгий


Site Timeline