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.

MSP430F5529: Erasing bank2 using code that runs from bank0


It seems that trying to erase bank 2 using a code running from bank 0 causes bank 0 to erase also.

So I guess I should try running this code from RAM.

Is there a more elegant solution ?

The link:  contains similar example.

But this link does not work.

Can you help ?




  • Originally, a bank erase was intended to allow flash read access ot the other banks during the erase. However, due to a bug (check the devices errata sheet) this does not work (neither can you continue running the code, nor does teh flash controller issue teh 'jump on place' fake instruction 0x3fff, so the processor crashes or runs wild, maybe triggering more erases) and you'll need to trigger the bank erase from ram and return only after the erase is finished.

    The code in ram, however, can beas short as

                          "  movx    #0,        &0x10000                       \n"
                          ".WaitForBankErase:                                  \n"
                          "  bit     %[_BUSY],  %[_FCTL3]                      \n"
                          "  jne     .WaitForBankErase                         \n"
                          "  ret                                               \n"

  • Hello,

    I tried using the sample code: MSP430F552x_flashwrite_01.c

    The cmd file was changed so the complete code rus from RAM.

    The address of the flash to write was changed from 0x1880 (information flash) to 0x14400 (bank 2)

    But when I ran the code, the flash is not written (according to the memory view of 0x14400).

    Can you help ?



  • Zvi Vered said:
    The cmd file was changed so the complete code rus from RAM.

    It woulod have been easier just to put the funciton (or rather a small function stub that jsut does the write and the wait) into the initialized variable segment. This way, the linker will link all function calls fine and copy the code from flash to ram at startup. No messing with segments.

    Zvi Vered said:
    But when I ran the code, the flash is not written

    Was the code executed at all? It is possible that you have moved the code to ram and it ahs been written there, but after power-up, RAM is empty, and your code gone. Or the code was never written to RAM at all (uninitialized ram, just like it happens with uninitialized data) and the call to your function jumped into the empty void of uninitialized volatile ram.

    To tell you more, I'd need to know what you've done. exactly (meaning: post the code and any other modification you've done).

  • Hello,

    I took the code: MSP430F552x_flashwrite_01.c and ran all of it from RAM.

    No opcode was run from flash.

    The only change I did is marked in red:

    void write_SegC(char value)
      unsigned int i;
      char * Flash_ptr;                              // Initialize Flash pointer
      Flash_ptr = (char *) 0x14400;      //  Original address: 0x1880
      FCTL3 = FWKEY;                            // Clear Lock bit
      FCTL1 = FWKEY+ERASE;            // Set Erase bit
      *Flash_ptr = 0;                                // Dummy write to erase Flash seg
      FCTL1 = FWKEY+WRT;                // Set WRT bit for write operation

      for (i = 0; i < 128; i++)
        *Flash_ptr++ = value;                  // Write value to flash
      FCTL1 = FWKEY;                          // Clear WRT bit
      FCTL3 = FWKEY+LOCK;             // Set LOCK bit

    Before running I loaded  another program to flash bank 0.

    After running the code, bank 0 was erased also ( and not only bank 2).

    Can you help ?


  • Possibly a problem with the type range.

    Flash_ptr is an int (16 bit) pointer, so the long (20 bit) value you assigned to it is truncated. Don't you get a 'conversion my lose significant bits' or 'constant too large' warning when compiling this?
    Unless your compiler supports 20 (32) bit pointer variables (large data mode) and is programmed to use this, your code will instead result in erasing 0x4400.
    Data access to memory locations above 64k also requires different code in the ISRs and the function frames, as any register may hold a 20 bit value which needs to be saved to stack using different push/pop instructions than normally. This increases code size and slows down execution. So this is usually not active (if supported at all).

    That is the reason why flash functions for >64k are usually written in assembly language (where you can use the proper 20 bit instructions without need to carry this additional weight for the whole program unnecessarily)

    p.s: during any flash operation, you need to clear GIE (it is in your case, as it is clear by default, but if you later extend your program...), else any interrupt that happens during flash write will crash the system and invalidate the write result.

**Attention** This is a public forum