I am afraid that I've broken the tools, again.
This time it is with the "PLC Data EEPROM Manager" and 32-bit access to EEPROM.
Test hardware FMD1616-10 with FRAM-RTC installed, firmware r82A.
The program does not handle 32-bit integers very well. There are mistakes in the code that are doing math as if the data is a 16-bit signed value and then sign extends it, incorrectly, to a 32-bit signed.
&H00008000 becomes &HFFFF8000 !
This is the PLC code:
' Quick test of EEP32 behaviors
'
' write a walking 1 pattern in memory
'
C = 1
for i = 1 to 32
DM32 = C : C = C + C
next
a = 1 ' just a target for a break point
' copy first 32 DM32[] to eep32
for i = 1 to 32
save_eep32 DM32, i
next
a = 2 ' just a target for a break point
' read eep32 back
'
for i = 1 to 32
DM32[i+40] = load_eep32(i)
next
a = 3 ' just a target for a break point
[/font][/color]
The test code generates a walking 1 pattern in DM32[] writes this to EEPROM32, then reads it back without problem.
The EEPROM/FRAM manager can't do the same.
Look at location #16 in the jpeg for the problem with &H00008000 the EEPROM manger things that this location is &HFFFF8000!
The ".csv" file that can be produced contains the same error.
If the ".csv" file is edited and corrected then the value &H00008000 is loaded into EEPROM correctly without the 16/32 bit sign extension mistake.
The EEPROM manager has other problems with "reading" 32 bit values. An example is if the value &H001BF5A (114522 decimal) is stored in EEPROM, the EEPROM manager will display it as &H0000BFA5. The EEPROM manager has lost the most significant 16 bits of the integer. This is another 16/32 bit boundary issue.
I have a question. If I have a file in .CSV format, how does the EEPROM/FRAM manager "know" if I want it to load the integer data as 16 vs 32 bit? There doesn't seem to be anything in the .CSV file that specifies the data size/addressing scheme.
Gary D
