Power blackouts and brownouts

Power blackouts and brownouts

[Chris Read]

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




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

Re: Power blackouts and brownouts

[Bari Ari]

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

RE: Power blackouts and brownouts

[Hicks, Jamey]

On the Intel chips, the reset line seems to be most useful to force the
chip into a very low power standby mode.

The specs for recent Intel and AMD flash chips that I have read claim to
halt programming or erasing when the supply voltage drops below
acceptable levels.

So now you just need to worry about which part of the system browns out
first, whether there are voltage monitors on all the supplies, etc.

Jamey Hicks



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

RE: Power blackouts and brownouts

[Vipin Malik]

Well, I haven't seen any flash chips without a reset line, not to say that
they aren't out there.

With a flash chip *with* a reset line, and one which is connected to the
system reset, and assuming that the reset gets asserted in a power down, up,
and brown condition, then everything is ok.

JFFS(2) are designed for this situation and will (are supposed to)
successfully recover on the next power up and all your writes that got
written with CRC will be there. Any write that did not get completed will
not be there at all. If you were overwriting a portion of an existing file,
then the original portion will (should) be still there.

The case of the *no flash chip reset* line is more complicated and you can
have the following situations, particularly in brownouts:

1. Flash chip gets reset as internal VCC monitoring threshold is
(numerically) greater than the system (CPU) reset threshold. In this case,
your flash chip state machine will get reset. In this case there are 2
conditions:
  a. If the flash chip was not being written to or read from, there is no
effect
  b. If the flash chip was being written to, it's state m/c will get reset
and most likely it's generate a fatal error in the JFFS or MTD write code.
You are unlikely to recover from this as the code is not written to retry
"fatal" errors like the state m/c getting reset in the middle of an
operation (AFAIK).

2. The processor gets reset in a brown out, but not the flash chip. Again
you have 2 conditions:
  a. If the flash chip was in the "default" read state, no problem as the
processor will expect and find it readable. Life is good.
  b. If the flash was in some other state (erasing or write), depending on
how fast the processor comes back up and tries to access the flash, the
flash may or may not respond to a read request. You are then hosed.

In summary, if your hardware is designed "right" you do not (read: should
not) have to worry about file system inconsistency problems as any data
corruption issues are taken care of by JFFS(2) design.

What type of flash chips do not have a hardware reset line? Any examples?

Vipin
P.S. All this is IMHO (In my humble opinion) of course. And that opinion has
been known to be fallable and wrong in more than one occasion in the past!
 

-----Original Message-----
From: Chris Read
To: 'mtd@infradead.org'
Sent: 4/26/01 8:06 AM
Subject: Power blackouts and brownouts

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




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


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

RE: Power blackouts and brownouts

[Joakim Tjernlund]

-----Original Message-----
From: owner-mtd@infradead.org [mailto:owner-mtd@infradead.org]On Behalf

Well, I haven't seen any flash chips without a reset line, not to say that
they aren't out there.

With a flash chip *with* a reset line, and one which is connected to the
system reset, and assuming that the reset gets asserted in a power down, up,
and brown condition, then everything is ok.

<snip>

hmm, do you mean that reset has to asserted at power DOWN as well in order
for JFFS2 FS to manage its FS? How do you manage that when someone pulls
the power cable?

         Jocke



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

Re: Power blackouts and brownouts

[Vipin Malik]

Joakim Tjernlund wrote:

> -----Original Message-----
> From: owner-mtd@infradead.org [mailto:owner-mtd@infradead.org]On Behalf
>
> Well, I haven't seen any flash chips without a reset line, not to say that
> they aren't out there.
>
> With a flash chip *with* a reset line, and one which is connected to the
> system reset, and assuming that the reset gets asserted in a power down, up,
> and brown condition, then everything is ok.
>
> <snip>
>
> hmm, do you mean that reset has to asserted at power DOWN as well in order
> for JFFS2 FS to manage its FS? How do you manage that when someone pulls
> the power cable?
>
>          Jocke

No, but most well designed embedded systems will assert the reset line both on
power
up AND down. Actually, direction does not really matter. Reset is asserted when
the
power rail is out of spec, which will happen (due to the laws of physics), both
on up and down.

You wan't the reset line asserted on power down also, else the processor may
"wander off"
into the weeds and overwrite battery backed RAM or other such stuff if present.

I don't think that JFFS(2) *require* you to assert the reset line (processor or
flash) on power down.

Vipin




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

Re: Power blackouts and brownouts

[David Woodhouse]

vipin.malik@daniel.com said:
>  No, but most well designed embedded systems will assert the reset
> line both on power up AND down. Actually, direction does not really
> matter. Reset is asserted when the power rail is out of spec, which
> will happen (due to the laws of physics), both on up and down.

> You wan't the reset line asserted on power down also, else the
> processor may "wander off" into the weeds and overwrite battery backed
> RAM or other such stuff if present.

Note that 'well designed embedded systems' does _not_ include the Intel
Assabet platform. I believe nothing ever asserts the flash reset line, so if
you reset while the flash is in a mode other than read mode, the CPU's reset
vector is pointing at status words :)

The only way to fix it when you've done this is to remove power, remove the 
battery, and wait for the on-board cap to run out of charge.

Fun. :)

--
dwmw2




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

Re: Power blackouts and brownouts

[Vipin Malik]

Well, with a name like "ass-a-bet" what can you expect ;)

What is this platform anyway?

Vipin

David Woodhouse wrote:

> vipin.malik@daniel.com said:
> >  No, but most well designed embedded systems will assert the reset
> > line both on power up AND down. Actually, direction does not really
> > matter. Reset is asserted when the power rail is out of spec, which
> > will happen (due to the laws of physics), both on up and down.
>
> > You wan't the reset line asserted on power down also, else the
> > processor may "wander off" into the weeds and overwrite battery backed
> > RAM or other such stuff if present.
>
> Note that 'well designed embedded systems' does _not_ include the Intel
> Assabet platform. I believe nothing ever asserts the flash reset line, so if
> you reset while the flash is in a mode other than read mode, the CPU's reset
> vector is pointing at status words :)
>
> The only way to fix it when you've done this is to remove power, remove the
> battery, and wait for the on-board cap to run out of charge.
>
> Fun. :)
>
> --
> dwmw2



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

Re: Power blackouts and brownouts

[David Schleef]

On Fri, Apr 27, 2001 at 03:34:32PM +0100, David Woodhouse wrote:
> 
> Note that 'well designed embedded systems' does _not_ include the Intel
> Assabet platform. I believe nothing ever asserts the flash reset line, so if
> you reset while the flash is in a mode other than read mode, the CPU's reset
> vector is pointing at status words :)

This is also a problem for soft-reset.  (Been there, dont that.)
That's why the Sharp chip driver always puts the chips into read
mode after checking the status.  I believe at least one of the
other chip drivers don't do this.



dave...



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

Re: Power blackouts and brownouts

[David Woodhouse]

ds@schleef.org said:
>  This is also a problem for soft-reset.  (Been there, dont that.)
> That's why the Sharp chip driver always puts the chips into read mode
> after checking the status.  I believe at least one of the other chip
> drivers don't do this. 

This bit me too, on suspend/resume. We now have MTD suspend/resume 
functions which deal with that case.

Incidentally, is there any particular reason why the functionality of the 
sharp driver shouldn't be provided by a more generic version of the Intel/
Sharp CFI commandset driver? Once we fix up the probe, of course.

--
dwmw2




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