|
|
View previous topic :: View next topic |
Author |
Message |
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
Why do I get a programing mismatch |
Posted: Tue Jan 24, 2006 5:05 pm |
|
|
When I program this compiled hex file I get a mismatch at the 0x7FFA location. Expected FF Actual 01.... If I take out the #fill_rom it programs OK. Am I missing something?
Code: | #include <18f452.h>
#case
#use delay(clock=40000000)
#fuses h4,nowdt,noprotect,nolvp
#define VER_MAJOR 2
#define VER_MINOR 01
#use rs232(baud=19200,xmit=PIN_C0,invert,stream=DEBUG,disable_ints) // stderr(same as debug)
#org 0x7FFA, 0x7FFF {}
#rom 0x7FFA={0x0201,0x0403,0xFF05}
#fill_rom 0xFFFF
char RX_BUF[256];
#org 0x7C00, 0x7F00 default
#use I2C(MASTER,SDA=PIN_C4,SCL=PIN_C3,FORCE_HW,FAST,RESTART_WDT)
void PrgmPIC(void){
disable_interrupts(GLOBAL);
reset_cpu();
}
#org default
//======================= main ============================//
void main(void)
{
int8 count=0;
fprintf(DEBUG,"start\n\r");
while(1)
{
}
}
|
End of Hex file useing #fill_rom looks like this.
Code: | :107FE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA1
:107FF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF91
:067FFA000102030405FF73
:020000040030CA
:0E00000000260F0E000181000FC00FE00F4020
:00000001FF
;PIC18F452
|
which to me in one breath says fill 0x07FF0 with FF
then changes it to fill 0x7FFA with 0102030405
I read back the chip, with both cases and it does program the 0102030405. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Jan 24, 2006 5:22 pm |
|
|
The #fill_rom command is not smart enough to avoid rom areas that
have already been set with the #rom command. |
|
|
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Tue Jan 24, 2006 5:27 pm |
|
|
But I read the chip. It programed the 0102030405. So #fill_rom worked. Or it was reprogramed with the next line.
It is just the ICD compairison that fell on its face.
Any way around this? |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Jan 24, 2006 5:38 pm |
|
|
Yes, but if you look at the Hex file, it's got 16 bytes of FF, starting at
address 7FF0. Then it's got 6 bytes of data, starting at address 7FFA.
This is what I meant when I said that #Fill_rom is not smart enough
to avoid putting overlapping data into the Hex file. Ideally, instead
of putting 16 bytes of FF at 7FF0, it shoul only have put 10 bytes there.
Then it wouldn't overlap your special data at 7FFA. |
|
|
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Tue Jan 24, 2006 5:48 pm |
|
|
Is there any way around the problem? |
|
|
|
|
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
|