public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Lukasz Majewski <lukma@denx.de>
To: Andrea Adami <andrea.adami@gmail.com>
Cc: Ricard Wanderlof <ricard.wanderlof@axis.com>,
	linux-mtd@lists.infradead.org
Subject: Re: Problem with NAND memory data retention
Date: Fri, 28 Apr 2017 10:36:52 +0200	[thread overview]
Message-ID: <20170428103652.62990916@jawa> (raw)
In-Reply-To: <CAAQYJAtBGn_-8z-1NQbVYPiVm6W3zquibLK9jutWWKGn0RBWuQ@mail.gmail.com>

Hi Andrea,

Thanks for your response!

> On Thu, Apr 27, 2017 at 3:04 PM, Lukasz Majewski <lukma@denx.de>
> wrote:
> 
> > Hi Ricard,
> >
> > >
> > > On Thu, 27 Apr 2017, Lukasz Majewski wrote:
> > >
> > > > I'd like to ask you for sharing your experience with NAND Flash
> > > > devices
> > > > - which may be older that their data retention time.
> > > >
> > > > I've a problem with Flash NAND memory (Samsung 128Mx8).
> > > >
> > > > In the data sheet [1] the manufacturer claims that it has 10
> > > > years for data retention. The device equipped with it is a bit
> > > > older than 10 years.
> > > >
> > > >
> > > > How one can diagnose that data retention time for NAND Flash has
> > > > been exceeded?
> > > >
> > > > Is that:
> > > >
> > > > - The number of bit flip errors on a RW page so large that ECC
> > > > cannot fix it?
> > > >
> > > > - Or are whole RW pages erased (0xFF)/corrupted/cleared (0x00)?
> > > >
> > > > - Or any other evidence?
> > > >
> > > > Thanks in advance for your help.
> > >
> > > I think the interpretation is that the manufacturer guarantees
> > > that under the circumstances specified (temperature, supply
> > > voltage, erase cycles etc) that the data will be retained for at
> > > least ten years, beyond that it's just not specified. It doesn't
> > > mean that something catastrophic will happen after ten years,
> > > i.e. ten years is not a hard limit beyond which things start
> > > going haywire.
> >
> > Thanks for your explanation.
> >
> > >
> > > I can't say I have experience with old NAND flashes loosing their
> > > data, but technically I would expect that what happens is that
> > > eventually the charge leaks away from the bit cells, causing bit
> > > flips, quite simply, so it's the same mechanism that requires the
> > > flash to be 'scrubbed' periodically to check if the data needs to
> > > be rewritten.
> > >
> > > I.e. it's the first case in your list, the number of bit flips
> > > increases.
> >
> > Unfortunately with my device I do experience the second scenario.
> >
> > I do observe pages read as zeros.
> >
> 
> Hello,
> 
> I think I have seen the same issue: one defective device did not
> respond to CFI QRY.
> 
> http://lists.infradead.org/pipermail/linux-mtd/2014-May/053872.html

I do not have (yet) the CFI commands dump, but in my case Erase->
Reflash sequence causes the file content to be correct.

IMHO, If the Flash memory controller itself is broken, then
"re-flashing" would not help.

Maybe - in my case the NAND flash driver (2.6 kernel) causes the issue
(with zero filled page showing up in the middle of a YAFFS file) by some
write done at mistakingly calculated address?

Any ideas/hints are more than welcome :-)

Best regards,
Łukasz Majewski

> 
> These devices were sold in 2002-2003 so they are now >15yrs old and I
> have two of them working flawlessy.
> 
> Regards
> Andrea
> 
> 
> 
> 
> >
> > For example in the middle of a file - page sized (2K) data is read
> > as zero. And this file is RO (no modification). And such zero read
> > is persistent - happens all the time. The only way is to replace
> > the whole file (erase it and write again).
> >
> > We use yaffs file system.
> >
> > And such errors pop up in random places.
> >
> > >
> > > The fewer erase cycles that a given flash block has seen, the less
> > > wear there has been on the insulation, and the better the
> > > retention would be. The ten year spec is under the worst case
> > > condition of the maximum number of erase cycles having been
> > > performed on the flash.
> > >
> > > /Ricard
> >
> >
> >
> >
> > Best regards,
> >
> > Lukasz Majewski
> >
> > --
> >
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > wd@denx.de
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> >




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

      parent reply	other threads:[~2017-04-28  8:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-27 10:25 Problem with NAND memory data retention Lukasz Majewski
2017-04-27 10:54 ` Ricard Wanderlof
2017-04-27 13:04   ` Lukasz Majewski
2017-04-27 13:13     ` Andrea Adami
     [not found]     ` <CAAQYJAtBGn_-8z-1NQbVYPiVm6W3zquibLK9jutWWKGn0RBWuQ@mail.gmail.com>
2017-04-28  8:36       ` Lukasz Majewski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170428103652.62990916@jawa \
    --to=lukma@denx.de \
    --cc=andrea.adami@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ricard.wanderlof@axis.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox