Hi all,
I am using MSP430F149 controller in one of my application. I am facing
problem of flash corruption for calibration data I stored in
controller.
Hs somebody faced same problem of MSP430F149 flash corruption Or any
other controller ?
If yes, pls let me know the reasons for flash corruption and remedy if
any.
Thanks in advance for your help,

BAB

bab wrote:
Hi all,
I am using MSP430F149 controller in one of my application. I am facing
problem of flash corruption for calibration data I stored in
controller.
Hs somebody faced same problem of MSP430F149 flash corruption Or any
other controller ?
If yes, pls let me know the reasons for flash corruption and remedy if
any.

All flash chips have limited write capability. Some chips actually
move data around so that when you write it, you are not writing
to the same spot each time. USB memory sticks have this implemented.
The "disposable" digital camera sold a few years ago did this in
software,

Eventually the memory becomes unuseable in spots that are written often,
for example if you use a memory chip as a DOS formated file system,
the FAT (file allocation tables) and master directory get written many
times as you write a file.

If for another example, you are writting the value of a sample to the
same spot every millisecond, the chip will become unuseable in around
a minute, depending upon the chip.

Geoff.

--
Geoffrey S. Mendelson, Jerusalem, Israel N3OWJ/4X1GM
IL Voice: (07)-7424-1667 Fax ONLY: 972-2-648-1443 U.S. Voice: 1-215-821-1838
Visit my 'blog at http://geoffstechno.livejournal.com/

bab wrote:
Hi all,
I am using MSP430F149 controller in one of my application. I am facing
problem of flash corruption for calibration data I stored in
controller.
Hs somebody faced same problem of MSP430F149 flash corruption Or any
other controller ?
If yes, pls let me know the reasons for flash corruption and remedy if
any.
Thanks in advance for your help,

BAB

Flash corruption can happen at times when the microcontroller is
allowed to "run" when operating conditions are not within the
guarenteed limits specified by the manufacturer. Under such conditions
the code may not run in the intended manner and the microcontroller may
execute strangly.

Of particular concern are instances wherein you actually have FLASH
writing routines within the firmware code itself. If there is a glitch
or upset of some sort that sends the microcontroller out to lunch these
routines could be accidently invoked and cause one or more writes into
the FLASH area.

This type of upset problem can also exist on microcontrollers that have
on-board EEPROM memory.

Here are some things you can do to make your system less likely to
encounter FLASH upset.

1) Use a precision reset supervisor / voltage monitor that is external
to your microcontroller that monitors the power supply rail to the
microcontroller. If the applied voltage on the rail goes outside the
normal operating range for the microcontroller then force the
microcontroller into hard reset. Too many of the on-board reset
supervisors that manufacturers put on the microcontroller chip are not
precise enough or only measure when the voltage is too low (as opposed
to measuring when it is too high or too low).

2) Make sure to implement the watch dog timeout scheme in to your
product so that if a voltage, current, or EMI transient occurs and
upsets your microcontroller code flow that you have some chance of
recovering from it. The longer an errant program runs the more likely
it is to accidently run into those resident flash writing routines.

3) Setup your calibration data base in the FLASH with two copies, each
with a robust CRC type check code attached. Then design your system so
it has a chance to run even if one copy of the calibration data is
corrupted.

4) Setup the micocontroller with an additional I/O pin or two that must
be asserted to certain logic levels to enable the FLASH write
calibration process. At other normal operational times put these I/Os
onto an alternate idle state via pullup or pulldown resistors. Then
right inside the lowest level subroutines that perform the FLASH write
operations on a byte by byte basis qualify the process every time on
the enable assert levels being present on these additional I/O lines.
Errant code execution is now less likely to be able to enter the FLASH
write routine and do any damage as the the routine will kick out if the
I/Os are not at the correct state.

- mkaras

On Tue, 19 Sep 2006 10:11:03 +0000 (UTC) (Geoffrey S.
Mendelson) wrote in Message id: :

bab wrote:
Hi all,
I am using MSP430F149 controller in one of my application. I am facing
problem of flash corruption for calibration data I stored in
controller.
Hs somebody faced same problem of MSP430F149 flash corruption Or any
other controller ?
If yes, pls let me know the reasons for flash corruption and remedy if
any.

Is the corruption occurring during write cycles, or does it happen after
the device is written to?

Have you checked the errata listing for this device?
http://focus.ti.com/lit/er/slaz017a/slaz017a.pdf

All flash chips have limited write capability. Some chips actually
move data around so that when you write it, you are not writing
to the same spot each time. USB memory sticks have this implemented.

This is referred to as "wear leveling"

The "disposable" digital camera sold a few years ago did this in
software,

Eventually the memory becomes unuseable in spots that are written often,
for example if you use a memory chip as a DOS formated file system,
the FAT (file allocation tables) and master directory get written many
times as you write a file.

If for another example, you are writting the value of a sample to the
same spot every millisecond, the chip will become unuseable in around
a minute, depending upon the chip.

Of course, if you have a application that writes to a memory location that
often, you should be using SRAM or DRAM. The device the OP is using has a
minimum life expectancy of 10K write/erase cycles. That being said, most
modern flash memory devices are good for 100K write cycles or more.