"Rob Horton" <yahoo@mr_horton.com> skrev i meddelandet
news:IfKdncfgVMf7gN_YnZ2dnUVZ8s-dnZ2d@pipex.net...
>I have been using the 8MB, AT45DB642, from Atmel for a number of years now.
>It has become apparent that some of the chips we use have stuck bits at
>various locations. So far this has exhibited itself in two forms.
>
> (1) a consistent pattern that occurs through every one of the 8192 pages.
>
> (2) a random scattering throughout a portion of the memory.
>
> Anyone experienced something like this or are my sources of chips coming
> from the "gray market"?


The dataflash will eventually wear out, and this is the symptom.
There is a soft and a hard wear out.

The soft erase works like this:
The flash is divided into blocks of 256 pages, and you need to keep track
of the cumulative number of erase cycles within each block.

You should do an erase cycle on each page in this block
before that count reaches 10,000.
If you erase all the pages but one 40 times: 40 * (256-1) = 10200.
The page not erased, then you run the risk of losing data in the page
not erased.  If you erase a single page 10000 times, then you risk
losing data in the remaining 255 pages.

Mentioned in the datasheet.
I believe the new AT45DB642D does not have this restriction.

If this rule is not followed, then the part may toggle a bit here and there
in those pages where the rule was not followed, but a new erase cycle
should fully recover the page.

There is a hard wear out which causes a bit to permanently be set.
(It cannot be erased) IIRC, this is 50000 erase cycles per page in the 642.

The problem where a bit is stuck in each page seems to be related
to the reading mechanism of the flash and not the memory bits themselves.


-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

Rob Horton wrote:
> I have been using the 8MB, AT45DB642, from Atmel for a number of years
> now. It has become apparent that some of the chips we use have stuck
> bits at various locations. So far this has exhibited itself in two
> forms.
> (1) a consistent pattern that occurs through every one of the 8192
> pages.
> (2) a random scattering throughout a portion of the memory.
>
> Anyone experienced something like this or are my sources of chips
> coming from the "gray market"?

Random bit errors can have several causes.

If you write too many times to the dataflash you will see bits which
fails to erase.

There is a soft limitation here.
The device is divided into blocks of 256 pages, and after
sending 10,000 erase commands to a block, either to a single
page or to a set of pages, any memory in the block
not erased starts to become unreliable.
If you make sure that each page in a block is erased
during such a cycle, you do not see a problem.
This limitation is described in the datasheet, and
only affects the AT45DB642 (which is obsolete) and does
not affect the new AT45DB642D.

If you have brownout, then the CPU can do anything
including writing random data to dataflash.

The AT45DB642 has a long hold time requirement.
I believe that not all Linux Drivers will honour that hold time.

If you have a buggy SPI, then this may cause the problem.
Check the errata of the MCU you are using to make sure
that this is not the issue.

Having a consistent pattern in everyone of the 8192 pages
in my opinion indicates a H/W error in the read circuitry.
Could be ESD related.

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

I have been using the 8MB, AT45DB642, from Atmel for a number of years 
now. It has become apparent that some of the chips we use have stuck 
bits at various locations. So far this has exhibited itself in two forms.

(1) a consistent pattern that occurs through every one of the 8192 pages.

(2) a random scattering throughout a portion of the memory.

Anyone experienced something like this or are my sources of chips coming 
from the "gray market"?