Hi all,
I'm trying to use the Michael Barr's memory testing algorithm (http://
www.netrino.com/Embedded-Systems/How-To/Memory-Test-Suite-C) but I'm
not completely satisfied of it.
Referring to the Address Bus test, I think that not all the address
bus fault can be detected by this algorithm...
For example, If you have more than one address line stuck high, you'll
not catch it. If you have two lines stuck together and the line that
goes to 1 drives high the other line, you'll not see it.
Am I wrong?

In order to catch all the address bus fault I modified Barr's
algorithm in this way:

datum *memTestAddressBus_Complete(volatile datum * baseAddress,
unsigned long nBytes)
{
    unsigned long addressMask = (nBytes/sizeof(datum) - 1);
    unsigned long offset;
    unsigned long testOffset;

    datum pattern     = (datum) 0xAAAAAAAA;
	 datum antipattern = (datum) 0x55555555;


	 for (testOffset = 1; (testOffset & addressMask) != 0; testOffset <<=
1)
	 {
		 MyPrintf((t_SIGN_BYTE *)"Controllo Offset: %h  ", testOffset);
		 /* Write the default pattern at each offsets. */
		 for (offset = 0; (((offset & addressMask) != 0) || (offset == 0));
offset++)
		 {
			 baseAddress[offset] = pattern;
			 uC_WDT_EXT^=1;
		 }

		 baseAddress[testOffset] = antipattern;
		 /* controllo se ho sporcato il resto */
		 for (offset = 0; (((offset & addressMask) != 0) || (offset == 0));
offset++)
		 {
			 if ((baseAddress[offset] != pattern) && (offset != testOffset))
			 {
				 return ((datum *) &baseAddress[testOffset]);
			 }
		 }
	 }


    return (0);

}   /* memTestAddressBus_Complete() */



This is quiet a "brute force" test and it's real slow, but it should
catch all the address bus errors. In a 80 MHz Renesas SH7058
microcontroller It takes almost 25 seconds to analyze an external
1MBytes SRAM.

Anyone have better ideas to implement an exhaustive test?
Thank you,

Matteo Canella

In article <a3e6303f-b149-40b1-bc59-
f...@r66g2000hsg.googlegroups.com>, M...@gmail.com 
says...
> Hi all,
> I'm trying to use the Michael Barr's memory testing algorithm (http://
> www.netrino.com/Embedded-Systems/How-To/Memory-Test-Suite-C) but I'm
> not completely satisfied of it.
> Referring to the Address Bus test, I think that not all the address
> bus fault can be detected by this algorithm...
> For example, If you have more than one address line stuck high, you'll
> not catch it. If you have two lines stuck together and the line that
> goes to 1 drives high the other line, you'll not see it.
> Am I wrong?
...

The simpleset Address BUS test is to use the incrememnting count written
to binary boundaries e.g

	Add	Data
	1	2
	2	3
	4	4
	8	5
	16	6
	....

Only use a boundary value you shift by one place within known memory
ranges.

The important bit is to

	Write all values
	Read a 'random' address in memory (not on binary boundary)
	read the values in REVERSE order

Becomes very simple loops even with offsets for RAM start points.

Because the write and read are separate and done in different orders
you avoid capacitive problems and catch all combinations or address line
short open-circuit etc..

You must have tested a single location with a full data pattern first to
check the data bus appears correct.


> This is quiet a "brute force" test and it's real slow, but it should
> catch all the address bus errors. In a 80 MHz Renesas SH7058
> microcontroller It takes almost 25 seconds to analyze an external
> 1MBytes SRAM.

Seems an excessive test to me, as you seem to be writing to every 
location in offset blocks, not the single address line boundaries.

If an address line is wrong how is writing to every location going to 
help? Especially if you stop at first error and don't do block analysis.
 
> Anyone have better ideas to implement an exhaustive test?
> Thank you,

Test each address line on its own first, then do more complex tests
test every location if you wish but NOT with the same pattern -
alternating, sliding '1' or '0', pseudo-random.

Any test writing and reading every single location WILL take time.
No way round it.
 
> Matteo Canella
> 

-- 
Paul Carpenter          | p...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>;    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/>; Timing Diagram Font
<http://www.gnuh8.org.uk/>;  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/>; For those web sites you hate

