MSP430F5529: Erasing bank2 using code that runs from bank0

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 ?

Thanks,

Zvika.

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 ?

Thanks.

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.