Hello,
Is it possible to write the same byte in flash multiple times? I understand that you can't turn a 0 to a 1 without an erase. But is it possible to go from 0101 1010 to 0000 0000 without erasure?
With some microcontrollers this is possible. But in the datasheet it doesn't say if it/isn't possible.
I have done some tests. And sometimes it works, and other times it doesn't. So I couldn't find a definitive answer.
Thanks in advance,
Lode
I think this should work. I think they rely on that in their SmartEEPROM implementation. The datasheet even says "The SmartEEPROM concept relies on the following NVM physical property: It is always possible to write a '0' in a NVM word, even if this word has been previously programmed". You say that sometimes this doesn't work? Can you elaborate?
Smarteeprom is not accessed in the same way as flash, even though it's the same thing. Flash is on AHB0/1, while smarteeprom is on AHB2. You'll also notice that the sectors allocated to smarteeprom are not readable or writable from NVM. I found this out the hard way.
SmartEEPROM allocated space in the main address space is not accessible from AHB0/1. Any AHB access throws a Hardfault exception. Any command issued with ADDR pointing in the SmartEEPPROM space is discarded, INTFLAG.DONE and INTFLAG.ADDRE are set in this case.
– Address: PARAM.NVMP*512-2*SEESTAT.SBLK*8192
– Size: 2*SEESTAT.SBLK*8192
– Property: Not readable, not writable
It is possible that smarteeprom takes longer to erase single bits, whereas normal AHB0/1 access does not. It sure seems that way in use, smarteeprom is not very fast and exponentially worse the larger it gets.
I've got nothing else, sorry!
" Smarteeprom is not accessed in the same way as flash" - well, when it is enabled, yes. But the chunk of flash that is used to implement SmartEEPROM has to be otherwise identical to the rest of the flash. And is definitely accessible as the rest of the flash when SmartEEPROM is disabled.
I am well aware, yet believe it's more important how the memory is accessed rather than what it is. For similar reasons you've got minimal wait states that change depending on conditions. How are you to tell that a designer didn't forego the ability to quickly erase single bits without harming more important bits, like access speeds or durability or even cost effectiveness? Do you know if smarteeprom holds it's data in a buffer and continually writes zeros till they "stick"?
The datasheet specifically says a page erase must happen before it can be written, whatever else the smarteeprom section of the NVM controller is doing to exempt that rule is irrelevant. On top of that, actual testing shows it can't be done.
So I guess, no, not unless you want to deal with really slow "eeprom." And since you can't see the raw data in any way, you won't even know if it's actually erasing bits or moving them all to a new page.
"actual testing shows it can't be done" - what testing?
"And since you can't see the raw data in any way, you won't even know if it's actually erasing bits or moving them all to a new page" - no sure what you mean. You can enable SmartEEPROM, write something into it, disable SmartEEPROM, look at the data in that chunk of flash that was mapped to SmartEEPROM, etc.
The testing the original poster did.
And you are right, there's probably a way to see the data. It's been a while since I've been through that section, but I think you can allocate everything manually and probably watch it move, or ask to move. I don't know, it works with auto allocation...
