Not done this, But maybe Configuration.WriteEnrty only returns true if the entry is new and written and false if its already set?
Maybe change the conditional statement to test for a successful Read after Write instead?
if (Configuration.ReadEntry(“FACTORY_TEST_2”)!=null)
I am already running this test and testing the actual value in my example. My problem is that WriteEntry and ReadEntry both return true, however the value returned from ReadEntry does not reflect what was supposed to have been successfully written. And it is not Null.
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?
I think I actually need to clarify here…
In the first iteration the Entry does not exist until it is written as 0xFF. Subsequent reads will indeed reflect 0xFF has been written.
Then on a second iteration the same entry may be written 0x00. It is from this point on that all reads will return 0x00 no matter what I write.
yep sure I see, but thought just worth a try to refactor it so we tested for a successful read and that also would test that the write was successful (at least once). Just to see results, and see if different, because it does sound like something isnt working as you’d expect it too. Worth a try
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.