MrPink wrote:
> Hi all,
> I'm trying to use the Michael Barr's memory testing algorithm (http://
> www.netrino.com/Embedded-Systems/How-To/Memory-Test-Suite-C) but I'm
> not completely satisfied of it.
> Referring to the Address Bus test, I think that not all the address
> bus fault can be detected by this algorithm...
> For example, If you have more than one address line stuck high, you'll
> not catch it. If you have two lines stuck together and the line that
> goes to 1 drives high the other line, you'll not see it.
> Am I wrong?
> 
> In order to catch all the address bus fault I modified Barr's
> algorithm in this way:
> 
> datum *memTestAddressBus_Complete(volatile datum * baseAddress,
> unsigned long nBytes)
> {
>     unsigned long addressMask = (nBytes/sizeof(datum) - 1);
>     unsigned long offset;
>     unsigned long testOffset;
> 
>     datum pattern     = (datum) 0xAAAAAAAA;
> 	 datum antipattern = (datum) 0x55555555;
> 
> 
> 	 for (testOffset = 1; (testOffset & addressMask) != 0; testOffset <<=
> 1)
> 	 {
> 		 MyPrintf((t_SIGN_BYTE *)"Controllo Offset: %h  ", testOffset);
> 		 /* Write the default pattern at each offsets. */
> 		 for (offset = 0; (((offset & addressMask) != 0) || (offset == 0));
> offset++)
> 		 {
> 			 baseAddress[offset] = pattern;
> 			 uC_WDT_EXT^=1;
> 		 }
> 
> 		 baseAddress[testOffset] = antipattern;
> 		 /* controllo se ho sporcato il resto */
> 		 for (offset = 0; (((offset & addressMask) != 0) || (offset == 0));
> offset++)
> 		 {
> 			 if ((baseAddress[offset] != pattern) && (offset != testOffset))
> 			 {
> 				 return ((datum *) &baseAddress[testOffset]);
> 			 }
> 		 }
> 	 }
> 
> 
>     return (0);
> 
> }   /* memTestAddressBus_Complete() */
> 
> 
> 
> This is quiet a "brute force" test and it's real slow, but it should
> catch all the address bus errors. In a 80 MHz Renesas SH7058
> microcontroller It takes almost 25 seconds to analyze an external
> 1MBytes SRAM.
> 
> Anyone have better ideas to implement an exhaustive test?
> Thank you,
> 
> Matteo Canella

Hi Matteo,

Try googling for "march B" or "march C" memory tests.
These are the best I could find.


Regards,  Wim

WiMos <W...@philips.com> writes:
> Try googling for "march B" or "march C" memory tests.
> These are the best I could find.

And while googling anyway, add "march cw" to the list.

Regards
Marcus

-- 
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]

             (seen on http://www.veripool.com/verilog-mode_news.html)

On 19 Set, 11:34, Marcus Harnisch <marcus.harni...@gmx.net> wrote:
> WiMos <Wi...@philips.com> writes:
> > Try googling for "march B" or "march C" memory tests.
> > These are the best I could find.
>
> And while googling anyway, add "march cw" to the list.
>
> Regards
> Marcus


I saw this "March" based algorithm (and the not so simple theory
behind them) , but I thought they are used for memory tests over the
single bit cell. (i.e. used es EOL test by ram chip manufacturer).
Do you think they are good also to perform simple tests on the chip in
order to check if it's correctly mounted on the board?

Matteo

If your memory size is small enough or you have enough 
time (testing memory during burn in, for example), 
a walking one bit test followed by a walking zero bit
test is quite good. It is very simple to code, and it 
catches a huge variety of rare problems, but the test 
takes a long time to run on larger memories.

-- 
Guy Macon
<http://www.GuyMacon.com/>;

On Sep 19, 4:01 am, MrPink <Matteo.Cane...@gmail.com> wrote:
> On 19 Set, 11:34, Marcus Harnisch <marcus.harni...@gmx.net> wrote:
>
> > WiMos <Wi...@philips.com> writes:
> > > Try googling for "march B" or "march C" memory tests.
> > > These are the best I could find.
>
> > And while googling anyway, add "march cw" to the list.
>
> > Regards
> > Marcus
>
> I saw this "March" based algorithm (and the not so simple theory
> behind them) , but I thought they are used for memory tests over the
> single bit cell. (i.e. used es EOL test by ram chip manufacturer).
> Do you think they are good also to perform simple tests on the chip in
> order to check if it's correctly mounted on the board?
>
> Matteo


Hi
 March C will catch all stuck at and solid addressing problems.
Things it is weak at are retention/history, read disturb, some weak
write/read
problems and some pattern sensitive faults. It is still a good general
purpose test.
Dwight