I am having an issue using the G30 Configuration Sector.
var WriteSuccess = false;
WriteSuccess = Configuration.WriteEntry("FACTORY_TEST_2", new byte[1] { 0xFF });
if (WriteSuccess)
{
byte[] read = null;
read = Configuration.ReadEntry("FACTORY_TEST_2");
if (read != null && read[0] == 0xFF)
{
// Will only Execute the first time this runs, read[0] will be 0x00 after that
}
}
}
I keep changing the name of the Entry slightly and each time I change it, this works exactly one time. Is each name only meant to be written to once?
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?
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
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
@ 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.
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.
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.
@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?