| View previous topic :: View next topic |
| Author |
Message |
Marco27293
Joined: 09 May 2020
Posts: 126
|
| PIC18F47J53 CCS C Compiler 5.090 #org question |
 Posted: Thu Jul 23, 2020 6:49 am |
 |
|
Hi,
I tried to reserve this block of memory:
#org 0x00002, 0x00007 {}
but compiler gives an error, why?
I noted that these 3 memory cells are related to NOP assembly instruction in all the projects I successfully compiled and built.
Is it a case or for any reason these cells are always assigned to NOP instruction by the hardware ?
Thanks for your reply
Marco |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9228
Location: Greensville,Ontario
|
|
| Posted: Thu Jul 23, 2020 7:03 am |
|
|
quick comment
Please see/read the datasheet section on 'memory', 6.1.1.......... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Thu Jul 23, 2020 7:21 am |
|
|
This part of memory, is under the control of the compiler. It is where first
the vector to the code is inserted, then 0x0008 is where the high priority
interrupt vector goes. As far as the compiler is concerned these addresses
are already in use, and there isn't enough space to insert any routine.
The goto instruction at the start of memory, is a two word instruction, so
actually occupies 0x0000, 0x0001, 0x0002 & 0x0003. You then only have
four bytes here.
If you just want to ensure these are cleared, then add:
#ROM 0x0004={0,0}
Which will force the available four bytes to zero. |
|
|
Marco27293
Joined: 09 May 2020
Posts: 126
|
|
| Posted: Thu Jul 23, 2020 9:36 am |
|
|
Thank you Ttelmah,
Now it is clearer.
but why:
#org 0x00004,0x00007 {}
gives:
Info#300 More info: Attempted to create: 00004-00006 for #org Error#126 Invalid ORG range
??
Also:
#ROM 0x0004={0,0}
gives error#126
Regards,
Marco |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1349
|
|
| Posted: Thu Jul 23, 2020 12:03 pm |
|
|
| Marco27293 wrote: | Thank you Ttelmah,
Now it is clearer.
but why:
#org 0x00004,0x00007 {}
gives:
Info#300 More info: Attempted to create: 00004-00006 for #org Error#126 Invalid ORG range
??
|
They already explained that the microprocessor specifies this memory location as used by default and the compiler has thus "reserved it" by default. Perhaps a better route to go: Why do you want to write to that specific location. If we know why, we can provide the intended work around. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Thu Jul 23, 2020 1:10 pm |
|
|
| Quote: |
#ROM 0x0004={0,0}
gives error#126
|
What compiler version are you on?.
I did check that this compiles correctly with three versions from the last year...
Where are you placing this?.
| Code: |
#include <18F47J53.h>
#device ADC=12
#FUSES NOWDT //No Watch Dog Timer
#use delay(crystal=20000000)
#ROM 0x0004={0,0}
void main()
{
while(TRUE)
{
delay_cycles(1);
}
}
|
Merrily compiles on the current compiler (5.094), on 5.070, and 5.049.
Also if you look at the .lst file generated it merrily writes 0 to these four
bytes. |
|
|
Marco27293
Joined: 09 May 2020
Posts: 126
|
|
| Posted: Fri Jul 24, 2020 1:36 am |
|
|
My compiler version is CCS C 5.090
I'm developing a bootloader and I want avoid that these cells might be occupied by bootloader instructions, because they must belong to application code.
| Code: | // Localize loader code
#define RESET_VECTOR 0x0000 // Defined by hardware
#define HIGH_INT_VECTOR 0x0008 // Defined by hardware
#define NORMAL_INT_VECTOR 0x0018 // Defined by hardware
#define INTERRUPT_END 0x001A // End of the interrupt area
#define LOADER_START 0xE87F // Loader code start: Developer choice, suitable for PIC18F family (both 64K and 128K Program memory)
#define LOADER_END 0xFF7F // Loader code end : Developer choice, suitable for PIC18F family (both 64K and 128K Program memory)
// Localize application after download
#build(reset=0x0000, interrupt=0x0008)
#ROM 0x0004={0,0}
#org HIGH_INT_VECTOR+2, NORMAL_INT_VECTOR-1 {}
#org INTERRUPT_END, LOADER_START-1 {}
#org LOADER_END+2, (getenv("program_memory")-1) {}
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Fri Jul 24, 2020 2:11 am |
|
|
The instruction at the reset address will always be a goto xxxx, so how can
anything ever 'get' to the instruction at 0x0004?. Unless code deliberately
jumps to that location, it can never be reached. The only exception to this
is on chips where there is a clock tuning value loaded at boot, where there
has to be an extra instruction in front of the goto, to save this, so
the actual sequence is then:
save the clock tuning value
goto application.
This is actually 'why' the extra space is there. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
