• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 385 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

LP-MSPM0G3519: Program for only 4-byte with ECC in DATA Flash

Eswaran Ganesan
Prodigy 51 points
Part Number: LP-MSPM0G3519


Tool/software:

Hi Team,

I am trying to write only 4-byte of data at a time in the DATA flash 0x41D00000 with ECC.

The first write is successful but when the next 4-byte is being tried to be written at 0x41D00004 the value is overwritten at 0x41D00000.

Is this actually to achieve only 4-byte writing at a time with command being passed at CMDBYTEN as 0x0000010F?

Please help me understand where i am going wrong.

Thanks.

Regards,

Eswar 

  • 0
    Guru 42215 points

    The flash starts out as all 0xFF's after erasure, and after than you can only change 1's to 0's, you cannot change 0's to 1's. You have to erase back to all 0xFF first.

    Is that what you are seeing?

  • 0 in reply to Keith Barkley
    Prodigy 51 points

    Thanks for your reply.

    I am trying to write in an erased memory which is 0xFF as first then only write operation is triggered.

    First i am trying to write 0xABCDEF00 at address 0x41D00000 - successfully written and reflected in memory.

    Then 0x12345678 at address 0x41D00004; Here the end output is the value 0x0204 4600 which is AND of the both the values at the 0x41D00000.

    So, yes the values are changes from 1's to 0's.

    Is there any reason why the data to be written at 0x41D00004 is overlapped at 0x41D00000?

  • 0 in reply to Eswaran Ganesan
    TI__Genius 16070 points

    Hi Eswaran, 

    Are you using our driverlib APIs to write the data to memory? Or are you manually writing to the registers? 

    You can write to the flash 32 bits at a time without overlapping the data, this sounds like an implementation error to me.

    CMDBYTEN looks like it should just be 0x0000000F when you want to write 32 bits for one piece. I encourage you to look at the source code in dl_flashctl.c and dl_flashctl.h for examples on how to issue flash controller commands like this.

  • 0 in reply to Dylan OBrien
    Prodigy 51 points

    Hi Dylan,

    Thanks for your reply.

    I am using the existing driverlib APIs for writing, by using this function DL_FlashCTL_programMemory32 of dl_flashctl.c file.

    And after every write I am incrementing the address by +4 to write it in the next address using the same function mentioned above. 

    But while doing that the overlap is observed.

    Using alternate method: 

    While looking at the datasheet it was mentioned only 8bytes of write is possible, even if a user wants to write 2bytes or 4bytes at a time

    The CMDBYTEN and CMDATA0 along with CMDATA1 should be used like the image below.

    While having this a reference I was able to write 4bytes at a time but had to do it like below snip. Now the write was successful but while reading the ECC is throwing issues and gets hanged at default handler.

    The difference between the two functions is that address alignment with 8bytes, below function flow will be called. With this write is successful but the read is still an issue.

    Please provide me your feedback on this.

  • 0 in reply to Eswaran Ganesan
    TI__Genius 16070 points

    Eswaran,

    Reading back over our docs, it looks to me like you need to pass the flash controller an 8 byte aligned address, and then use CMDBYTEN to mask which bytes you'd like to write to. 

    The first screenshot you've included from our TRM is correct. I cannot see your definitions for all of the new test functions, but if you are following the procedure listed above and can see the memory changing as intended, then I think you are good to go. I'll note that we do need to check the flashctl source code considering that it appears the provided APIs can only write the lower 32, 16, 8 bits of a word.

    I think you are seeing issues with ECC because you are writing to a flash word without erasing first. Some bit in the ECC was likely cleared in the first write, and afterward in the second write it needs to be set. Since a write can only clear bits, the bit stays cleared and then the word as a whole fails the ECC check. 

    The easiest way around this is to either erase before writing, or to write only 64 bits at a time. You could maintain a buffer in SRAM to save the first 32 bits, then the second 32 bits, before writing, to avoid ECC errors as well.