EEProm Data appears to be stored incorrectly.

[JimB]

I am attempting to generate a routine that will load constanst into EEProm for use in setting up a D/A. When I run the code in a loop, I find that the first reads from the EEProm are always FF. After the loop runs again the values are read correctly. If I recompile and run the same code again, I again get FF for the first pass at reading the EEProm. All the printf statements are for me to see what is happening.
Also when a constant is setup as a #define......... how is the declaration for type made. I have not found any examples of this.

[Ttelmah]

0xFF, is exactly what you should get on the first pass. The EEPROM is _blank_ after programming, unless you deliberately tell the compiler to put values there, and for the EEPROM, 'blank', corresponds to all bits being '1'.
Now, when you are testing the loop, is this in a real chip, or an emulator?. Which compiler version?. You are compiling for ICD. Is this what you are using?.
As a general comment, though it is legitimate 'C', to put the variable declarations inside the function loop, I'd stick to putting them at the start of main. CCS, can have some oddities with such declarations, and nothing is gained from putting them inside the loop (unlike the situation for a processor with a data 'stack').
The #define is fine. The data is automatically a 'long', since it is more than 8bits in size. If you want to force a long declaration, simply append an 'L'.
As another general comment, always 'bracket' numeric declarations. So:
#define ref12 (0xD000L)
This avoids potential problems latter, where if you use such a definition inside a statement that results in arithmetic/logic expressions being carried ot, the 'unbracketed' form, can result in the expression not evaluating as you expect...

What you show, should work, but it is slightly confusing, storing the value MSB first (at the end of the day, why not have byte 0 at index 0, and make it less likely that you will get confused latter from the bytes being swapped...).

Best Wishes

[JimB]

I am running this with a development board, so the real hardware is being used. I am using compiler version 3.232. Shouldn't the "write_eeprom" put data into the EEProm that is preserved after turning off the power or for that fact for any events other than another write_eerpom command? I started viewing the EE information in the debugger window and noted that it is stored after running a few loops through and then stopping. However, just after re-compiling, but before running the code again, I see that the EEPRom has been reset (?) to FF again. It appears to me that the EEProm gets reset every time a compilation occurs. If this is true that means for each new compilation, there always must be code to reload the EEProm, hence the read and check to insure that the correct values are in place.

I assume that when you say "tell the compiler to put values there" you are referring to the write_eeprom command? If not, I am missing something more fundamental.

The order of the address's used is simply because I removed several other stored constants to be brief here. I am still very much a student.

[PCM programmer]

[Mark]

There is also an option to NOT program the eeprom which would prevent the previous data from being erased.

[JimB]

This is mainly an excercise for the student. It gives me some direct assurance that what I am doing (storing data in the EEProm) is functioning correctly. In the final code the EEProm values stored will not be checked each time the program is run. In fact they will be changed whenever a calibration routine is run. They will be called for use later. If the vaues in this example were to remain in the EEProm as I had expected, then there would be no writing to it. This is to check to see that what was put there previousley is still there, but if incorrect, the values are re-written again.

[JimB]

I thought I would post this little tidbit since I did not ask the question directly. That was "does the compiler reset the EEProm during compile time". The short answer is yes....at least in my case.
Now I find that there is a setting, in the ICD, that disables this reset feature. However, in my case, I found that the compiler must be running. Then go to the ICD in the Windows start menu, not the selection under the Tools menu. When the ICD window opens, click on the Advance button. Now you will see three choices for handling the EEProm memory. When I selected to do nothing, all was as I desired. Now when data is read to the EEProm, it remains there even after I recompile.

[Mark]

Yeah, that is what my last post eluded to