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.
@ 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.
@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.
@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 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.