From: Lukasz Majewski <lukma@denx.de>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: <linux-mtd@lists.infradead.org>
Subject: Re: Problem with NAND memory data retention
Date: Thu, 27 Apr 2017 15:04:16 +0200 [thread overview]
Message-ID: <20170427150416.2c6bba07@jawa> (raw)
In-Reply-To: <alpine.DEB.2.11.1704271246210.6882@lnxricardw1>
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.
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
next prev parent reply other threads:[~2017-04-27 13:04 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 [this message]
2017-04-27 13:13 ` Andrea Adami
[not found] ` <CAAQYJAtBGn_-8z-1NQbVYPiVm6W3zquibLK9jutWWKGn0RBWuQ@mail.gmail.com>
2017-04-28 8:36 ` Lukasz Majewski
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=20170427150416.2c6bba07@jawa \
--to=lukma@denx.de \
--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