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