CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

#ROM on 18F452

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Burt Poppenga
Guest







#ROM on 18F452
PostPosted: Tue Feb 11, 2003 7:08 pm     Reply with quote

Hello,

I recently migrated my app from a 16f877 to the 18f452: can't seem to get the #ROM stuff working. I have seen some related threads here, so I am hoping someone can help. Here is a small test app:

//===========================================================
// rom-test.c
// Simple 18Fxxx #ROM test: used to work on 16F877.
//===========================================================
#include <18F452.h>

#fuses XT,NOWDT,PUT,NOLVP,NOPROTECT
#device *=16 // Use 16 bit pointers to RAM
#device ADC=10 // Configure # ADC Bits to 10
#use delay(clock=4000000, RESTART_WDT) // 4 MHz clock

// Reserve what used to be Page 3 ROM on the 16F877
#org 0x1800, 0x1FFF {}

// Zone 1
#define ZN_1 0x1800

#ROM ZN_1 = {
0x400,0x401,0x402,0x403,0x404,0x405,0x406,0x407,
0x408,0x409,0x40A,0x40B,0x40C,0x40D,0x40E,0x40F
}

int16 lookup;

//===========================================================
// main()
//===========================================================
main()
{
int8 i;

//Loop around and read a few of the ROM table values ...
for (i=0; i < 10; i++)
{
lookup = read_program_eeprom(ZN_1 + i);
}

while(1) {}
}

I see some reasonable looking stuff in the HEX file:
:020000040000FA
:1000000002EF00F0FFFFF86AD09EEA6AE96A070E85
:10001000C16E076A07500908D8A026EF00F0075004
:10002000086E180E096EF86A09C0F7FF08C0F6FFDF
:100030000900FFFFF5500800FFFFF5CF03F0F86A55
:10004000056E03C006F0072A0AEF00F026EF00F065
:020050000300AB
:10180000000401040204030404040504060407049C
:10181000080409040A040B040C040D040E040F044C
:020000040030CA
:0E00000000210E0E000181000FC00FE00F4026
:00000001FF
;PIC18F452

But after loading it up with MPLAB6/MPLAB ICD 2 I see this in program memory:

1800 040F FFFF FFFF FFFF FFFF ....
1810 FFFF FFFF FFFF FFFF FFFF ....

Needless to say, my test returns a lot of F's.

Thanks,
Burt

PCH: 3.141
MPLAB: 6.12
___________________________
This message was ported from CCS's old forum
Original Post ID: 11561
john cutler



Joined: 06 Sep 2003
Posts: 82
Location: Hot Tub, California

View user's profile Send private message

Re: #ROM on 18F452
PostPosted: Tue Feb 11, 2003 7:32 pm     Reply with quote

Burt:

I've also gone quite mad trying to get #rom to work wth 18Fxxx chips and PCH. Many far more knowledgible than myself have written on this bbs about it. All I can do is offer this little bit of knowledge:

the PIC18F stores byte data in its program flash memory - the 16Fxxx stores 16 bit words.

the 18F series has special table ptr and table read registers and instructions which are discussed in the Microchip data sheets.

There is an issue with byte ordering - high or low byte first.

Search posts from the past month or two here and you'll find much discussion on the subject. For me, it reminded me that I used to use assembler and that for micro's it often makes sense to use it. I find that I spend more time trying to figure out the idiosyncracies of CCS functions than programming, and I think it's often wiser to roll your own.

JC




