MSP430F149 loosing flash content

Hi Bernd,

Have you taken a look at our Flash Best Practices page?  The most common way for flash to get corrupted is runaway code, typically a stack overflow or undefined ISR, or similar.  This could cause the device to "run in the weeds" and potentially start executing random code, even from the BSL.

A couple of quick questions:

• Does the application firmware modify flash intentionally at any point, or are they using the BSL at any point?
• Is it possible the boards were subjected to an ESD event (or similar)?

Mike

One more question: you say that supply is ok. Are you sure? How your device control supply voltage? Especially when it is powered down? I ask because most of f1 series systems experiencing flash contents loss, do not use external supply voltage monitor thus is subject of brownout.

Hi,
as mentioned above, the most common problem for flash corruption would be due to supply voltage problem when running the device at higher frequency. It is described more in detail here:
processors.wiki.ti.com/.../MSP430_FAQ
So could you tell in which frequency is the MSP430 operated to run the application?
Since the MSP430F149 doesn't have any internal supervisor, we would recommend to use an external one:
www.ti.com/.../supervisor-reset-ic-products.page

Hello,

I am one of the developers of the device which has described problem above.

Thanks a lot for your prompt answers and excuse my delay.

Mike

A couple of quick questions:

• Does the application firmware modify flash intentionally at any point, or are they using the BSL at any point?
  • Our firmware has routines for modifying flash, but write address is checked and write can be performed only to some permissible area. Via this routine whole flash can't be erased. BSL is not used. Bootloader is in a specific sector. It is also erased.
• Is it possible the boards were subjected to an ESD event (or similar)?
  • I can't exclude this, but devices were sent back from different customers, so it is unlikely, that all different customers with concerned devices work in a similar enviroment

Ilmar

One more question: you say that supply is ok. Are you sure?

No, the problem is, that we get device back from customer, but till now we have no information, what happens directly before erasure, so also no information if supply is correct or not.

How your device control supply voltage? Especially when it is powered down?

Torex XC61CN2902 is used for this purpose.When +3V3 voltage goes under 2.9V, Torex should reset microprocessor. But I think due RC components (cause of EMI problems) can reset action (by power off) come later. Power down is controlled by processor(power off is switched, when everything necesarry is done)

Leo Hendrawan

So could you tell in which frequency is the MSP430 operated to run the application?

8MHz @ 3,3V 

But according information from pdf combination of 8MHz and 3.3V supply means, that processor is bit overclocked. Is this a problem?

I wonder, why only this type of device is concerned. The other type uses also the same bootloader, the same RCcomponents at Torex etc.

Thanks in advance for further hints

Matthias

Hi Matthias,

technically you are using the F149 outside its operating conditions with 8MHz @ 3.3V which means that functionality is not guaranteed anymore. As Mike called it, the device may "run in the weeds".

But aside from that, are you sure that the devices were programmed correctly before they were send to the customer?

Thanks and best regards,
Christoph

Hi Matthias,
you are right, you are basically "overclocking" the device when running at 8 MHz with 3.3V as the datasheet requires 3.6V in this case.
So basically you are "lucky" to be able to run 8MHz with 3.3V on the other device.

Please notice that these values are the spec which we tested, that doesn't mean that the device can't do more than that - e.g. in this case 8MHz with supply less than 3.6V, but again only we guarantee the device work properly with 3.6V.

I would suggest to increase the supply voltage and use external supervisor to avoid problems in the future.
Thanks.

Hi Christoph,

but if the device run in the weeds, it does not work anymore, but memory should not be empty.

Chr: But aside from that, are you sure that the devices were programmed correctly before they were send to the customer?

Yes, because devices were calibrated and have to pass an extensive final test.

Hi Leo Hendrawan,

may this little overclocking the reason for erasing whole memory inclusive bootloader?

Best regards(also to Christoph)

>When +3V3 voltage goes under 2.9V, Torex should reset microprocessor
So your device starts at 2.9V and immediately set it's clock to 8MHz? - Then not only power-off but also power-on "running out of spec, thus in the weeds" could be your problem.

>but if the device run in the weeds, it does not work anymore, but memory should not be empty.
That's the point that while running in the weeds, device can find flash erase code on the path and execute it. When you are not sure that CPU can fetch and execute instructions correctly, you cannot be sure about anything in your microcontroller. If you have no code bugs and voltage supervisor is confirmed to work on power_on/power_off then I have no other ideas than - change the chip to one having SVS. They do not have so many "flash is gone" reports.

[edit] I would put some (dozen) test devices in thermal chamber at max specified temperature and do extensive power cycling for couple of days.

Matthias,

Talking about over clocking, IT's own product, the G2 LaunchPad, is over clocking a MSP430F1612 at 12 MHz. Power is from USB +5V regulated to 3.6 V. I have never heard that G2LP accidentally erased all the Flash on its MSP430F1612.

In your case, you are over clocking at 8 MHz with power as low as 2.9V. I think it is very unlikely that this can directly cause total erasure of Flash. It is also very unlikely that ESI etc. can directly cause total erasure. But you do have fragments of code that unlock the Flash Controller and do various Flash operations. I think over clocking, ESI, etc., can easily cause the CPU go into the weeds. Once that happens, there is no telling how the CPU found its way into the fragments of you code that may cause a total erasure.

If possible, could you post your bootloader code? And also your power supply and monitoring portion of your schematics?

-- OCY

BTW, I have examined the code inside the MSP430F1612 on the G2LP. It also has a bootloader in the Main Flash (they do not use the BSL-ROM) the Schematics of G2LP can be found on pages 14 - 19 here