• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 443 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.

MSPM0G3107: Blank check on uninitialized memory not working

Andreea Barbu
Prodigy 25 points
Part Number: MSPM0G3107


Tool/software:

Hello,

I am currently working on implementing a service layer for handling the read/write request to NVM and I using the FLS driver module provided in the MCAL.

While testing, I noticed that if I want to perform a blank check operation before initializing the memory(I want to check if the memory was programmed before or not), the job result is always set to FLS_E_BLANK_CHECK_FAILED..

After performing an erase operation on the sector, the function works and returns a valid output.

I was wondering what is the difference between the uninitialized memory and the erased memory? And why it does not work to perform a blank check on the uninitialized memory. They both appear to be 0xFF.

 

Thank you!

 Best regards,

Andreea

  • 0
    TI__Mastermind 19012 points

    Hi Andreaa,
    Can I confirm that when you say blank check, you refer to blank verify?
    Best Regards,
    Diego Abad

  • 0 in reply to Diego Abad Sajamin
    Prodigy 25 points

    Hello Diego,

    Yes, that is correct. I meant blank verify command.

    Best regards, 

    Andreea

  • +1 in reply to Andreea Barbu
    TI__Mastermind 19012 points

    Hi Andreaa,

    The check doesn't work because the check evaluates if the flash has been successfully erased and not yet programmed away from that non-erased state. You can find more information in the MSPM0G3107 TRM Chapter 6 Section 6.3.6 BLANKVERIFY Command.


    Best Regards,
    Diego Abad

  • 0 in reply to Diego Abad Sajamin
    Prodigy 25 points

    Hello Diego,

    Thank you for your response.

    I have one more question related to this topic.

    I will start with a little background for this. The concept I wanted to implement for this service layer involved the usage of some sectors for writing data and only one sector would contain valid data at a time (validate a sector -> write a specific header at a location in the sector).

    The problem would be after a reset to determine which is the valid sector. And for that initially I was thinking to first check if all the sectors were empty(to perform a blank verify on them) and afterwards continue the processing with the ones which have some data written. But now this will no longer be in scope since the blank verify only works for erased memory(the problem appears at the first power on, when the memory is neither programmed nor erased).

    So the next idea would be to read/compare(read-verify) the header from memory with the pattern I chose. And here I have some questions because I read in the reference manual, at chapter 6.3.6 BLANKVERIFY Command that "After erase, a flash word is not in a deterministic state until it is programmed using the PROGRAM command.
    This means that application software can not expect that erased bits will read back as '1's' after an erase.
    A memory location must be successfully programmed using the PROGRAM command before a read of that
    memory location can be considered deterministic and used by application software."

    Does that mean that even if I erased a sector, at the location of the header there might be a change of having the same pattern that was written before the erase? Would it be ok to use the read/compare(read-verify) operations on the erased memory?

    So for example if I had written 8 bytes of 0x22 in NVM, after an erase, if I read or perform a read-verify with 0x22 at that location, would they return a valid response?

    Thank you!

    Best regards,

    Andreea

  • +1 in reply to Andreea Barbu
    TI__Mastermind 19012 points

    Hi Andreea,
    After consulting with our internal team, you can expect a value of 0xFF every time you erase a location in flash. You should be able to use readverify and check for that value in the erase locations. As a reminder, the blankverify command will still check for erased flash rather than a value.
    Best Regards,
    Diego Abad

  • 0 in reply to Diego Abad Sajamin
    Prodigy 25 points

    Hello Diego,

    That's great. Thank you for your support!

    Best regards,

    Andreea