I'm using a struct (~272 byte) to manage my data. Within the struct there are two two-dimentional float arrays each 128 Byte.
When I read out the struct, some data (always [3][4]) of one array is corrupt - showing "-inf".
When I access the dedicated corrupt entry directly the value is read out correctly. (reading single bytes in the suspected areas did als not show any wrong data ...
Are there limitations when using arrays ?
Well, this message says the content is invalid representing a negative inifite value. It sounds to me like a corrupted data and/or bad storage, or a defective EEPROM, I don't know.
What happens if you comment out the entire "for()"?
Inf or -Inf requires the max exponent, and the significand must be zero. Otherwise it is NaN (which seems like a waste of bits. Looked it up: turns out there are both quiet and signaling NaNs, and they can contain a payload in the significand bits.)
Due to the biased exponent, that's just one or two bits off
How are you showing the value? Serial.print does not print the negative sign unless it's a valid number
size_t Print::printFloat(double number, int digits)
{
if (digits < 0)
digits = 2;
size_t n = 0;
if (isnan(number)) return print("nan");
if (isinf(number)) return print("inf");
if (number > 4294967040.0) return print ("ovf"); // constant determined empirically
if (number <-4294967040.0) return print ("ovf"); // constant determined empirically
// Handle negative numbers
if (number < 0.0)
{
n += print('-');
number = -number;
}
Also the offset of korr_A[3][4] is 252, which means it ends just before offset 256. (Might be more of a lead if it started there.) What does setMemoryType do?
I think you could try and check the EEPROM content first byte per byte, to make sure you correctly stored the arrays or not (indicating another kind of problem). Write a small memory dump to serial and see if the value 1.0 is correctly stored (float32 should be 0x7F 0x00 0x00 0x00).
Something like this one, it's a code I wrote for another project where I had a "cfg" struct (so you need to adapt it to read from your EEPROM):
for (int a = 0; a < sizeof(cfg); ++a) {
byte b = EEPROM.read(a);
if (b < 16) Serial.print("0");
Serial.print(b, HEX);
Serial.print(" ");
}
Serial.println();
So 255 at offset 255. Interesting. And as I mentioned, that does change it from 1.0 to -Inf, since the most significant byte (with the sign bit) is last.
How about larger payloads? 512, 1024, etc. And in the other direction, what if you read 128 or 64 at a time? (Depending on the available functions, may have to read it into a generic buffer and then memcpy it into the right place.) A byte at a time is of course simplest, and maybe it's not too slow.
You have to decide whether you want to try and fix the problem, find a clean solution, or just do a workaround.
The 1.0 value (I must correct my previous statement) as float32 (IEE-754) is the 4-bytes sequence:
3f 80 00 00
After the first 12 bytes, I see float values 1.0 are stored as "00 00 80 3F" so it looks ok to me because it's a Big Endian encoding. Are you sure you (or the library..) are using the same when writing and reading?
Dealing with the standard EEPROM library, I can write and read back a structure with a single instruction using EEPROM.put(0, cfg); and EEPROM.get(0, cfg);. I wonder why you can't do the same with Sparkfun EEPROM functions, loading the whole struct in memory with myMem.get(LOCATION_SETTINGS, calstruct); and access its values, instead of reading single floats with a for() statement?
