Hi,

when the MSP430F149 gets a little low voltage from a gold cap for some seconds
the flash is cleared; the 
MSP430F149 refuses to work again even after discharging all capacitators and
reset!
The problem is reproducible on any tested board.
What can be done against the flash clearing?

Regards

Rolf F.

I can't offer advice because I have no experience in this area, but
please
indulge my curiosity anyway:

Your code is performing flash writes and erases during normal execution?

You experience occasional brownouts (voltage drops below 2.7v)?

You have powered the device up after crash and read memory and it's all
reset?

During a brownout your system invokes the datasheet condition "If Vcc falls
below 2.7 V during a write or erase, the result of the flash write or erase
will be unpredictable."?

I guess it hadn't occurred to me that mass erase would be one of those
"unpredictable" outcomes, but I guess it sort of makes sense.  Could
your
system check for low voltage and suspend writes during that period?

--Bruce



> when the MSP430F149 gets a little low voltage from
a gold cap
> for some seconds the flash is cleared; the
> MSP430F149 refuses to work again even after discharging all
> capacitators and reset!
> The problem is reproducible on any tested board.
> What can be done against the flash clearing?
>
> Regards
>
> Rolf F.

Trying to run the MSP from a capacitor and perform flash writes is not 
feasible, The current spikes during flash write will almost certainly 
guarantee that the voltage drops below limits. In my own testing I have 
decided that 3V is the absolute minimum voltage that I'll allow flash 
writes at. The problem is that even monitoring the voltage from the cap 
won't work, since the dips occur after you've committed to the write.
I 
use some kind of regulation with all my systems that need to write 
flash, alongside batteries and direct monitoring of the battery voltage, 
so that I don't start a flash write on a borderline battery. It may help 
if you could put a small switching reg on the cap, but I doubt it. How 
do you know the flash is cleared? It may not reboot, but it may not be 
cleared. Have you dumped the flash contents after a failure? During the 
tests I did corruption was usually across segments,. not the entire memory.

Al

nobodyo@nobo... wrote:
> Hi,
> 
> when the MSP430F149 gets a little low voltage from a gold cap for some
seconds the flash is cleared; the 
> MSP430F149 refuses to work again even after discharging all capacitators
and reset!
> The problem is reproducible on any tested board.
> What can be done against the flash clearing?
> 
> Regards
> 
> Rolf F.
> 
> 
> 
> 
> .
> 
>  
> 
> ">http://docs.yahoo.com/info/terms/ 
> 
> 
> 

Hi,

> The current spikes during flash write will ...

There are no flash write routines in the code and programming adapters like FET
or BSL 
adapter are not connected! That's the reason why this is a big problem,
because this 
can happen suddenly at the customers home and then the device is dead for the 
customer!


> How do you know the flash is cleared? It may not
reboot, but it may not be
> cleared. Have you dumped the flash contents after a failure? 

No, but after 3 tries more than 5 Minutes discharching the capacitators and the
gold 
cap with switching of the supply voltage, a cable short and several seconds 
pressing the tested reset push-button there was no reboot. For the average
customer (without a flash adapter) the device is dead and i can see no other
reason 
than flash corruption.

Regards

Rolf F.

Is the JTAG fuse still intact? If it is then:
1. If you reprogram the device does it work?
2. Read out the FLASH memory from a dead device and
see if the code matches what you downloaded or if
wrong flash segments have been erased.

-Sumukh



--- nobodyo@nobo... wrote:
> Hi,
> 
> when the MSP430F149 gets a little low voltage from a
> gold cap for some seconds the flash is cleared; the 
> MSP430F149 refuses to work again even after
> discharging all capacitators and reset!
> The problem is reproducible on any tested board.
> What can be done against the flash clearing?
> 
> Regards
> 
> Rolf F.
> 
> 
> 


__________________________________

