Re: In search of bad 4164, 41256 DRAM

From: David Roberts <daver21145_at_gmail.com>
Date: Fri, 13 Sep 2019 21:09:04 +0100
Message-ID: <CAC5emFECOHkTzv-fGfYeP5V8RKtq1pJcu3+g66jKJAdApcjDtg_at_mail.gmail.com>
Checkout the march-b and march-c algorithms. These are pretty good 'off the
peg' algorithms for finding quite a range of faults.

Dave

On Fri, 13 Sep 2019 at 21:05, Jeffrey Birt <birt_j_at_soigeneris.com> wrote:

> Hi All,
>
>
>
> I built a DRAM tester for fun and to brush up on Arduino development. I
> have a lot of students I work with use Arduino, so I wanted to build
> something to stay up to date and I have not done anything with an Arduino
> for more than a year. I found a project online as a starting point and
> added an automatic DRAM refresh driven by Timer2 overflow. Even with a
> pokey Arduino and the ISR in C it can refresh 64 rows in less and 100us.
>
>
>
> I did a quick test with a 41256 just now and was happy I could read/write
> all bits successfully. Then I realized I don’t have any known bad
> 4164/41256 type DRAM chips on hand. So, if you happen to have a few bad
> DRAM chips on hand and you’re in the USA I would gladly take them off your
> hands. Otherwise I’ll have to figure out a way to inject a simulated fault.
> Maybe writing a wrong value to a known cell after writing the proper
> pattern to all cells would be a good enough simulation?
>
>
>
> I still have a way to go with the software. The original project I found
> online used separate functions for each test pattern. I want to create a
> single function that will write a bit pattern that is passed to it and then
> verify that pattern is in memory. Maybe a n second pause would be good to
> have in place between the write and verify to ensure that the refresh is
> working properly?
>
>
>
> Thanks,
>
> Jeff Birt
>
Received on 2020-05-29 22:50:33

Archive generated by hypermail 2.3.0.