View previous topic :: View next topic |
Author |
Message |
aaea
Joined: 11 Jan 2010 Posts: 8
|
EEPROM Problems |
Posted: Mon Jan 11, 2010 8:17 am |
|
|
Hi
I am using the PIC18LF2550 chip.
I have written the following to the EEPROM:
Code: |
//***Initialize "0 0 0 0 0 0 0 0" to EEPROM
t = 0;
for(i=0;i<8;i++){
write_program_eeprom(10+i,t);
}
|
I then comment this block out, and read from the EEPROM as follows:
Code: |
for(i=0;i<8;i++){
t = read_PROGRAM_eeprom(10+i);
ch = 48+t;
f[i] = ch;
}
printf(f);
|
But now I get junk in f. If both blocks of code are present then it works fine. If only the latter, junk.
Can someone please tell me how to get theEEPROM to retain the previous number set?
Thank you in advance
a. |
|
![](templates/subSilver/images/spacer.gif) |
Wayne_
Joined: 10 Oct 2007 Posts: 681
|
|
Posted: Mon Jan 11, 2010 9:20 am |
|
|
As in all these posts :-
t is not defined
i is not defined
ch is not defined and f is not defined
Yes I can assume t, i and ch are int8 and f is
int f[?];
But as you can see I have no idea what size f is. This IS important as a string should be null terminated. You do NOT null terminate your string but assume the compiler zero's the string for you. If it has a size of [7] or less you can't null terminate it as you havn't left enough space for the termination char.
I expect the problem is though that when you program it with the code for just reading the eeprom you have not told the programmer to NOT erase the EEPROM and not RE-PROGRAM it. |
|
![](templates/subSilver/images/spacer.gif) |
aaea
Joined: 11 Jan 2010 Posts: 8
|
|
Posted: Mon Jan 11, 2010 11:50 pm |
|
|
Hi Wayne_
Thank you for your reply.
Can you please tell me if there is a way to prevent the EEPROM from being re-programmed in the *.c code? Is there a line/command I can add?
It turns out that I could not get write_program_eeprom to work for the PIC18F2550, however the write_eeprom() does work.
Regards
a. |
|
![](templates/subSilver/images/spacer.gif) |
Wayne_
Joined: 10 Oct 2007 Posts: 681
|
|
Posted: Tue Jan 12, 2010 3:16 am |
|
|
I didn't actually spot that you were writing to the program memory but the same problem applies.
Actually it is worse.
Your program memory is just that, the programable memory where your code resides.
If you look at the memory map for your device and read some info on the CCS compiler you will notice that the lower area of memory is reserved for interrupt routines, you are trying to write to addresses 10, 11, 12, 13, 14, 15, 16, 17
This is not a good area to use as it will most likely corrupt your code.
Second problem is preventing the programmer to overwrite the area you are using when you re-program it.
You can do this by reserving the area with #org and then telling the programmer to only erase the required area for re-programming. As long as the blocks that contain the reserved memory do not ALSO contain code.
But, usually with an application like this you would include both sets of code anyway. This is so that if you have a clean device you program it once and it will initialise the values.
The way to stop it from re-initialising the values each time it is run is by using a magic number stored somewhere in the memory you are programming.
For instance. it is easier to use the data EEPROM rather than program code as this is treated seperately when programming anyway and you can just tell the programmer not to program that area when updating your code.
Assuming your data may grow lets use areas 0,1,2,3 for our magic number and areas 4 upwards for data.
knowing that when the device is erased it sets the memory locations to 0xFF you just need to check for the magic number in your init routine. If it is there then assume you have already written to memory. |
|
![](templates/subSilver/images/spacer.gif) |
|