| View previous topic :: View next topic |
| Author |
Message |
csanders
Joined: 23 Apr 2005
Posts: 16
|
| EEPROM read error -- Only even # addresses can be wrote |
 Posted: Wed Dec 07, 2005 2:41 pm |
 |
|
Hello everybody
I have a 18F8720 & am trying to store some default values in the eeprom when the pic is programmed via the rom# statement -- Here is my header file
| Code: |
#include <18F8720.h>
#device ICD=TRUE
#fuses NOWDT, HS, NOCPD, NOWRT, NOWRTD, MCU
#use delay(clock=20000000)
//Load default values into eeprom when mcu is programmed
#rom 0xF00000 = {
0xA1, //EEPROM Address 0x00
0x6B, //EEPROM Address 0x01
0x1C, //EEPROM Address 0x02
0x9D, //EEPROM Address 0x03
0xFE, //EEPROM Address 0x04
0x2A //EEPROM Address 0x05
}
|
But when I read these values from an initialization routine, I get the following results.
EE Addr 0x00 = 0xA1
EE Addr 0x01 = 0x00
EE Addr 0x02 = 0x6B
EE Addr 0x03 = 0x00
EE Addr 0x04 = 0x1C
EE Addr 0x05 = 0x00
EE Addr 0x06 = 0x9D
EE Addr 0x07 = 0x00
EE Addr 0x08 = 0xFE
EE Addr 0x09 = 0x00
EE Addr 0x0A = 0x2A
As you can see, the data is obviously being placed in the eeprom, only skipping the odd addresses. I'm sure I have overlooked something in the compiler manual that may be causing this. Can anyone help me to correct this?
btw, I am using the read_eeprom(addr); function to retrieve the values.
Any help is appreciated[/code] |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Dec 07, 2005 3:11 pm |
|
|
| Quote: | As you can see, the data is obviously being placed in the eeprom,
only skipping the odd addresses. I'm sure I have overlooked something
in the compiler manual that may be causing this. Can anyone help me to
correct this? |
This thread has an example of using int8 as a qualifier in the #rom statement:
http://www.ccsinfo.com/forum/viewtopic.php?t=23914&highlight=rom+int8+0xf00000 |
|
|
csanders
Joined: 23 Apr 2005
Posts: 16
|
|
| Posted: Thu Dec 08, 2005 12:23 am |
|
|
Thank you PCM -- that was the answer I was looking for.
It's frustating searching for answers in older posts when you don't input the correct keywords & find zilch related to your issue. |
|
|
UFAnders
Joined: 13 Apr 2005
Posts: 36
Location: Michigan
|
|
| Posted: Mon Mar 13, 2006 11:15 pm |
|
|
Yes PCM, Bravo!
It took me about half an hour to find your post, but it answered all of my questions save one: Where is this #ROM type qualifier documented in the CCS documentation?  |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Tue Mar 14, 2006 3:01 am |
|
|
| UFAnders wrote: | | Where is this #ROM type qualifier documented in the CCS documentation? |
PICC manual October 2005, page 58. This manual can be downloaded from the CCS site.
The description is incomplete, missing the int8 specifier. |
|
|
rnielsen
Joined: 23 Sep 2003
Posts: 852
Location: Utah
|
|
| Posted: Tue Mar 14, 2006 9:33 am |
|
|
You could also enter the code as follows:
| Code: |
#rom 0xF00000 = {
0x6BA1, //EEPROM Address 0x00 & 0x01
0x9D1C, //EEPROM Address 0x02 & 0x03
0x2AFE //EEPROM Address 0x04 & 0x05
}
|
This works because the part defaults to 16 bits.
Ronald |
|
|
UFAnders
Joined: 13 Apr 2005
Posts: 36
Location: Michigan
|
|
| Posted: Tue Mar 14, 2006 10:37 am |
|
|
| rnielsen wrote: | You could also enter the code as follows:
| Code: |
#rom 0xF00000 = {
0x6BA1, //EEPROM Address 0x00 & 0x01
0x9D1C, //EEPROM Address 0x02 & 0x03
0x2AFE //EEPROM Address 0x04 & 0x05
}
|
This works because the part defaults to 16 bits. |
Actually I tried that before browsing the forum, and all I got was a HEX file with the highbyte (as inserted with the #ROM statement) placed in the SECOND byte space, leaving the first location as 00. This repeated itself for subsequent entries. I am using an 18F2520 with #ROM 0xF00000. |
|
|
rnielsen
Joined: 23 Sep 2003
Posts: 852
Location: Utah
|
|
| Posted: Tue Mar 14, 2006 1:21 pm |
|
|
I've compiled the code for both 18F8720 and 18f2520 and both of them insterted the hex numbers into the proper place of the eeprom. Not sure what might be going on for you. I've used this style for some time now and it's always worked for me.
Ronald |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
