Searching \ for '[OT] FLASH (AMD 29F040)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/mems.htm?key=flash
Search entire site for: 'FLASH (AMD 29F040)'.

Exact match. Not showing close matches.
PICList Thread
'[OT] FLASH (AMD 29F040)'
1998\11\09@201607 by Dennis Plunkett

flavicon
face
11/11/'98

Hello all,
Does anyone know if the AMD 29F040 series of FLASH EEPROMS can have
individual bytes erased and written again. By this I mean can we write 0xff
to erase over the top of the old byte, and then the new data?


Thanks in advance
Dennis

1998\11\10@112946 by Bob Shaver

flavicon
face
On Monday, November 09, 1998 8:18 PM, Dennis Plunkett
[SMTP:spam_OUTdennisTakeThisOuTspamRDD.NECA.NEC.COM.AU] wrote:
> 11/11/'98
>
> Hello all,
> Does anyone know if the AMD 29F040 series of FLASH EEPROMS can have
> individual bytes erased and written again. By this I mean can we write
0xff
> to erase over the top of the old byte, and then the new data?
>
>
> Thanks in advance
> Dennis
>

No, they cannot.  You must erase an entire sector at a time.  Each sector
can be erased or programmed independently of the other sectors.  You can
even protect some sectors to prevent erasure.  You cannot, however, execute
code from one sector while programming another sector (although there are
other FLASH chips that allow this, but I can't remember the part numbers
off the top of my head).

Bob.

1998\11\10@163349 by Dale Wescombe

flavicon
face
My reading of the Data sheet would suggest they can only be sector erased
in sectors. If you want to contact me privately I may be able to contact
AMD and confirm this for you.
Dale




Dennis Plunkett <.....dennisKILLspamspam@spam@RDD.NECA.NEC.COM.AU> on 11/10/98 11:18:13 AM

Please respond to pic microcontroller discussion list
     <PICLISTspamKILLspamMITVMA.MIT.EDU>

To:   .....PICLISTKILLspamspam.....MITVMA.MIT.EDU
cc:    (bcc: dale.wescombe)
Subject:  Re: [OT] FLASH (AMD 29F040)




11/11/'98

Hello all,
Does anyone know if the AMD 29F040 series of FLASH EEPROMS can have
individual bytes erased and written again. By this I mean can we write 0xff
to erase over the top of the old byte, and then the new data?


Thanks in advance
Dennis

1998\11\10@213033 by brad

flavicon
face
Dale Wescombe wrote:
>
> My reading of the Data sheet would suggest they can only be sector erased
> in sectors. If you want to contact me privately I may be able to contact
> AMD and confirm this for you.
> Dale

According to my AMD Flash products data book, and experience. This is
correct.
Erase only on a Per Sector or Whole chip basis

--
-----------------------------------
Brad Campbell
Technical Manager

Seme Electrical Engineering Co
59 Collingwood St Osborne Park 6017
Western Australia
Ph    :-+61 8 9445 2577
Fax   :-+61 8 9244 1327
Email :- EraseMEbradspam_OUTspamTakeThisOuTseme.com.au

 /"\
 \ /
  X  ASCII RIBBON CAMPAIGN
 / \ AGAINST HTML MAIL

1998\11\11@190028 by John Payson

flavicon
face
|Does anyone know if the AMD 29F040 series of FLASH EEPROMS can have
|individual bytes erased and written again. By this I mean can we write 0xff
|to erase over the top of the old byte, and then the new data?

Once a bit has been changed from a "1" to a "0", the only way
to change it back is to do a sector erase; if memory serves,
the 29F040 is divided into 10 sectors of various sizes, and
sector erase operations take hundreds of miliseconds to complete.

It is possible, however, to convert "1"'s to "0"'s; as a result,
it's possible to mark old data as obsolete even though the space
for it cannot be reclaimed until the block is rewritten.  On a
similar AMD chip (256Kx16) I implemented a simple file system on a
DSP which subdivides the chip into 2Kx16 blocks.  Files are erased by
overwriting their identifying markers with "0000"; erasing or rep-
lacing a file doesn't actually free up the space, but does mark the
space for re-use.  When space gets too low, a "garbage collection"
routine cleans up the storage area by unloading sectors' data either
into other sectors or else RAM, erasing the now-unloaded sectors,
and then (if needed) writing the data back to them.  Although the
sector size is 32Kx16, the RAM buffer doesn't have to be quite that
big (it's only necessary to erase and rewrite a sector if it has one
or more "garbage" blocks, and there's no need to store such blocks.

The garbage collection interates the following loop as needed:

- Copy a block of data from the garbage-containing sector with the
  smallest amount of used space to the garbage-free sector with the
  least free space.  This data will never have to be moved again.
  Repeat until no longer possible.

- Copy into RAM a block from the sector containing the smallest
  number of useful blocks.  Repeat until RAM is full or no more such
  sectors exist.

- Erase all sectors that no longer contain any useful data.

- Write sectors from RAM into the garbage-free sector with the least
  free space.

Given a 28K RAM buffer and 2K block size, the only way this algorithm can
fail is if every sector is either full of useful data or contains exactly
one block of garbage data and is otherwise full.  Having a block or two
which are normally never allocated will solve this problem since such a gap
will ensure the garbage collector has a place to start.

Note of course that all bets are off if power fails while a device update is
in progress.  If you can afford an entire spare sector of flash, it's possible
to design a file system which is robust even in such cases, though for most
applicaitons I doubt if it'd be worth the effort.

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...