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.
Part Number: MSP430F5437A
We use MSP430F5437A in our product and observed flash corruption instances happened in field. Below are the details –
We have quite few returned units from field where flash got corrupted randomly (we found some instances where info memory was also corrupted)
Following are few points, we are not sure the MSP’s behavior during those situations –
1. Is it OK to perform flash erase/write operation from ADC_ISR (or any ISR) context?
2. Our flash routines are guarded through following logic -
unsigned int gieState = __get_SR_register() & GIE;
/*** Flash erase/write operations *********/
__bis_SR_register(gieState); // restore the GIE status
Since we erase/write flash inside the ADC_ISR, _disable_interrupt() and __bis_SR_register() gets called from ADC_ISR context. Is it OK to do so ?
3. Code uses ‘Long-word write’ mode for flash write operation. It uses memcpy() lib function to write into flash instead of running for loop…Is it OK to use memcpy() lib function instead of conventional for loop, after unlocking the flash ?
4. What if flash erase or write operation is still in-progress and supervisory IC issues a RESET pules? Will the flash memory (or info) which are not targeted for erasing/writing see any corruption?
5. The switching of MCLK between 4 MHz to 8 MHz and ice-versa through ISR context cause any harm?
Thanks for your detailed post. I wouldn't recommend switching the MCLK frequency around but would rather see it at a fixed frequency. I'm concerned that adjusting the MCLK frequency is pushing your Flash Controller frequency out of spec which could cause memory corruption. Also, your supply voltage may not be high enough to support the higher frequencies. I wouldn't use the memcpy() function but would instead access the memory as we do in our code examples, either register-level or DriverLib.
Please take some time to read through the Debugging Flash Issues on the MSP430 Family of Microcontrollers application report to learn more about what things can cause memory corruption and how they can be fixed (e.g. Table 1). This will be more helpful and more comprehensive than if I just listed them out here in the thread manually.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.