 |
 |
| View previous topic :: View next topic |
| Author |
Message |
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
| intel hex file location 4,5,6,7 |
 Posted: Fri Nov 11, 2005 4:05 pm |
 |
|
pcwh3.2328,18F452,40mhz
I am making a boot loader of sorts. I was looking at a intel hex file and the
address started at 0 and has data for 0,1,2,3 then the address jumps to 8??
So...
When i loaded the hex file in mplab it read loacation 4,5,6,7 at FF's.
Will that be always so?
Can I assume that my hex file has data for 0,1,2,3, FF FF FF FF,then 8 and the
rest consecutive addresses?
pdf page 38 shows them as empty. Can i try to program them to FF so my
data stays all nice and consecutive? |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Nov 11, 2005 4:44 pm |
|
|
You're very likely looking at the reset vector code (at 0x0000) and
interrupt vector code (at 0x0008). The FF's are un-programmed
(erased) flash memory. The compiler always puts its "jump to main()"
code at location 0x0000 and the interrupt dispatcher at 0x0008 (for the 18F series) unless you specify other addresses with the #build directive. |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Fri Nov 11, 2005 4:59 pm |
|
|
| I think your right. But can I program them with FF's or do I need to jump those location? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Nov 11, 2005 5:49 pm |
|
|
The code that you program at 0x0000 is presumably going to jump to
main(), which is somewhere up in higher memory. So does it matter
what those unused locations are, since they're never executed ?
If you want to ensure that they're set to 0xFF, then you can use the
CCS function, write_program_memory() to do that. See the sample
program below which shows that it can be done.
The output of the program is:
| Quote: | 00 01 02 03 04 05 06 07
55 AA 77 88 FF FF FF FF |
| Code: | #include <18F452.h>
#fuses XT,NOWDT,NOPROTECT,PUT,BROWNOUT,NOLVP
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
//=============================
void main()
{
int8 i;
int8 write_buffer[8] = {0,1,2,3,4,5,6,7};
int8 read_buffer[8];
// Initialize 8 bytes of program memory, starting at
// address 0x1000 to 0,1,2,3,4,5,6,7.
write_program_memory(0x1000, write_buffer, 8);
// Then read them and display them.
read_program_memory(0x1000, read_buffer, 8);
for(i = 0; i < 8; i++)
printf("%X ", read_buffer[i]);
printf("\n\r");
//---------------------------
// Now overwrite the buffer with new data, but set the
// last four bytes, starting at address 0x1004, to 0xFF.
write_buffer[0] = 0x55;
write_buffer[1] = 0xAA;
write_buffer[2] = 0x77;
write_buffer[3] = 0x88;
write_buffer[4] = 0xFF;
write_buffer[5] = 0xFF;
write_buffer[6] = 0xFF;
write_buffer[7] = 0xFF;
write_program_memory(0x1000, write_buffer, 8);
// Read the block of 8 bytes and display them.
read_program_memory(0x1000, read_buffer, 8);
for(i = 0; i < 8; i++)
printf("%X ", read_buffer[i]);
printf("\n\r");
while(1);
} |
|
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Mon Nov 14, 2005 8:35 am |
|
|
| thanks |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
| Re: intel hex file location 4,5,6,7 |
| Posted: Mon Nov 14, 2005 9:47 am |
|
|
| treitmey wrote: | pcwh3.2328,18F452,40mhz
I am making a boot loader of sorts. I was looking at a intel hex file and the
address started at 0 and has data for 0,1,2,3 then the address jumps to 8??
So...
When i loaded the hex file in mplab it read loacation 4,5,6,7 at FF's.
Will that be always so?
|
No. Depending on the processor, the first location may have a NOP to accommodate a debugger.
Some compilers (including CCS) will, depending on the phases of the moon, stick a small code fragment between 0x0005 and 0x0007. If your application does not use interrrupts then the compiler will almost certainly use this address space. You can fix this in CCS using | Code: | | #build(reset=0x00:0x07) |
Generally a PIC18F bootloader assumes a long jump will occur in the first 8 bytes (4 instructions) so when you remap the reset vector you should assume you need to accommodate 8 bytes. To play it safe the next locatio n in ROM should have a reset instruction or a jump to itself to prevent the bootloader code wandering off into the never never potentially corrupting whatever you do not want corrupted.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