nobodyo@nobo... wrote:
> Hi,
> 
> 
>> The current spikes during flash write will ...
> 
> 
> There are no flash write routines in the code and programming
> adapters like FET or BSL adapter are not connected! That's the reason
> why this is a big problem, because this can happen suddenly at the
> customers home and then the device is dead for the customer!

The impression from your first post was that you were writing flash.

>> How do you know the flash is cleared? It may
not reboot, but it may
>> not be cleared. Have you dumped the flash contents after a failure?
>> 
> 
> 
> No, but after 3 tries more than 5 Minutes discharching the
> capacitators and the gold cap with switching of the supply voltage, a
> cable short and several seconds pressing the tested reset push-button
> there was no reboot. For the average customer (without a flash
> adapter) the device is dead and i can see no other reason than flash
> corruption.

You cannot possibly just jump to this conclusion. You must test it, and 
the only way to do this is to do a memory dump prior to the problem 
occurring, and then again after it has occurred, then compare the two. 
If they differ you have corruption, if not then you need to look 
elsewhere. I have never known the flash to corrupt for any reason that 
was not associated with long term write testing. Certainly in the 
thousands of MSP430 based boards I have in the field none has ever been 
returned with corrupted flash.

The 149 has a very poor POR set up. It is well known that it can hang 
the micro. I've known this to take 20 minutes before I could restart the 
board, until the problem was fixed. have you scoped the supply lines 
after shorting them? What is the slope on Vcc like? A simple reset 
button will do nothing if the micro has latched. Try grounding Vcc for 
20 seconds, then scope Vcc as you remove the short. What does Vcc 
measure after all your attempts to reset it?

Al

Hi,

> You cannot possibly just jump to this conclusion.
You must test it, and
> the only way to do this is to do a memory dump prior to the problem
> occurring, and then again after it has occurred, then compare the two. 

Ok, the content is the same but even after 10 minutes discharging all
capacitators with shorts and Reset the MSP430 is dead. The MSP430 can only be
waken up with new flashing with a BSL or FET adapter.


> The 149 has a very poor POR set up. It is well
known that it can hang
> the micro. I've known this to take 20 minutes before I could restart
the
> board, until the problem was fixed.

That must be the reason. What can be done against it and are you sure the hangup
is gone after 20 minutes?
Is it save to use a battery and keep the MSP430 in LPM3 or can the POR hangup
occur even in LPM3?

Regards

Rolf F.

nobodyo@nobo... wrote:
> Hi,
> 
> 
>> You cannot possibly just jump to this conclusion. You must test it,
>> and the only way to do this is to do a memory dump prior to the
>> problem occurring, and then again after it has occurred, then
>> compare the two.
> 
> 
> Ok, the content is the same but even after 10 minutes discharging all
> capacitators with shorts and Reset the MSP430 is dead. The MSP430 can
> only be waken up with new flashing with a BSL or FET adapter.

Are you using a crystal on the design? The easiest thing to do is to 
hold a dead short across the decoupling caps closest to the micro for 
about 20-30 seconds, to test this, it won't always clear the problem, 
especially if you have lots of big caps in there, but it normally will.

> 
> 
> 
>> The 149 has a very poor POR set up. It is well known that it can
>> hang the micro. I've known this to take 20 minutes before I could
>> restart the board, until the problem was fixed.
> 
> 
> That must be the reason. What can be done against it and are you sure
> the hangup is gone after 20 minutes? Is it save to use a battery and
> keep the MSP430 in LPM3 or can the POR hangup occur even in LPM3?

You can keep the MSP in LPM3. The problem only occurs when you turn 
power off, or remove power from the board, or power slowly increases or 
decreases through the operating threshold. If you measure the voltage on 
Vcc after turning off you will typically see something like 0.8V. this 
is too low to let the micro run, the micro hasn't performed a proper 
RESET, and cannnot restart as the voltage rises. The simplest solution 
if you aren't concerned for power is a small resistor across Vcc to 
bleed it. About 1mA usually does it. However in power conscious systems 
this is not enough. here you require an external RESET chip, set for 
about 1.8V, the minimum operating voltage of the MSP. You also need to 
ensure that your power supply does not have a long rise time. Remove 
large capacitance from your circuit. You don't need lots of large 
decoupling caps, these can cause long rise times if you're not careful.

