Yahoo Groups archive

Lpc2000

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

Message

Re: two questions on Byte Count for LPC Flash Writes

2006-01-28 by Guillermo Prandi

> >Q1: N1+N2 implies that to update 16 bytes (on 16-byte boundary),
> >one must read 256 bytes, modify 16 bytes at the appropriate
> >offset, and then write 256 bytes.  Is this correct?
> Correct.

Well; for areas that already has information but fall inside my 256 
byte chunk I am writing 0xFF instead of the original content. The 
reason I do this is to avoid forcing a "huge" 0 where there is 
already one. I read some long time ago about how EPROMs worked (yes, 
old UV EPROMs, like 2732, 2764); the idea was that holes and 
electrons are pushed from one side to the other, and every time you 
push a hole or an electron, it is more difficult to put it in the 
other place again. I have no idea if I've got the concept correctly 
(I was 16 old!) or if this applies to flash memories as well, but the 
fact that they have a limited number of writing cycles seems to 
suggest so.

"1s" are suppossed to be neutral, whilst "0s" actively attempt to 
modify the memory contents. Writing 0xFF instead of the original 
contents seems to work just fine as far as my tests go. Besides, the 
EE_Demo project in the Files section of this group does likewise.

It would be great to know for sure which method is best with some 
explanation of why.

Guille

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.