#ROM on 18F452

[Burt Poppenga]

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]

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]

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]

:=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]

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]

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