Lpc2000

Using the Keil Flashfiler, am i having trouble with the internal flash via IAP.

It seems that extra data is placed on the flashmap, different from RAMbuffer, after it is delivered to IAP_execute.

Has any one Experienced the same ? 
or and have some advice.

I have stopped interrupt, during the IAP call. and the bootloader is v2.11

GTZ

Hi,

When updating a sector that already contains data, I noticed that with 
some data the update writes the wrong data. I found this when updating 
the first 4 bytes of the 2nd sector. Through my supplier in the 
Netherlands I have a support request that was forwarded to the LPC2000 
development team in the USA about 3 weeks ago. I get very little 
feedback on the status of my support request, so I don't even know if 
they have been able to reproduce the error.

Richard Duits



gtz.gtz@... wrote:

> Using the Keil Flashfiler, am i having trouble with the internal flash 
> via IAP.
>
> It seems that extra data is placed on the flashmap, different from 
> RAMbuffer, after it is delivered to IAP_execute.
>
> Has any one Experienced the same ?
> or and have some advice.
>
> I have stopped interrupt, during the IAP call. and the bootloader is v2.11
>
> GTZ

There are extra ECC (Error correction codes) bits for every
16-bytes of flash memory.  Check some very old thread with answers
from philips guys in this forum. Something about you could only use
the flash Memory at min block size of 16-bytes.

Regards

--- In lpc2000@yahoogroups.com, Richard Duits <yahoo@r...> wrote:
>
> Hi,
> 
> When updating a sector that already contains data, I noticed that 
with 
> some data the update writes the wrong data. I found this when 
updating 
> the first 4 bytes of the 2nd sector. Through my supplier in the 
> Netherlands I have a support request that was forwarded to the 
LPC2000 
> development team in the USA about 3 weeks ago. I get very little 
> feedback on the status of my support request, so I don't even know 
if 
> they have been able to reproduce the error.
> 
> Richard Duits
> 
> 
> 
> gtz.gtz@j... wrote:
> 
> > Using the Keil Flashfiler, am i having trouble with the internal 
flash 
> > via IAP.
> >
> > It seems that extra data is placed on the flashmap, different 
from 
> > RAMbuffer, after it is delivered to IAP_execute.
> >
> > Has any one Experienced the same ?
> > or and have some advice.
> >
> > I have stopped interrupt, during the IAP call. and the 
bootloader is v2.11

> >
> > GTZ
>

Thanks, this explains a lot (exept for the very slow reaction of philips).
Did I miss this in the user manual (UM_LPC21XX_LPC22XX_2.pdf)?

Richard.


unity0724 wrote:

> There are extra ECC (Error correction codes) bits for every
> 16-bytes of flash memory.  Check some very old thread with answers
> from philips guys in this forum. Something about you could only use
> the flash Memory at min block size of 16-bytes.
>
> Regards
>
> --- In lpc2000@yahoogroups.com, Richard Duits <yahoo@r...> wrote:
> >
> > Hi,
> >
> > When updating a sector that already contains data, I noticed that
> with
> > some data the update writes the wrong data. I found this when
> updating
> > the first 4 bytes of the 2nd sector. Through my supplier in the
> > Netherlands I have a support request that was forwarded to the
> LPC2000
> > development team in the USA about 3 weeks ago. I get very little
> > feedback on the status of my support request, so I don't even know
> if
> > they have been able to reproduce the error.
> >
> > Richard Duits
> >
> >
> >
> > gtz.gtz@j... wrote:
> >
> > > Using the Keil Flashfiler, am i having trouble with the internal
> flash
> > > via IAP.
> > >
> > > It seems that extra data is placed on the flashmap, different
> from
> > > RAMbuffer, after it is delivered to IAP_execute.
> > >
> > > Has any one Experienced the same ?
> > > or and have some advice.
> > >
> > > I have stopped interrupt, during the IAP call. and the
> bootloader is v2.11
> > >
> > > GTZ
> >

Richard,

I am assuming you are not referring to the bytes that comprise the
reserved vector that is used as checksum for the boot loader.

If no matter what you write to a bit location (a given bit at a given
location) it always reads as a one (or zero) then you have stuck bits
in flash.  Solution: replace your part.

If the error is temporal meaning a given bit location only sometimes
does not reflect what is written, then you may have a timing problem.

Solution: if your boot loader is not the latest one, update to the
latest one; if it is, replace your part.

Do not worry about ECC, or number of bytes written as these are taken
care of at the flash controller and boot loader levels, respectively.

Jaya 

--- In lpc2000@yahoogroups.com, Richard Duits <yahoo@r...> wrote:

>
> Hi,
> 
> When updating a sector that already contains data, I noticed that with 
> some data the update writes the wrong data. I found this when updating 
> the first 4 bytes of the 2nd sector. Through my supplier in the 
> Netherlands I have a support request that was forwarded to the LPC2000 
> development team in the USA about 3 weeks ago. I get very little 
> feedback on the status of my support request, so I don't even know if 
> they have been able to reproduce the error.
> 
> Richard Duits

At 09:38 AM 1/11/06 +0000, jayasooriah wrote:
>Do not worry about ECC, or number of bytes written as these are taken
>care of at the flash controller and boot loader levels, respectively.

Only if you write the correct blocksize.  If you try to update part of an 
ECC'd block you will probably run into problems.  The ECC is in flash too 
and when you try to update part of a block the ECC changes but since it 
can't 'unprogram' already programmed bits in the ECC the ECC will end up 
being incorrect.

That should be just about as clear as mud.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Hi,

have a look at the application note about using Flash as EEPROM in the
files section of this forum.
Name: EE_Demo.zip

There have been several posts indicating that the smallest sector to
be modified should be 16 bytes. You can also just modify less bytes
but do not try to reuse the other bytes of the 16 bytes block. The ECC
will be generated once and tried to update every time a write to the
sane 16 byte block occurs, ergo it is going to be wrong and it will
try to "correct" your data, so your data will be wrong too. 

hope this helps, Bob

--- In lpc2000@yahoogroups.com, gtz.gtz@j... wrote:
>
> Using the Keil Flashfiler, am i having trouble with the internal
flash via IAP.
> 
> It seems that extra data is placed on the flashmap, different from
RAMbuffer, after it is delivered to IAP_execute.
> 
> Has any one Experienced the same ? 
> or and have some advice.
> 
> I have stopped interrupt, during the IAP call. and the bootloader is
v2.11

> 
> GTZ
>

--- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@y...> wrote:

> have a look at the application note about using Flash as
> EEPROM in the files section of this forum.
> Name: EE_Demo.zip

Thanks to this post by lpc2100_fan, I had a closer look at ECC in the
user manual for 214x.

I took the statement on page 297 "The operation of ECC is transparent
to the running application." on face value, and was not interested in
the implementation details.

Is the case in every flash, disk or other system I know, ECC has
always been transparent to the extent most manufacturers do not make
any mention of this in their programming or user manuals for flash
memory, disks, etc.

Many times they prefer not to highlight ECC as the strength of their
ECC regime usually exposes fabrication process control limitations.

However, when I read further down, I found out that, ECC is not after
all transparent as claimed.

1/  You *cannot* make use of the NAND/NOR flash characteristics for
implementing a flash file system.

2/  When you write incrementally to an erased block, you *must* ensure
each 4-byte block does screw up the ECC algorithm used.  [You do not
know what the algorithm is because it is supposed to be transparent.]

3/  The boot loader and IAP calls being advertised as to to hide flash
implementation details apparently does not hide this "property" of the
flash.

I now have to put exclusions in my flash file system package -- that
it will not work on LPC for the above reasons.