Al

Hi,

> The 149 has a very poor POR set up. It is well
known that it can hang
> the micro. I've known this to take 20 minutes before I could restart
the
> board, until the problem was fixed.

the hangup is irreversible. Without new flashing the 149 is dead even after
discharging with shorts and waiting more than 2 days. Resetting 30 times does
not help.
With reading out via BSL adapter i see that the flash content is unchanged, so
it is a "flash blocking brownout" which occurs in approx. 25 % of the
cases switching the supply off and on. The error also occurs with a battery
powered supply, stabilised with a 10,000 uF capacitator, when the 149 switches
to/from LPM3.
After new flashing with a FET or BSL adapter with the same software (flash
content) the 149 starts without problems. 
I found out that the software 10 days ago did not produced this bug but the
routines for startup and switching to/from LPM3 are unchanged. What may be the
reason of this bug?

Regards

Rolf F.

Get rid of the big cap for a start. Other than that look at your
on/off circuit, is it possible that it is generating sopikes/bouncing?
haveing never experienced a single failure like you describe I don't
know the answer, but can suggest only tests you might make. You need
to establish some parameters for this failure. Does it only occur when
not hooked to C-Spy for example. If not then you may be able to use
C-Spy to trap what is happening.

1. Do you have Flash inhibit traps that will detect a flash write
attempt, or do you have an error handler for flash violations?

The following extract is from my INIT routine:-

;****** Initialise FLASH CONTROL REGISTERS

        MOV     #FWKEY,&FCTL1           	;
        MOV     #FWKEY+FSSEL0+FN1,&FCTL2 	;
        MOV.B   #(OFIE+NMIIE+ACCVIE),&IE1  	;Enables OscFault, NMI
&
Flash Violation interrupts

This guarantees a known state for the flash control registers, and
provides clean handling of a flash access violation. Put a trap or
counter here that toggles a LED or an I/O. 

2. Make sure you have ISR handlers for EVERY possible interrupt
source, and handle them . try trapping them in turn to locate the
source of the problem.

3. Take voltage measurement son the chip when it fails, and let us
know what they are. With a 10,000uF cap I'm not surprised you can stay
latched for days. I use 1uF and that can latch me for 20 minutes.

4. Just as a test put a 470R resistor across VCC and GND, and
disconnect your big cap. See if the problem still occurs.

5. If this works try it with the big cap in circuit.

Let me know the results if you can. I'm not receiving emails right
now, this spam is flooding my mailbox, so legitimate emails are
bouncing. Yahoo has already suspended my account twice due to that, so
in the interim I'll work through the groups site.

Al




--- In msp430@msp4..., <nobodyo@w...> wrote:
> Hi,
> 
> > The 149 has a very poor POR set up. It is well known that it can hang
> > the micro. I've known this to take 20 minutes before I could
restart the
> > board, until the problem was fixed.
> 
> the hangup is irreversible. Without new flashing the 149 is dead
even after discharging with shorts and waiting more than 2 days.
Resetting 30 times does not help.
> With reading out via BSL adapter i see that the
flash content is
unchanged, so it is a "flash blocking brownout" which occurs in
approx. 25 % of the cases switching the supply off and on. The error
also occurs with a battery powered supply, stabilised with a 10,000 uF
capacitator, when the 149 switches to/from LPM3.
> After new flashing with a FET or BSL adapter with
the same software
(flash content) the 149 starts without problems. 
> I found out that the software 10 days ago did not
produced this bug
but the routines for startup and switching to/from LPM3 are unchanged.
What may be the reason of this bug?
> 
> Regards
> 
> Rolf F.