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.

MSP430G2553: Delay from Stop WDT being called and actually being executed

Part Number: MSP430G2553
Other Parts Discussed in Thread: MSP430WARE

Hello, 

So I have been observing this strange behavior where I try to write to the flash but immediately after writing it would cause a reset. After further investigation, we found in one of the forums that "CPU instructions cannot be executed during flash writes". We concluded that even though we stop the WDT there needs to be a wait before Erase bit is set for what we assume is allowing execution of the command to turn off the WDT to finish in its entirety. This was not documented anywhere in the examples we looked through. We were wondering if this is an expected behavior or if there is another underlying issue. We are using MSP430ware_3_80_14_01. The snippet of code below is how we were writing to flash.

WDTCTL = WDTPW + WDTHOLD; 

// Wait inserted here

FCTL1 = FWKEY + ERASE;                  // Set Erase bit
FCTL3 = FWKEY;                          // Clear Lock bit
dest[0] = 0;                            // Dummy write to erase Flash segment
FCTL1 = FWKEY + WRT;                    // Set WRT bit for write operation

for (uint8_t i=0; i<size; i++)
{
    *dest++ = *settings++;
}

FCTL1 = FWKEY;                          // Clear WRT bit
FCTL3 = FWKEY + LOCK;                   // Set LOCK bit

WDTCTL = WDT_ARST_1000;

  • The CPU is held after the dummy write (dest[0] = 0), not before. I count 8 cycles, more or less, between stopping the dog and erase starting.

    The example in the guide writes to FCTL2, FCTL3, and then FCTL1. Order may or may not matter but the settings in FCTL2 do. Did you set those somewhere else? So that the flash clock is within specifications? The defaults (MCLK/3) are usually OK if you haven't changed the clock configuration.

    The MSP430 is pipelined so the hazard isn't instructions taking longer to execute than you think but instructions beginning execution before you expect. This is because the next instruction is fetched and scheduled before the current instruction is finished. More or less. This is why you generally put a NOP after setting a LPM mode. That instruction is going to be executed before the LPM mode takes effect.

**Attention** This is a public forum