From: swahl@brecis.com (Steve Wahl)
To: linux-mtd@lists.infradead.org
Subject: DQ5 & DQ6 in chips/cfi_cmdset_0002.c (Dairy Queen 5 warning)
Date: Tue, 18 Mar 2003 10:51:00 -0600 [thread overview]
Message-ID: <20030318105100.N1745@brecis.com> (raw)
In-Reply-To: <1047925661.11512.213.camel@tubarao>; from tharbaugh@lnxi.com on Mon, Mar 17, 2003 at 11:27:41AM -0700
On Mon, Mar 17, 2003 at 11:27:41AM -0700, Thayne Harbaugh wrote:
> On Mon, 2003-03-17 at 09:19, Steve Wahl wrote:
> > On Mon, Mar 17, 2003 at 08:54:21AM -0700, Thayne Harbaugh wrote:
>
> <snip>
>
> > > I do know, however, that several
> > > manufactures recommend that the final status should be checked an
> > > additional two times before a success is reported.
>
>
> > I'd be interested
> > to see specific data sheets or application notes that do this.
>
> What I stated is not completely accurate. Here is what SST states on
> page 14 of _4_Mbit_LPC_Flash_SST49LF040_ in the Write Operation Status
> Detection section:
>
> The actual completion of the nonvolatile write is asynchronous with the
> system; therefore, either a Data# Palling or Toggle Bit read may be
> simultaneous with the completion of the Write cycle. If this occurs,
> the system may possibly get an erroneous result, i.e., valid data may
> appear to conflict with either DQ7 or DQ6. In order to prevent spurious
> rejection, if an erroneous result occurs, the software routine should
> include a loop to read the accessed location an additional two (2)
> times. If both reads are valid, then the device has completed the Write
> cycle, otherwise the rejection is valid.
Ahh. If I read this correctly, if you are about to report an error
you should read two more times to make sure it's still there.
So your original wording should be "the final status should be checked
an additional two times before a *failure* is reported." You could
legally / reasonably report success the instant you detect it.
Do you agree?
It is somewhat funny that if this was followed, I wouldn't have run
into the "DQ5 detected, but things seem OK" warning (can't remember
the original wording, sorry).
--> Steve
next prev parent reply other threads:[~2003-03-18 16:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-12 0:25 DQ5 & DQ6 in chips/cfi_cmdset_0002.c (Dairy Queen 5 warning) Thayne Harbaugh
2003-03-12 15:44 ` John Burch
2003-03-12 16:35 ` Thayne Harbaugh
2003-03-12 16:27 ` Steve Wahl
2003-03-12 17:12 ` John Burch
2003-03-12 21:43 ` Steve Wahl
2003-03-12 22:17 ` John Burch
2003-03-13 7:17 ` David Woodhouse
2003-03-13 7:26 ` Russ Dill
2003-03-17 15:54 ` Thayne Harbaugh
2003-03-17 16:09 ` John Burch
2003-03-17 16:19 ` Steve Wahl
2003-03-17 18:27 ` Thayne Harbaugh
2003-03-18 16:51 ` Steve Wahl [this message]
2003-03-18 17:22 ` Thayne Harbaugh
2003-03-17 15:40 ` Thayne Harbaugh
2003-03-17 18:38 ` Thayne Harbaugh
2003-03-19 0:23 ` Thayne Harbaugh
2003-03-19 15:56 ` Steve Wahl
2003-03-19 19:38 ` Thayne Harbaugh
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=20030318105100.N1745@brecis.com \
--to=swahl@brecis.com \
--cc=linux-mtd@lists.infradead.org \
/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