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.

FCTLx registers cannot be written

Other Parts Discussed in Thread: CC430F6137

Hi,

i noticed during debugging my code that any write to the FCTLx registers has no effect. One exception is the LOCKA bit which can be toggled just fine but for example the LOCK bit always stays 1. The FCTL3 and FCTL1 registers have their reset values of 0x9658 and 0x9600 at the beginning

In my code i set the FCTL3 and FCTL1 registers according to the following lines.

FCTL3 = FWKEY;                     
FCTL1 = FWKEY + ERASE;

//dummy write to start the erase process

*((u16*)0x8000) = 0;

And according to the assembler code it does exactly what it should do:
 mov.w   #0xA500,&FCTL3
mov.w   #0xA502,&FCTL1

However if i step past each of the instructions then the register then the register values have not changed their value according to the debugger. FCTL3 is still 0x9658 instead of 0x9600 and FCTL1 still has the value 0x9600 instead of 0x9602.

I am using the CC430F6137 and my code is running from flash. My idea was that the LOCK and ERASE bits might be immediatly reset because the next instruction is fetched from flash. According to the example code and datasheet you just have to do a dummy write at a segment in order to start the erase process. However how should this work if the LOCK bit  is set and the ERASE bit reset until then? The ACCVIFG Flag is obviously set once the dummy write instruction is executed, however the segment is properly erased.

Thanks for any hints.




  • It's possible that the debugger simply does not update the display.
    Accessing memory during flash operation is not recommended (and signle-stepping duing an active flash write will give unpredictable results).

    However, writing 0 to the low-byte of FCTL3 does not have the effect you expect. You read 0x9658.
    BIT3 is read-only, and it is set if flash is ready. So this bit is expected to be 1 evne if oyu wrote a 0 to it. And BIT6 is inverted if you write 1 to it and unchanged if you write 0, so it is expected to be set too. A very confusing and error-prone mechanism, since an OR operation on any other bit will unexpectedly clear this bit.
    The only thing that's unexpected is the BIT4. It should be cleared by your write. Then again, perhaps the debugger is not updating the display.

    mark sonn said:
    The ACCVIFG Flag is obviously set once the dummy write instruction is executed, however the segment is properly erased.

    Why that? ACCVIFG is not set by a write to flash while LOCK bit is set. It is set if you read from flash while a flash write is performed (whcih can only happen when the code executes from ram).

    You don't write which MSP you use. Personally, I didn't have any problems writing to any MSPs flash, as far as I tried.
    And I doubt there is a problem ony yours too, since the FET uses a software snippet (written to ram, together with the data to be flashed) too, to flash your code into the MSP (which obviously worked).

    So I'm pretty much sure that the debugger is the bugger here.

  • Hi Jens-Michael,

    thanks for your answer. It really just seems to be a debugger problem. The ACCVIFG bit is not set at all if the code isnt run in singlestep mode, but set in singlestep mode right after the dummy write.

  • Almost every device errata sheet tells that you must not single-step through code that activates the flash controller or set breakpoints. The users guide also tells you that you even have to disable interrupts (clear GIE) during flash operations.

**Attention** This is a public forum