Forums

After you LOCKed FCTL3, you can go ahead and do what ever you want the CPU to do.

That is the problem, the CPU hangs long after I LOCK the flash. I was expecting the CPU to hang sometime before this.

Chris Jones73762

That is the problem, the CPU hangs long after I LOCK the flash. I was expecting the CPU to hang sometime before this.

When you do the 'dummy write', the flash controller will start the erase and disable the flash access. However, the CPU will simply continue, reading teh next instruction. Now the flash is inoperable, the flash controlelr will simply return 0x3fff, which teh CPU will itnerpret as 'JMP $'. No harm done. As soon as the flash is operable again, it will get the 'real' instruciton and continue.

However, if you had a breakpoint on the instruction after the dummy write, it will be triggered by the first attempt of the CPU to read the next instruction. Right at the start of the erase cycle.

Keep in mind that the breakpoints are 'instruciton fetch breakpoints' and not 'instruciton execution breakpoints'.

Thank you for your response, while seeing the problem I thought exactly the same thing. Unfortunately, I see the problem even when not debugging or halting on a break point. I have set some LEDs to blink at different  intervals and another LED to light only while in my erase routine. Once the LED that indicates I am in the erase routine goes off, (meaning I have left the routine, erase should have finished) then my other LEDs that are blinking on regular intervals hang and the WDT resets. All signs point to the erase happening immediately. (ie: I can set a while loop in my erase routine to wait for the memory to read back 0xFFFF) But then I get this strange CPU hang after leaving the erase routine. Without the erase routine in my code my code executes without any WDT resets.

I noticed that in your erase funciton you do not disable interrupts.

While an erase is in progress, flash is not available. Any request will be responded with 0x3fff. While this will make the CPU jump in place, it will also return 0x3fff as the ISR address for any incoming interrupt. Then the PC will be loaded with 0x3fff and then jump there on place until the erase is done. Once the flash controller is done, the cpu will try to execute code at 0x3ffe (LSB ignored) with interrupts disabled.
Depending on what the flash content at 0x3ffe is, anything can happen.

BTW: if the WDT is active, you should reset it before you trigger the erase. :) (and immediately after)

No luck.... this is my code now:

void erase_FLASH(unsigned int *Flash_ptr)
{
    
  unsigned int *erase_ptr;
 
    LED2_ON;
    ISR_OFF;                                                                                             // defined as _BIC_SR(GIE)
    WDTCTL = WDTPW + WDTHOLD + WDTCNTCL;                     //    clear and Stop WDT
      FCTL2 = FWKEY + FSSEL0 + FN5 + FN4;             // MCLK/48 for Flash Timing Generator
     FCTL3 = FWKEY;                            // Clear Lock bit.
     FCTL1 = FWKEY + ERASE;                                     // Set Erase bit
 
     erase_ptr = (unsigned int *)Flash_ptr;                    // copy Flash pointer into erase pointer so that flash
     *erase_ptr = 0xFFFF;                                       // dummy write to erase Flash segment.


    FCTL3 = FWKEY + LOCK;
                    
    CLRWDT();                                     //    Setup and clear WDT defined as WDTCTL = ( WDTPW | WDTCNTCL | WDTSSEL )
    LED2_OFF;
    ISR_ON;                                        // defined as _BIS_SR(GIE)
return;

Still causes my device to reset. Because WDT is disabled during the erase function the hang must be happening after I re-enable. If I never re-enable it my device no longer resets but I can see a definate hang from my timer LEDs.

Thanks for your continued help.

Hi team,

Is there an update available regarding this inquiry?

Regards,