Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: Flash fails to write a bit or zeroes other bit

2004-05-24 by chazeltopman

--- In lpc2000@yahoogroups.com, "chazeltopman" <rob@n...> wrote:
>  Now let me explain the write algorithm I'm using.
>  I need to be able to store 32 bit values into flash
>  one at a time.  Since the IAP routines limit writes
>  to a minimum of 512 bytes I  had to work around
>  this limit.

I've received an anonymous reply that addresses the
flash writing limitations:

: The flash can not be used '32 bit word' wise.
: You could try to write 16 bytes at once (4x 32 bit word),
: but the number of partial writes per 512 bytes (the normal
: size) is limited (I don't believe this number is specified).
:
: Note the '16 byte'data should be properly aligned on 16 byte
: multiples (but again the number of 'partial write'is limited
: .. let's say .. 16 times or so :-) ).
:
: You may repost this info in the group - as long as you
: don't refer to me.

Since counting the number of times I write to a location
presents a new bag of trouble, I'll use the dumb algorithm
of copy, modify, erase and write back.  Sigh.

 Although, with a second thought, it might be worth a best-of
 algorithm which does a:
  o copy
  o modify
  o write
  o compare
  o if ok then done
  o if different then do dumb algorithm

 The question is, how much should be compared?  If I compare
 just the surrounding 512 byte section that I am writing to,
 will the other sections in the 8K sector be affected?  I
 suspect not.  But if the write fails, then the copied part
 and the other sections from the flash must be merged to form
 the new flash sector image.

 Now what if I didn't have to write 512 bytes?
 Does the reply suggest that I can use the IAP write command
 with a value smaller than the stated 512 bytes?  Hmmm... One
 way to find out is the emperical method.... No.  Only the
 published values are accepted.  So I tried to write the
 whole section of 512 bytes multiple times and the most I
 got was three good writes after an erase but mostly just
 two.  So overall, I could cut the time in half by only
 erasing every second write or as above, if they differ.
 In my testing, I stayed with a 16 byte, aligned, segment.

 This is my testing with MaxForth V5.2 in interactive 
 hex entry mode:
  Where: FLERASE will erase an 8K sector containing a given address
         Z compares SECTOR to flash and prints the differences
         SECTOR is a 512 byte buffer
         COM and READY are command/response buffers
         IAP takes a command buffer and returns it as a result buffer

3DC00 FLERASE  OK  ( erase 8K sector )
Z 3DC00 3DC04 3DC10 3DC14 3DC18  OK  ( buffer has differences )
A55B SECTOR 10 + !  OK  ( alter some buffer locations )
FFFFFFFF SECTOR 14 + !  OK
Z 3DC00 3DC04 3DC10 3DC18  OK  ( less differences )
32 READY ! READY IAP ? 33 COM ! COM IAP ? Z 0 0  OK  ( first write is ok )
A558 SECTOR 10 + ! Z 3DC10  OK  ( change buffer again )
32 READY ! READY IAP ? 33 COM ! COM IAP ? Z 0 0  OK  ( second write is ok )
FDP @ SECTOR 14 + ! Z 3DC14  OK  ( change buffer again )
32 READY ! READY IAP ? 33 COM ! COM IAP ? Z 0 0 3DC18  OK ( third write fails )

  The third write failed at a location that I wasn't even
  changing (0x 3DC18).

  I like the flash on the 6812 where they have two separate flash
  banks with different write widths.  The smaller one has a write
  width of 4 bytes so if you need to write 32 bit values in flash
  you use the smaller flash.  If you can write in large blocks, 
  you use the larger flash.

 Rob

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.