Hi All,

I'm a newbie to the group and to MSP430 development...

I'm working on an simple battery-powered product that measures sensors 
with the F149. It uses a simple serial command structure to communicate 
to the outside world (me).

Occasionally the data and code I have stored in flash get's corrupted 
at runtime. Seemingly random flash segments get initialized to 
unprogrammed "FF" state. We're talking swiss cheese. Typically I
loose 
my vector table too.

I've heard that port voltages above or below TI's maximums (even if 
only tenths of a volt) may cause the behavior I've seen. Can anyone 
confirm this is the case? I have protection circuitry for the ports, 
but I haven't ruled out my circuitry is inadequate.

I've seen this flash corruption often enough and across different units 
to be motivated to find a cause. Problem is, I can't reproduce it 
regularly enough to help me chase it down.

Other issues that may be relevant and spark an idea:

The product stores data in flash so code exists to write and erase 
segments; however, i can't see how this code is getting executed on an 
error and across non-contiguous segments.

The product can change baud rates on the fly. Is clock/timer stability 
an issue with the flash?

The serial processing code looks like it protects against buffer 
overflows... Again, I can't imagine a buffer overflow turning my flash 
into swiss cheese.

Any ideas?

~Todd

--- In msp430@msp4..., Todd Martin <todd@d...> wrote:
> Occasionally the data and code I have stored in
flash gets
> corrupted  at runtime. Seemingly random flash segments get 
> initialized to unprogrammed "FF" state. We're talking swiss
> cheese. Typically I lose my vector table too.
> 
> I've heard that port voltages above or below TI's maximums 
> (even if only tenths of a volt) may cause the behavior I've seen.

Yes, the minimum is 2.7 volts during FLASH programming. Also, the 
clock speed is defined in a relatively narrow range for programming. 

If this is happening on its own, i.e. not while you're programming, 
then you've probably got a software problem that is being triggered 
by a power issue. I just had a customer having this same problem. He 
was losing about one out of 400 boards during production. He had a 
RAM location as a flag to determine whether or not to initialize his 
FLASH and RAM. Most compilers' CSTARTUP code will erase the RAM, and 
he hadn't changed that. He also had re-entrant code that could screw 
up his C stack (jumping into main() from subroutines, under certain 
error conditions).  On top of all that, he had other problems, like 
not using include files and the linker correctly - definitely an 
inexperienced programmer. 

ESD hits and power switch bouncing can sometimes actually cause the 
micro to start up and run some code. It may run through a few 
hundred cycles reliably, or there may be a brownout that causes the 
code to run erratically.  For parts without brownout protection, the 
micro will probably run down to 1V or so (out of spec, don't do this 
on purpose!!), but the FLASH may be unreliable at higher voltages, 
so you could be jumping into random code. Brownout protection resets 
the micro somewhere around 1.6V, before the FLASH starts losing 
bits. The 'F149 does not have brown-out protection. If you don't 
have an external reset mechanism, consider upgrading to the pin-
compatible 'F169. You gain brownout, and maybe some things you don't 
need in your system (2-channel DAC, 3-channel DMA, and I2C), but 
your 'F149 code should drop in with only some header changes.

The datasheet lists "Absolute Maximum Ratings". If your Vcc is going 
higher than that, don't count on anything to continue to work. Same 
thing with connecting I/O to higher voltages - there are ESD 
protection diodes that will feed the higher voltages back to the 
processor. 

Good luck,
Mike.

The most common cause in my experience is low Vcc. Although Vflash is 
rated as >=2.7V I do not allow flash access below 3V. Other wise I find 
the flash highly stable.

Any voltage above the rated voltages could potentially cause problems. 
If this may be the case a serial resistor of adequate value, combined 
with the built in protection diodes should be adequate. If ESD is an 
issue of course you must separately protect for that. What resistor is 
adequate? the diodes should not be forced to handle more than 2mA, hence 
  choose a resistor that, typically, gives around 100uA or less with the 
largest known spike voltage.

Al

Todd Martin wrote:
> Hi All,
> 
> I'm a newbie to the group and to MSP430 development...
> 
> I'm working on an simple battery-powered product that measures sensors

> with the F149. It uses a simple serial command structure to communicate 
> to the outside world (me).
> 
> Occasionally the data and code I have stored in flash get's corrupted 
> at runtime. Seemingly random flash segments get initialized to 
> unprogrammed "FF" state. We're talking swiss cheese.
Typically I loose 
> my vector table too.
> 
> I've heard that port voltages above or below TI's maximums (even
if 
> only tenths of a volt) may cause the behavior I've seen. Can anyone 
> confirm this is the case? I have protection circuitry for the ports, 
> but I haven't ruled out my circuitry is inadequate.
> 
> I've seen this flash corruption often enough and across different
units 
> to be motivated to find a cause. Problem is, I can't reproduce it 
> regularly enough to help me chase it down.
> 
> Other issues that may be relevant and spark an idea:
> 
> The product stores data in flash so code exists to write and erase 
> segments; however, i can't see how this code is getting executed on an

> error and across non-contiguous segments.
> 
> The product can change baud rates on the fly. Is clock/timer stability 
> an issue with the flash?
> 
> The serial processing code looks like it protects against buffer 
> overflows... Again, I can't imagine a buffer overflow turning my flash

> into swiss cheese.
> 
> Any ideas?
> 
> ~Todd
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
>