2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

Dear All,

I want to save some working critical data to flash in my project.
I need to save the same before the unit is powered down.

I am using EINT2 to trigger flash writing routine, so that the data is available to my application, at the time of next power-up. I need to save the data on power down since the same keeps on changing when the unit is working.

My questions are:
Is it advisable to trigger IAP on EINT2 (Or any interrupt)?
If not what is the alternative method?
Since I am running short of time (Capacitor backup is not sifficient), can I overwrite the data without erasing the sector? (Which will save my precious 400mS)

Replies will be highly appreciated.

Regards

Anil Velhankar

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

weldcon wrote:
> Is it advisable to trigger IAP on EINT2 (Or any interrupt)?

Maybe it is not advisable, but I think that, if you make sure you are
not calling IAP from main program and EINT2 handler in the same time,
you will be fine.

> If not what is the alternative method?

Setting a flag in the EINT2 handler and watching it in the main loop

> Since I am running short of time (Capacitor backup is not sifficient),
> can I overwrite the data without erasing the sector? (Which will save my
> precious 400mS)

In LPC you can't do any overwriting at all due to the ECC. But why don't
you make sure in bootup that there is an erased block available for the
future power off.

--

Timo

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi all!,

You can call IAP from IRQ,FIQ, or anywhere whenever you have FIQ/IRQs
disabled
before call to IAP(it's mandatory when calling IAP) -> so mutual exclusion
with main
wouldn't be a problem.

If I'm not wrong, the minimum you can is in blocks of 256, and when you
write on a block
you couldn't overwrite it (even if it's all 0xff) because with every 4 bytes
1 ecc byte is stored
in flash, and it won't be 0xff.

So as Timo recomends, I would prepare everything at bootup. I would use a
4/32kB sector,
and go advancing +=256 bytes at every boot (checking signatures at every
256block start to
check if it's free), if the sector is full then erase and set the pointer to
the base of the sector.
my 2 cents

2009/10/11 Timo

> weldcon wrote:
> > Is it advisable to trigger IAP on EINT2 (Or any interrupt)?
>
> Maybe it is not advisable, but I think that, if you make sure you are
> not calling IAP from main program and EINT2 handler in the same time,
> you will be fine.
>
> > If not what is the alternative method?
>
> Setting a flag in the EINT2 handler and watching it in the main loop
>
> > Since I am running short of time (Capacitor backup is not sifficient),
> > can I overwrite the data without erasing the sector? (Which will save my
> > precious 400mS)
>
> In LPC you can't do any overwriting at all due to the ECC. But why don't
> you make sure in bootup that there is an erased block available for the
> future power off.
>
> --
>
> Timo
>
>
>
[Non-text portions of this message have been removed]

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Miguel Angel wrote:
> ... it's mandatory [to disable interrupts] when calling IAP

Not true - see UM 20.4.10. But it is probably the easiest way to avoid
problems.

> If I'm not wrong, the minimum you can is in blocks of 256, and when
> you write on a block you couldn't overwrite it (even if it's all
> 0xff) because with every 4 bytes 1 ecc byte is stored in flash, and
> it won't be 0xff.

There is one ECC byte for every 16 bytes of data (UM 20.6.).

If data is all 0xFF, then the ECC byte must be 0xFF. Otherwise you
couldn't succesfully read just erased data because the ECC byte was
erased too (UM 20.6.). So it actually is possible to write 16 byte block
at a time by filling the rest of the data buffer with 0xFF. I have
tested this with LPC2468.

--

Timo

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

It's true Timo, my memory was worse than I thought :-)

20.4.10 says:
"""
The on-chip flash memory is not accessible during erase/write operations.
When the user
application code starts executing the interrupt vectors from the user flash
area are active.
The user should either disable interrupts, or ensure that user interrupt
vectors are active in
RAM and that the interrupt handlers reside in RAM, before making a flash
erase/write IAP
call. The IAP code does not use or disable interrupts.
""""

So this means that if you have any interrupt handler that runs off flash yo=
u
should disable it.
but any way, for his description is a very possible reason for his crash.

About the ECC bytes, is confusing:

""""
The operation of ECC is transparent to the running application. The ECC
content itself is
stored in a flash memory not accessible by user=92s code to either read fro=
m
it or write into it
on its own. A byte of ECC corresponds to every consecutive 128 bits of the
user
accessible Flash. Consequently, Flash bytes from 0x0000 0000 to 0x0000 0003
are
protected by the first ECC byte, Flash bytes from 0x0000 0004 to 0x0000 000=
7
are
protected by the second ECC byte, etc.
"""
but is confusing as they say " 0x0000 0000 to 0x0000 0003 are
protected by the first ECC byte, Flash bytes from 0x0000 0004 to 0x0000 000=
7
are
protected by the second ECC byte, etc."
And later it says: "for the implemented ECC mechanism to perform properly,
data must be written
into the Flash memory in groups of 4 bytes (or multiples of 4), aligned as
described above"
So I guess it's 4 bytes, anyway when Issuing a Ram to flash copy you should
take care of this:

"""
Input Flash Address(DST): Destination Flash address where data bytes are to
be
written. The destination address should be a 256 byte boundary.

RAM Address(SRC): Source RAM address from where data bytes are to be read
.
Number of Bytes: Number of bytes to be written. Should be 256 | 512 | 1024
|4096"""

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
2009/10/11 Timo

> Miguel Angel wrote:
> > ... it's mandatory [to disable interrupts] when calling IAP
>
> Not true - see UM 20.4.10. But it is probably the easiest way to avoid
> problems.
> > If I'm not wrong, the minimum you can is in blocks of 256, and when
> > you write on a block you couldn't overwrite it (even if it's all
> > 0xff) because with every 4 bytes 1 ecc byte is stored in flash, and
> > it won't be 0xff.
>
> There is one ECC byte for every 16 bytes of data (UM 20.6.).
>
> If data is all 0xFF, then the ECC byte must be 0xFF. Otherwise you
> couldn't succesfully read just erased data because the ECC byte was
> erased too (UM 20.6.). So it actually is possible to write 16 byte block
> at a time by filling the rest of the data buffer with 0xFF. I have
> tested this with LPC2468.
>
> --
>
> Timo
>
>=20=20
>
[Non-text portions of this message have been removed]

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Miguel Angel wrote:
> ... Flash bytes from 0x0000 0000 to 0x0000 0003 ...

Which version of user manual are you reading? It is consistently 16 bytes in Rev. 02 - 25 July 2006 user manual.

--

Timo

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

This one for LPC2148, but it's older.

http://www.nxp.com/acrobat_download/usermanuals/UM10139_1.pdf

15 Aug 2005

If we check the 2006 version it's 16 bytes :-)

""""
The operation of ECC is transparent to the running application. The ECC
content itself is
stored in a flash memory not accessible by user=92s code to either read fro=
m
it or write into it
on its own. A byte of ECC corresponds to every consecutive 128 bits of the
user
accessible Flash. Consequently, Flash bytes from 0x0000 0000 to 0x0000 000F
are
protected by the first ECC byte, Flash bytes from 0x0000 0010 to 0x0000 001=
F
are
protected by the second ECC byte, etc.
"""""
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
2009/10/12

> Miguel Angel wrote:
> > ... Flash bytes from 0x0000 0000 to 0x0000 0003 ...
>
> Which version of user manual are you reading? It is consistently 16 bytes
> in Rev. 02 - 25 July 2006 user manual.
>
> --
>
> Timo
>
>=20=20
>
[Non-text portions of this message have been removed]

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )