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.

MSPM0L1306-Q1: Writing to the same sector in 32 bit, 16 bit and 8 bit chunks

Part Number: MSPM0L1306-Q1
Other Parts Discussed in Thread: MSPM0L1306

Hello.

So the flash program size on this MCU is a flash word (64bits). I'm trying to understand how write works when trying to write smaller chunks in the same sector. I've slightly modified the 'flashctl_multiple_size_write' program such that it writes a byte at offset 0, 2 bytes at offset 1, 4 bytes at offset 3 and finally 8 bytes at offset 7 (thereby straddling the word boundary). So this is how it should look in principle.

         11       22      22       33       33      33      33       44       44      44      44      44       44      44       44        
     |--------|--------|--------|--------|--------|--------|--------|--------|--------|--------|--------|--------|--------|--------|--------|

0x1000                                                              0x1007                                                                          0x100F                                                      


I now step through the program and see how the memory looks

Writing 11 at 0x1000:



Writing 2222 at 0x1001:



Writing 33333333 at 0x1003:



Writing  4444444444444444 at 0x1007:


Looking at the screen shots above, it looks like executing a 'program memory from RAM' inherently results in the sector being partially wiped. Sometimes existing bits are all zeroed (writing 0x2222 at 0x1001 and writing 0x4444444444444444 at 0x1007) out while some other times, they remain intact (writing 0x33333333 at 0x1003). 

Can someone give me a rundown on what the actual rules are so I can be sure of what I can expect?

  • I don't quite understand what you are asking, but remember flash is erased to 0xFF and only zeros can be programmed until the next erasure. So, if your write sets 1's to zero, you are good, but if it tries to set a 0 to a 1 it will not succeed.

  • Hi Aj,

    I agree with Keith's comments. 0x1 is 0001, 0x2 is 0010, 0x3 is 0011, 0x4 is 0100. So from figure 1 to figure 2, 0x11 will be modified to 0x00. 

    Thanks,

    Yuhao

  • If that is the case, then what good are the driverlib APIs that write 8/16/32 bits into a flash word? This surely requires a read modify write to ensure it is written the way you expect it to be.

    Writing anything less than a flash word (64 bits) is not guaranteed to reflect what you write it seems. Can you comment on this?

  • Please note that FLASH operations will perform address alignment. 

    And we do not recommend repeated writing of flash words that have already been written. 

    But if you want to write flash words repeatedly anyway, you can try writing FF in the already written part.

    for example ,write 0x11 at 0x1000, then write 0x22FF at 0x1000 and so on...

  • Wouldn't that wipe out the existing data then? I don't quite understand what you say.

    By the way, I do know writing to the same flash word repeatedly may wear out the NVM flash chip faster. With that out of the way, let me rephrase my question:

    Assume that my flash word contains 0xFFFFFFFFFFFFFF11. Is there a way for me to replace the red FFFF with 2222 without doing a read modify write? Since I was not able to do write it directly at that location using the driverlib APIs.

    Keen to hear your response.

  • As Yuhao said:

    write 0xFFFFFFFFFF2222FF

    (I hope I got the number of F's right!) This will write the 2222 where you want to put it, and protect the data at the LSB's.

  • Do you mean to say that if I write 0xFFFFFFFFFF2222FF to a word that contains 0xFFFFFFFFFFFFFF11, I will have 0xFFFFFFFFFF222211?

    Does this also imply that I always must use 'DL_FlashCTL_programMemoryFromRAM64'  aka a 64bit write (regardless of the actual number of bytes that one intends to write) and mask all other bytes that are to be kept untouched with FF?

  • I tried that before and it works. But please note it is only for device without ECC.(like MSPM0L1306)