:=Hello,
:=
:=I recently migrated my app from a 16f877 to the 18f452: can't seem to get the #ROM stuff working. I have seen some related threads here, so I am hoping someone can help. Here is a small test app:
:=
:=//===========================================================
:=// rom-test.c
:=// Simple 18Fxxx #ROM test: used to work on 16F877.
:=//===========================================================
:=#include <18F452.h>
:=
:=#fuses XT,NOWDT,PUT,NOLVP,NOPROTECT
:=#device *=16 // Use 16 bit pointers to RAM
:=#device ADC=10 // Configure # ADC Bits to 10
:=#use delay(clock=4000000, RESTART_WDT) // 4 MHz clock
:=
:=// Reserve what used to be Page 3 ROM on the 16F877
:=#org 0x1800, 0x1FFF {}
:=
:=// Zone 1
:=#define ZN_1 0x1800
:=
:=#ROM ZN_1 = {
:= 0x400,0x401,0x402,0x403,0x404,0x405,0x406,0x407,
:= 0x408,0x409,0x40A,0x40B,0x40C,0x40D,0x40E,0x40F
:= }
:=
:=int16 lookup;
:=
:=//===========================================================
:=// main()
:=//===========================================================
:=main()
:={
:= int8 i;
:=
:= //Loop around and read a few of the ROM table values ...
:= for (i=0; i < 10; i++)
:= {
:= lookup = read_program_eeprom(ZN_1 + i);
:= }
:=
:= while(1) {}
:=}
:=
:=I see some reasonable looking stuff in the HEX file:
:=:020000040000FA
:=:1000000002EF00F0FFFFF86AD09EEA6AE96A070E85
:=:10001000C16E076A07500908D8A026EF00F0075004
:=:10002000086E180E096EF86A09C0F7FF08C0F6FFDF
:=:100030000900FFFFF5500800FFFFF5CF03F0F86A55
:=:10004000056E03C006F0072A0AEF00F026EF00F065
:=:020050000300AB
:=:10180000000401040204030404040504060407049C
:=:10181000080409040A040B040C040D040E040F044C
:=:020000040030CA
:=:0E00000000210E0E000181000FC00FE00F4026
:=:00000001FF
:=;PIC18F452
:=
:=But after loading it up with MPLAB6/MPLAB ICD 2 I see this in program memory:
:=
:=1800 040F FFFF FFFF FFFF FFFF ....
:=1810 FFFF FFFF FFFF FFFF FFFF ....
:=
:=Needless to say, my test returns a lot of F's.
:=
:=Thanks,
:=Burt
:=
:=PCH: 3.141
:=MPLAB: 6.12
___________________________
This message was ported from CCS's old forum
Original Post ID: 11564
Burt Poppenga
Guest







Re: #ROM on 18F452
PostPosted: Tue Feb 11, 2003 7:39 pm     Reply with quote

JC,

Thanks for the reply, I have been searching around and seeing lots of good discussions. I did fix up my little test app to deal with the byte addressing issue:

for (i=0; i < 10; i++)
{
// Addresses are to bytes, so move by two each time
lookup = read_program_eeprom(ZN_1 + (i*2));
}

The thing that is blowing my mind: the HEX file looks like it has the right stuff in it, yet only the first word of program memory gets loaded (with the last word of data). Does this make any sense?

Burt
___________________________
This message was ported from CCS's old forum
Original Post ID: 11565
john cutler



Joined: 06 Sep 2003
Posts: 82
Location: Hot Tub, California

View user's profile Send private message

Re: #ROM on 18F452
PostPosted: Tue Feb 11, 2003 8:21 pm     Reply with quote

:=JC,
:=
:=Thanks for the reply, I have been searching around and seeing lots of good discussions. I did fix up my little test app to deal with the byte addressing issue:
:=
:= for (i=0; i < 10; i++)
:= {
:= // Addresses are to bytes, so move by two each time
:= lookup = read_program_eeprom(ZN_1 + (i*2));
:= }
:=
:=The thing that is blowing my mind: the HEX file looks like it has the right stuff in it, yet only the first word of program memory gets loaded (with the last word of data). Does this make any sense?
:=
:=Burt
___________________________
This message was ported from CCS's old forum
Original Post ID: 11566
john cutler



Joined: 06 Sep 2003
Posts: 82
Location: Hot Tub, California

View user's profile Send private message

Re: #ROM on 18F452
PostPosted: Tue Feb 11, 2003 8:23 pm     Reply with quote

I dod remember seeing or an email that the .LST file doesn't show the #om data and that I as told to look at the HEX file to see it.

jc


:=JC,
:=
:=Thanks for the reply, I have been searching around and seeing lots of good discussions. I did fix up my little test app to deal with the byte addressing issue:
:=
:= for (i=0; i < 10; i++)
:= {
:= // Addresses are to bytes, so move by two each time
:= lookup = read_program_eeprom(ZN_1 + (i*2));
:= }
:=
:=The thing that is blowing my mind: the HEX file looks like it has the right stuff in it, yet only the first word of program memory gets loaded (with the last word of data). Does this make any sense?
:=
:=Burt
___________________________
This message was ported from CCS's old forum
Original Post ID: 11567
Burt_Poppenga
Guest







Re: #ROM on 18F452
PostPosted: Wed Feb 12, 2003 2:52 pm     Reply with quote

Just an update for you folks.

I started noticing some diferences between the HEX and COD files for my simple test application, so I did the following test:
- Re-named the HEX and COD files (allow MPLAB to load the hex)
- Open MPLAB
- Import the HEX file
- Examine program memory at 0x1800 (all looks well)
- Import the COD file
- Examine program memory at 0x1800 (all is not well)

I sent this info to the folks at CCS an received the following reply:
"Thanks for pointing out the problem in the cod file. We have fixed it and would be available in the next release(probably tomorrow)."

So hopefully my application will be back in action soon ...
___________________________
This message was ported from CCS's old forum
Original Post ID: 11615
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group