Block write operation in MSP430F248

Before you (over)write a flash location, you need to erase it. During this process, teh whole flash block is erased. In case of code memory, this is 512 bytes with 512 bytes alignment. I fhtis area contains anything you want to keep (because the block you're copying is smaller or not 512 byte saligned), then you need to copy the old content to ram first and write it back after erasing the destination area, together with the new content.

The plain copy process can be performed with a data source form flash as well as ram. No need to move teh data to be copied to ram first (as long as source and destination are in different 512 byte segments).

During the write process, the flash is unavailable for read. THis includes the code. Hwoever, all read attempts (include the code fetch from teh CPU) results in 0x3fff returned, which is (incidentally) the code for 'jump on place'. So during the write operation, the cpu loops and after the last byte/wort was successfully written, teh flash is available for reading the source data for the next byte/word write.

However, if you use a write function in ram, you can use the block write mode, which allows much faster writing. In this mode, the flash is not available for reading until the whole write operation has been finished.

If the MSP430 you use has more than one bank of FLASH, and you are copying from one bank to a different bank, then you do not need to go through RAM.

But most MSP430s have only one bank of FLASH. When you try to do a Erase or Write (block or otherwise) to any part of that bank of FLASH, you simply cannot read or fetch from that entire bank (the FLASH controller will fake is with a 0x3FFF). Thus you must copy the source block to somewhere else (e.g., in RAM) before you start that block write of FLASH. Your code during the block write must also reside somewhere other than that band of FLASH (e.g., in RAM) for the same reason.

old_cow_yellow said:

Thus you must copy the source block to somewhere else (e.g., in RAM) before you start that block write of FLASH. Your code during the block write must also reside somewhere other than that band of FLASH (e.g., in RAM) for the same reason.

No. If you don't use block write mdoe, you can perfectly well execute code from the very same flash bank, and also fetch data from it. During the actual writ eprocess, the controlle rindeed return 0x3fff (a 'jump on place' instruction), however, this instruction doesn't try to fetch and data from flash :) And once the write of teh current word is finished, flash returns code as well as data fetches properly again. Each single byte/word writ eoperation is started and ended individually, so between the operations, flash is normally accessible (e.g. for reading the next word to copy). The only caution that must be takes is that no accidetnally write operations are done to any point of flash, as it is unprotected until you finis the whole operation (well there should non, as writes to flash shouldn't ever happen except if explicitely wanted) and interrupts are blocked globally during the write. (however, it is allowed, set GIE and clear it immediately right after the write and before reading the data that is written next. Then ISRs have a chance to be executed between two word write operations. However, flash is unprotected against accidental writes in this case. No probelm for properly written code, but may cause havoc if there are soem bugs that normally do not do any harm.

Yes. The original poster wants to use block write mode.

 

old_cow_yellow said:

The original poster wants to use block write mode.

No. Blockwise copying doe snot necessarily mean using block writ emode for flash. Only that a block of data is copied and not individual values now and then.
YOu can very well copy a block of data word by word without block write mdoe. (and it is easier and allows to enable ISRs between individual writes, which might be essential for some applicaitons.)