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.

MSP430F6659: Error erasing Flash bank

Part Number: MSP430F6659

Hello, 

I'm having trouble with my flash bank clear subroutine.

I always delete the same memory bank when starting program execution or after a reset.


Normally it works fine, but sometimes the BUSY flag stays active and does not exit the subroutine.

This is my subroutine.

void cmdFlash_BankErase(uint8_t * flashAddress){
    SFRIE1 &= ~WDTIE;                         // Disnable WDT interrupt
    WDTCTL = WDTPW | WDTHOLD;                 // Stop WDT
    do {} while(FCTL3 & BUSY);                // Wait for !BUSY

    FCTL3 = FWKEY;                            // Clear Lock bit
    FCTL1 = FWKEY|MERAS;                      // Set Erase bit for segment erase

    * flashAddress = 0;                       // Dummy write to erase Flash seg

    do {} while(FCTL3 & BUSY);                // Wait for !BUSY

    FCTL3 = FWKEY|LOCK;                       // Set LOCK bit
    SFRIE1 |= WDTIE;                          // Enable WDT interrupt
}

I am doing something wrong?. What can be the cause of this error?

I could leave WDT active with a long time (severals minutes), so that in normal operation it does not affect erasing Flash and if the erasing process fail, the micro Flash can recover?


Regards,

  • Hi Marcos,

    Do the problem happen on one chip or multi chips?  You could try another device to see whether it will happen. Does it happen only in Bank erase? 

  • Hi Allen,
    The problem has happened on several boards with the MSP430F6659 (the boards are similars), but it can take months without it happening. I reset the flash bank once a day. It only happens deleting the Flash bank.

  • Hi Marcos,

    Is the supply power or clock abnormal when this happened?  Dose this always duplicate on several specific board?

  • I have not detected anomalies in the clock, nor in the power supply when it has happened. It is an error that happens sporadically. There are boards where it has never happened and others where it happens after weeks or months of normal operation.
    I'll set up a test that reboots the micro cyclically every 20 minutes and checks the clock and source, although I think that if the clock or power supply failed, the micro would reboot. In my case the micro hangs but I can see  a 16Khz in ACLK (pin 34).  

  • Hi Marcos,

    Have you try to change a new device to the board with this problem? Do you find some common thing on these board or find the way to duplicate this? If you find the duplicate way, we may find the reason.

  • Hi Allen,
    On one of the failed board I prepared a test that cyclically erased a Flash bank and normally never exceeded 10 cycles without the micro hanging in the erasure process.

    I changed the subroutine to disable all interrupts, not just the WD and it has failed no more and have hit hundreds of clear cycles.

    This is my subroutine now:

    void cmdFlash_BankErase(uint8_t * flashAddress){

    SFRIE1 &= ~WDTIE; // Disable WDT interrupt

    _disable_interrupts();

    WDTCTL = WDTPW | WDTHOLD; // Stop WDT
    do {} while(FCTL3 & BUSY); // Wait for !BUSY

    FCTL3 = FWKEY; // Clear Lock bit
    FCTL1 = FWKEY|MERAS; // Set Erase bit for segment erase

    * flashAddress = 0; // Dummy write to erase Flash seg

    do {} while(FCTL3 & BUSY); // Wait for !BUSY

    FCTL3 = FWKEY|LOCK; // Set LOCK bit

    _enable_interrupts();

    SFRIE1 |= WDTIE; // Enable WDT interrupt
    }

    In the examples only the WDT was disabled before erasing the Flash bank. Is it necessary to disable all interrupts ?. It is right?

  • I changed the subroutine to disable all interrupts, not just the WD and it has failed no more and have hit hundreds of clear cycles.

    Are your interrupts handlers in flash or have they been copied to RAM?

    Executing interrupts during Flash read/write was a previous investigation using a MSP430F6659 which showed a crash when a RAM-base interrupt vector was enabled during flash programming.

  • Hi Marcos,

    It seems that the interrupt makes some impact in erasing flash. As the ticket Chester provide, during the flash operation interrupt may cause unpredictable problem.