This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

flash memory corruption on msp430f1471

Other Parts Discussed in Thread: MSP430F1471

I'm seeing single and double bit errors splashed around the program code area of flash memory after several hours of use. I've disabled all sections of the firmware that attempt to read and write to information ram , but still accumulate an error or 2 after a few power cycles. These are both 1 to 0 and 0 to 1 bit flips and  persist until the chip is re-flashed. It ends up being very nasty, the board appears to run ok until the  bit errors accumulate enough to stop the program from executing. I've even seen the interrupt vector get flipped on one occasion. What can be doing this ? The power appears clean, at 3.3 V, with no over voltage spikes on power cycle. Turn on & off are a bit jittery, but reset is held low on power up until it stabilizes. Any Ideas ? This is on an MSP430F1471 running at 8 Mhz.

  • If power is slowly dropping below the required voltage level for flash operation (see datasheet), it may be that the CPU hasn't crashed yet but the flash is already failing. In this case, flash corruption may appear. The MSP430F1471 has no brownout detection nor voltage supervisor. So either ensure that supply voltage switches between 0V and VCC and back almost instantly or add an external supply voltage supervisor that holds the MSP in reset state while supply voltage is below the required level. Not just for power-on but also for power-down. A regulator with 'power good' output should be sufficient, if it works on power-off too (not all do).
    The pin- and more or less software compatible MSP430F16xx devices have both, brownout detection and programmable voltage supervisor.

    Btw: you know that for 8MHz operation, you need 3.6V supply? With 3.3V, you're running outside the specifications (at 3.3V, you are limited to ~6.5MHz, which is still above the maximum the DCO will produce)
  • Thanks for some input. I've been mildly concerned about the 3.6 volt spec for years but have not seen the corruption issue until recently. Back 9 or so years ago when the '147 was new, before the brownout problem was public, the rep I was working with suggested that 8 Mhz would be good even at 3.3 volts, even if out of formal spec. Even though my experience verifies this to be true, all future production will have this changed to meet spec.
    At any rate, I implemented the software suggestions from TI's faq regarding reliable use of the flash ROM . As it turns out I was doing something (actually, almost everything) stupid, not setting the flash controller clock at all, not re-locking the flash after write, and then going into a shutdown immediately after a flash write, with no regard for halt/catch fire during shutdown. After making the appropriate code corrections, and still concerned about the 3.3/3.6 vdd issue, I was happily surprised to see the problem corrected. I am surprised that this chip even pretended to run correctly under these conditions, yet the only failure mode of the broken code was a dozen or so random bit "rots" in program ROM after maybe 200 power cycles ! After following the code checklist provided, excepting the 3.3 V, the units began holding fine with 0 bit losses at over 1200 power cycles, as had the predecessor product . After checking, I noticed that I had stripped out a bit too much code after porting code from a product with more features to the new simpler product. The key items were setting the flash controller clock, adding a 2 mS delay between writing to flash and toggling the power supply shutdown pin, and following the shutdown with a c code "while(1)". All appears fine now. So tempting to blame the poor silicon, as usual, and yet to pass QC ( 100 power cycles for the product/functional test) when so obviously miss-coded was amazing. FYI, I have had no problems with original product, using 3.3 V at 8 Mhz. It only appeared after the bad code rewrite. So I'm saying problem solved, with some reservations on the 3.6 volt issues, but holding off on a retro-active regulator ECN for the old product (with the original correct code) unless it proves necessary. I was lucky to have only 1/2 dozen of the new ones in the field.
  • While the 3.6V are (at least theoretically) required for 8MHz CPU speed, the flash doesn't need this voltage. It has its own charge pump for programming voltage (that works down to 2.4V or so), and you adjust the flash controller write clock to the main clock anyway.
    So yes, the MSPs perform remarkably well even if operated outside the specs. TI obviously has quite some safety margin in the design.

    BTW: failure due to insufficient voltage/overclocking can go from instant crashes and erroneous code execution through calculation errors to subtle problems like certain instruction sequences not working correctly (which may not appear at all in your specific code) or problems when debugging. Or it works. After all, 0.3V aren't that much of a difference and almost in the regulation range of some cheaper 3.3V regulators :) Also, 3.6V guarantee operation over full temperature range. In a limited range, 3.3V might be more than sufficient.
    If the design allows a simple replacement of a 3.3V regulator by a 3.6V type, you should do it. If not, well, maybe a more thorough QC test (with focus on stability, perhaps at different temperatures) might be sufficient.

**Attention** This is a public forum