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.

MSP430 Write to Flash

Hi,

I have already found a lot of resources about writing and reading to flash. There is one thing that is kind of unclear though. The write to flash function is erasing the segment where you want to to store your value. Is this necessary every time? It seems unpractical, since you would have to re-store the old values that were previously written in that specific segment. Thank you.

Alin

  • Alin Dosa said:

    I have already found a lot of resources about writing and reading to flash. There is one thing that is kind of unclear though. The write to flash function is erasing the segment where you want to to store your value. Is this necessary every time? 

    Alin,

    Yes, it is necessary that the flash segment, in which the data has to be modified, needs to be erased before re-programming it with modified data. This is because of the technology used in making flash memory.

    Alin Dosa said:

    It seems unpractical, since you would have to re-store the old values that were previously written in that specific segment. Thank you.

    When few bytes of the Flash segment needs to changed, the application has to first copy the current data (present in that flash segment) into some location, change the particular bytes that you want to modify, erase the flash segment and rewrite  (re-program) the whole segment data into the flash.

    Here is one more Application Report on the MSP430 flash memory that you can refer which talks about different usecases which can make use of the flash memory. It contains many other useful infomation.

    http://focus.ti.com/lit/an/slaa334a/slaa334a.pdf

     

    Regards,

    Nag

    --------------------------------------------------------------------------------------------------------------
      Please click the Verify Answer button on this post if your question is answered
    --------------------------------------------------------------------------------------------------------------

  • Thanks Nag. Interesting document. So bottom line is: do not write data to a memory address that has already stored a variable without first erasing the memory... 

    Since I am a curious guy, could you tell me what would happen if I would try it anyway?  Thanks.

  • Alin, Thanks for your acknowledgement.

    Here's what I can think of.

    If the flash write happens with out erasing it, the flash programming may fail and the new data will not be written into the flash segment.

    Regards,

    Nag

  • Alin Dosa said:
    Since I am a curious guy, could you tell me what would happen if I would try it anyway?

    All newly added '0' bits will be written, all previous '0' bits remain zero even if you write a '1'.

    Actually, you can only write '0' to flash cells and erase the whole segment to 'all 1'

    There is, however, a certain limit on the total accumulated programming time of a single segment. If it is exceeded, there is a risk that even 'unprogrammed' cells turn from 1 to 0. This time is reset when erasing the segment.

    So it's possible to incrementally write a segment byte by byte (or word by word) until it's full. It's even possible to fill it bit by bit, yet the number of programming cycles is then limited. On old MSPs, the maximum time didn't allow to write a complete flash segment bytewise. The newer MSPs have flash that allows bytewise programming and another overwriting run on a segment.

    So if oyu have , say, 16 bytes data, you can write it to the first 16 bytes of a segment, then copy it to the second 16 bytes (with modifications) and overwrite the first 16 bytes with 0 (or just clear a single flag in these first set). And so on until the segment is filled. No need to erase or buffer the data in RAM in-between.

    Personally, I use two 128byte segments for storing my configs. I write to oen segment, then mark the other one invalid, then erase it. To ensure that I have always a working config stored, in case power fails during the flashing cycle. And I don't need to buffer the 128 bytes while erasing the segment.

  • Thanks Jens-Michael. Your wisdom is always appreciated.

  • Can you guys tell me where to find an example code showing how to write and erase a flash segment using the MCU? I need to store some configuration parameters in the flash memory so that they can be reloaded after the microcontroller is power cycled.

    Thanks,

    Daniel

  • 3073.msp430x54x_flashwrite_04.zip

     

    Kindly find one reference example code for flash write in MSP430

  • Thanks but how to read the data back ..in your sample code I do not see

  • Tam Nguyen1 said:
    Thanks but how to read the data back

    Data written to flash is accessible by just accessing the byte in the normal address range (e.g. by  apointer). Like other flash-stored constants or like variables in ram.
    It's only the writing that requires a special procedure.

  • Hello,

    I notice that in many examples of writing to flash, the flash writing function is copied to and then executed from RAM.  Why is this so?  My initial guess is that one can unintentionally erase code memory otherwise.

    I've seen other cases where the following would be done:

    1. Designate a block of flash for code/functions
    2. Designate a different block of flash for data (i.e. saving variable values) -- essentially the block that the code will write to / read from
    If one is careful in allocating the blocks, then is it necessary to execute the flash write code from RAM?  Is there another advantage I am missing?  Or perhaps my train of thought is incorrect?
    Sincerely,
    Mehdi
  • Mehdi Rahman said:
    I notice that in many examples of writing to flash, the flash writing function is copied to and then executed from RAM.  Why is this so?

    While flash memory is being erased or written to, the whole flash memory isn't available. The CPU cannot read its next instructions from it. During a arite activity, reading from flash always returns the value 0x3fff. THis is the JMP $ instruction. So a CPu that starts a write operation from within flash will 'jump in place' until the operations is done. For this reason, interrupts must be disabled. Else the CPU would read 0x3fff as the address of the ISR.
    Now you can do a flash write from withing flash. The CPU will effectively stop while the write is ongoing and continue once the flash controller is done. But when doing so, you can only use the single-write mode. Writing one word after another. Each time, the flash controller must start generating programming voltage, apply it to the cells, write, disable programming voltage, then wait for the next write command.
    When the code runs from ram, it can use block write mode. Here the programming voltage on/off is only performed once for multiple writes. Since the CPU can read its instructions from RAM while the flash is busy, it can poll the current write status form the controller and seamlessly write a whole block of data. This is about twice as fast. But requires shuttin goff interrupts for the whole write session while when executing from flash, one could enable interrupts between two writes, so any pending interrupt is served before proceeding.
    Both has advantages and disadvantages.

**Attention** This is a public forum