Occasionally a ReadEntry returns false. When this happens it also says Failed to Allocate 16704 bytes. This is close to the size of the Configuration Sector. Do I need all that memory to use it?? Could that be my issue even when it isn’t printed?
Guess its loading the whole configuration sector and iterating through it to find the key match?, as its not some sort of hash table look up
What version of firmware etc?
hmm does sound suspect, have you search the GHI formus?
As Ive found a few similar posts about similar issues.
Does John’s Test code in this thread work (1/2 way down)
Also this might be a ‘gottcha’
@NicholasR - You can call WriteEntry with the same name and different value multiple times without needing to call erase. It handles different lengths. The config in NETMF works by appending new entries to the list. It does not erase old entries. So when you write a new entry with the same name and same sized value, you are still using up more space. The existing space is not reclaimed. WriteEntry should return false when there is not enough space left. It is possible there is a bug in that functionality. If it happens again, read back the entire config region and send it to us. We can take a look at it.
@Darren SFI - NETMF has some internal compaction mechanisms that are not exposed that run automatically. Once the region is completely full though there is nothing more to be done.
John’s code experienced the same issues. I will not be walking down this path. If it is bugged then it’s a dead end, and if it is not bugged then it doesn’t work how I need it to.
Thank you for looking into this with me. 
As a workaround, a colleague of mine said he found the same issues and would instead
use Read()
modify values that he knew were okay to modify
use Write()
But I have no interest in making sure 16kB are available at any moment for this purpose. Not to mention Write() is meant to be used with unmodified arrays taken from Read().
Interesting, What version of firmware do you have?
Tried an older version? As seems there has been some history around this issue… So maybe got fixed and re-broken
I have version 4.3, I have never used another version
Interesting comments from John_Brochue
@ Tulmandil - I believe this is a result of using Read/Write improperly. The documentation for Write that you can view in Visual Studio states: “Writes the given buffer to the configuration sector. The data written must come unmodified from a previous call to Read.” Write and Read are only meant for backup purposes – they do not operate on a general purpose storage buffer. Configuration stores more data than just the buffer you provide it. You want to use WriteEntry and ReadEntry which allow you to write arbitrary data.
You just happened to write some bytes to configuration that corrupt the device. The only way to be sure that is the issue and to fix it, if it is, is to send the device back to us for repair. You can contact support@ ghi and reference this thread to proceed with that. In a future SDK we will add more safe guards to prevent corrupting the device when using Configuration improperly and emphasize the constraints of Read/Write more.
does reloading the firmware have any effect?.
Yes, this is where I gathered that the workaround I mentioned before may not be acceptable. To be clear, I never called either function: Read or Write.
I have a new solution without using the Configuration Sector. Also, my dev device is now enclosed (I believe I will need access to LDR pins to reflash Lemur + Config.ghi). Next time I access an open device, and time permitting, I will explore this question.
I am no longer interested in this, but if others are then I will try to find the time to gather more detail.
@Mike I am still stuck on this. I filled up my EEPROM and came back to this Flash sector because you guys said it was re-writable in this post:
So maybe I didn’t conjure up in my head that someone from GHI specifically warned me this could only be written to once per FW flash.
Exactly where are stuck?
Basically, you should use read and write entry. The space is not reclaimed. Write too much data and/or rewrite an entry too many time, you will run out of space.
Should only use for configuration data. Write once read many.
@Mike Part of what I am not understanding is how it writes to the same entry multiple times without erasing data…if you read back that entry won’t it give you the data from the first as well as the second write? I want to write more than once…EEPROM tetris may be what I have to do…such a shame there’s so much “unusable,” space, per say.
Justin said he is able to easily re-write 100k times to this sector with his own version of NETMF.
Configuration should only be used with rare writes. Like network settings that changes almost never. I personally recommend adding an eeprom.
@Gus_Issa I have an EEPROM I am just on the last page of it…would be easier to be able to bust out this sizable flash space BUTTTTTTT when is anything ever easy?
So, when I’m rolling out my machines and I want to have a serial number embedded, I should use them or should I use an SPI flash?
The best for serial is a one time write device or an eeprom. You will lose config if you erase your device.
So, what should someone use config? Only configuration that you are okay losing and you update rarely.
what does this mean? It would be really beneficial if you articulated your problem statements more fully so us logical thinkers can assist.
@Brett the 252 kbit EEPROM I have prefers 64 kbit page writes…if you do less than a page, any address after what you write that is on the same page gets erased. I just have to write way more data to EEPROM than I want to since I have to do full the page instead of just writing 2-4 bytes to flash (more often than Gus would like but the device wouldn’t be getting erased for years so I don’t see what the problem is).
so you do or don’t have space for the data in your eeprom? I still don’t get why the page size matters - read in the page, update the necessary values, write… heck you could even keep the whole page in memory if you’re not doing your own wear levelling. Or if you’re just storing a small amount, just write the whole page even though you don’t have more than a handful of bytes…
I have posted this code before but it seems to be a good solution to this issue.
I got my EEPROM optimized it just took a significant amount of rearranging which bits come first on the last page and also writing full pages at once when only a bit was needed. I just wanted it to be easy lol and use Configuration space.