public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Bari Ari <bari@onelabs.com>
To: "chris.read@activesilicon.co.uk" <chris.read@activesilicon.co.uk>
Cc: "'mtd@infradead.org'" <mtd@infradead.org>
Subject: Re: Power blackouts and brownouts
Date: Thu, 26 Apr 2001 10:35:42 -0500	[thread overview]
Message-ID: <3AE8404E.7030305@onelabs.com> (raw)
In-Reply-To: 01C0CE5A.276D58F0.chris.read@activesilicon.co.uk

Chris Read wrote:

> Does anyone know what actually happens to a flash chip when the power 
> starts to fail during an erase or a write cycle? We are all trying to write 
> code which can recover when abruptly halted at any point, but can all the 
> devices which we are using claim the same?
> 
> I have noticed that several flash devices have a power on reset line; most 
> however do not. Whilst I appreciate that flash devices are not fully static 
> like SRAM or EPROM, and therefore must have some way of initialising in a 
> known state at power up; most devices appear to not need this external 
> signal. My hypothesis is therefore that this line may be more for abruptly 
> stopping any internal state machine during the first stages of a brown-out 
> whilst there is still sufficient power available to do so.
> 
> Any thoughts?
> 
> Chris Read

The answer depends on how the circuit designer engineered the power 
supplies and reset circuitry. How well was the circuit engineered to 
account for power failure and to minimize data corruption? The flash 
device characteristics are only part of the puzzle.

In one scenario the power supply for the flash device may hold within 
spec longer than the driver writing the data to it, in this scenario the 
flash device operates correctly and latches the data to its input 
register but the data latched may already be garbage based on the output 
driver from the device writing data to the data inputs on the flash 
since the drivers supply voltage is below spec at that clock edge when 
the data is latched.

Bari Ari                         email: bari@onelabs.com 
<mailto:bari@onelabs.com> <mailto:bari@onelabs.com>
O.N.E. Technologies
1505 Old Deerfield Road        tel: 773-252-9607
Highland Park, IL 60035        fax: 773-252-9604

http://www.onelabs.com




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

  reply	other threads:[~2001-04-26 15:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-26 13:06 Power blackouts and brownouts Chris Read
2001-04-26 15:35 ` Bari Ari [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-04-26 13:54 Hicks, Jamey
2001-04-26 15:55 Vipin Malik
2001-04-27  7:39 ` Joakim Tjernlund
2001-04-27 14:30   ` Vipin Malik
2001-04-27 14:34     ` David Woodhouse
2001-04-27 15:31       ` Vipin Malik
2001-04-27 20:37       ` David Schleef
2001-04-28 10:34         ` David Woodhouse

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=3AE8404E.7030305@onelabs.com \
    --to=bari@onelabs.com \
    --cc=chris.read@activesilicon.co.uk \
    --cc=mtd@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