 |
 |
| View previous topic :: View next topic |
| Author |
Message |
object01
Joined: 13 May 2004
Posts: 90
Location: Nashville, TN
|
| #org has no effect |
 Posted: Wed Jun 30, 2004 7:53 am |
 |
|
I'm trying to use an #org directive to reserve four bytes in ROM (PIC18LF2320) for a non-volatile device serial number, that only changes when running a program compiled with a special directive. But my #org doesn't seem to have any effect.
I've tried,
#org 0x100, 0x103 {}
and the symbol list shows the following:
100 @MUL1616.@SCRATCH
103 getGPSFix.attempts
104-105 strcpyn.s1
I've tried,
#org 0x100, 0x400 {}
and absolutely nothing changes. The size of the .hex file is the same, the symbol list is unchanged, nothing.
I've tried #org and #ORG to no avail.
Am I missing something?
--
Jeff S. |
|
 |
dyeatman
Joined: 06 Sep 2003
Posts: 1934
Location: Norman, OK
|
|
| Posted: Wed Jun 30, 2004 8:01 am |
|
|
What happens when you actually try to put something there as a placeholder?
For example:
#ORG 0x100, 0x103
char test1[4]; |
|
|
Guest
|
| Re: #org has no effect |
| Posted: Wed Jun 30, 2004 8:29 am |
|
|
| object01 wrote: |
and the symbol list shows the following:
100 @MUL1616.@SCRATCH
103 getGPSFix.attempts
104-105 strcpyn.s1
|
symbol list shows RAM space, #org 0x100, 0x103 {} reserve ROM space,
if you want to reserve RAM space, then you should use
#reserve 0x100:0x103
see HELP -> index -> #reserve
and HELP -> index -> #org |
|
|
object01
Joined: 13 May 2004
Posts: 90
Location: Nashville, TN
|
| Re: #org has no effect |
| Posted: Wed Jun 30, 2004 8:38 am |
|
|
| Anonymous wrote: | | object01 wrote: |
and the symbol list shows the following:
100 @MUL1616.@SCRATCH
103 getGPSFix.attempts
104-105 strcpyn.s1
|
symbol list shows RAM space, #org 0x100, 0x103 {} reserve ROM space,
if you want to reserve RAM space, then you should use
#reserve 0x100:0x103
see HELP -> index -> #reserve
and HELP -> index -> #org |
Argh. I'm an idiot. But it is ROM I want to reserve. However, the statistics report indicates that ROM usage is only minimally affected by the directive. Without the #org directive, my ROM usage is 6608. With #org 0x100, 0x103 {}, ROM usage is still 6608. With #org 0x100, 0x400 {}, ROM usage is 6610.
--
Jeff S. |
|
|
object01
Joined: 13 May 2004
Posts: 90
Location: Nashville, TN
|
|
| Posted: Wed Jun 30, 2004 8:42 am |
|
|
| dyeatman wrote: | What happens when you actually try to put something there as a placeholder?
For example:
#ORG 0x100, 0x103
char test1[4]; |
I get an out or ROM error with the code above. Compiler reports:
@const325
Seg 00100-00102, 0004 left, need 0008
But without the org directive and the declaration, ROM usage is 6608. Does this mean I'm violating some kind of segment boundary?
--
Jeff S. |
|
|
object01
Joined: 13 May 2004
Posts: 90
Location: Nashville, TN
|
|
| Posted: Wed Jun 30, 2004 9:04 am |
|
|
| dyeatman wrote: | What happens when you actually try to put something there as a placeholder?
For example:
#ORG 0x100, 0x103
char test1[4]; |
I noticed the following:
#org 0x100, 0x106
char testingORG[4] = {0xFF,0xFF,0xFF,0xFF};
...produces the following in the symbol list:
076-079 testingORG
The following:
#org 0x100, 0x106
char testingORG[4] = {0xFF,0xFF,0xFF,0xFF};
...produces an out of ROM error.
--
Jeff S. |
|
|
Ttelmah
Guest
|
| Re: #org has no effect |
| Posted: Wed Jun 30, 2004 10:06 am |
|
|
| object01 wrote: | I'm trying to use an #org directive to reserve four bytes in ROM (PIC18LF2320) for a non-volatile device serial number, that only changes when running a program compiled with a special directive. But my #org doesn't seem to have any effect.
I've tried,
#org 0x100, 0x103 {}
and the symbol list shows the following:
100 @MUL1616.@SCRATCH
103 getGPSFix.attempts
104-105 strcpyn.s1
I've tried,
#org 0x100, 0x400 {}
and absolutely nothing changes. The size of the .hex file is the same, the symbol list is unchanged, nothing.
I've tried #org and #ORG to no avail.
Am I missing something?
--
Jeff S. |
#org, locates something at a location in ROM. However there are 'caveats', when it comes to low memory. You cannot #org, into the areas used by the reset, and the interrupt handler, and some critical system handlers (there are seperate directives to override these vectors for bootloaders etc.). I suspect this is the problem you are hitting.
You also need to turn the #org 'off', using #org default.
What you post would therefore probably work if you put the data higher in memory. However you really need to put something into the area to be sure.
So try:
#org 0x100,0x104
#ROM 0x100 = {1,2,3,4}
#org default
and then try increasing the address if there is still a problem. An area near the top of the ROM, is less likely to cause problems (unless you are using the ICD).
Best Wishes |
|
|
object01
Joined: 13 May 2004
Posts: 90
Location: Nashville, TN
|
| Re: #org has no effect |
| Posted: Wed Jun 30, 2004 11:23 am |
|
|
| Ttelmah wrote: | <snip>
and then try increasing the address if there is still a problem. An area near the top of the ROM, is less likely to cause problems (unless you are using the ICD).
Best Wishes |
Is there a way to know whether I'm violating the ICD's address space (besides the verification errors I'll likely get)? Or, how do I find out what areas are off-limits?
--
Jeff S. |
|
|
object01
Joined: 13 May 2004
Posts: 90
Location: Nashville, TN
|
| Re: #org has no effect |
| Posted: Wed Jun 30, 2004 11:45 am |
|
|
| Ttelmah wrote: | So try:
#org 0x100,0x104
#ROM 0x100 = {1,2,3,4}
#org default |
Tried that, and this is the part of the .hex file containing that range:
00000100 31 46 30 30 46 35 30 30 30 36 45 31 30 35 30 30 1F00F50006E10500
I get the same thing whether the #org block is there or not. I'm only guessing that the #org block should change the hex file somehow, 'cause the listing doesn't seem to associate any instructions with the #org block.
--
Jeff S. |
|
|
Ttelmah
Guest
|
| Re: #org has no effect |
| Posted: Wed Jun 30, 2004 2:26 pm |
|
|
| object01 wrote: | | Ttelmah wrote: | So try:
#org 0x100,0x104
#ROM 0x100 = {1,2,3,4}
#org default |
Tried that, and this is the part of the .hex file containing that range:
00000100 31 46 30 30 46 35 30 30 30 36 45 31 30 35 30 30 1F00F50006E10500
I get the same thing whether the #org block is there or not. I'm only guessing that the #org block should change the hex file somehow, 'cause the listing doesn't seem to associate any instructions with the #org block.
--
Jeff S. |
Yes. You are obviously low enough in memory that other code is overlaying the area. The 'listing' misses a lot of things (turn off the 'nolist' option in the included device file, to get a lot of them back). On the size of the ICD code, the hex files are in the compiler directory, so you can look at these to see where they load.
Best Wishes |
|
|
object01
Joined: 13 May 2004
Posts: 90
Location: Nashville, TN
|
| Re: #org has no effect |
| Posted: Wed Jun 30, 2004 4:13 pm |
|
|
| Ttelmah wrote: | Yes. You are obviously low enough in memory that other code is overlaying the area. The 'listing' misses a lot of things (turn off the 'nolist' option in the included device file, to get a lot of them back). On the size of the ICD code, the hex files are in the compiler directory, so you can look at these to see where they load.
Best Wishes |
But if the #org directive is supposed to effectively reserve ROM, why would other code overlay it?
--
Jeff S. |
|
|
Tony Helinski
Joined: 09 Sep 2003
Posts: 6
|
|
| Posted: Thu Jul 01, 2004 8:54 am |
|
|
In the 18Fxx20 parts and I assume the other 18F parts the NVM starts at
#rom int8 0xF00000 = { <- notice the int8 is used to access the ROM in byte values
This allows you to store initialized data at compile time. (Serial Numbers)
#rom int8 0xF00000 = { 0x01,0x02,0x03 } |
|
|
Ttelmah
Guest
|
| Re: #org has no effect |
| Posted: Thu Jul 01, 2004 9:23 am |
|
|
| object01 wrote: | | Ttelmah wrote: | Yes. You are obviously low enough in memory that other code is overlaying the area. The 'listing' misses a lot of things (turn off the 'nolist' option in the included device file, to get a lot of them back). On the size of the ICD code, the hex files are in the compiler directory, so you can look at these to see where they load.
Best Wishes |
But if the #org directive is supposed to effectively reserve ROM, why would other code overlay it?
--
Jeff S. |
#org, does not affect areas that are allready 'reserved' before it is declared. The areas are:
1) The boot vector (#build allows this to be relocated).
2) The interrupt vector (#interrupt allows this to be relocated).
3) The 'delay' code.
4) The RS232 handler code.
The 'key' is that the last two, are actually placed in the bottom of memory _before_ the #org is met. The CCS compiler, does not recursively apply it's directives (which can be 'useful', allowing multiple #delay statements etc.). In this case, it means that code has allready been written into the area concerned.
You can relocate (for example) the 'delay' code, by adding an 'org' in front of this, and this would potentially allow the problem to be fixed.
Best Wishes |
|
|
object01
Joined: 13 May 2004
Posts: 90
Location: Nashville, TN
|
| Re: #org has no effect |
| Posted: Thu Jul 01, 2004 12:06 pm |
|
|
| Ttelmah wrote: | #org, does not affect areas that are allready 'reserved' before it is declared. The areas are:
1) The boot vector (#build allows this to be relocated).
2) The interrupt vector (#interrupt allows this to be relocated).
3) The 'delay' code.
4) The RS232 handler code.
The 'key' is that the last two, are actually placed in the bottom of memory _before_ the #org is met. The CCS compiler, does not recursively apply it's directives (which can be 'useful', allowing multiple #delay statements etc.). In this case, it means that code has allready been written into the area concerned.
You can relocate (for example) the 'delay' code, by adding an 'org' in front of this, and this would potentially allow the problem to be fixed.
Best Wishes |
Hm. It's pretty frustrating that no error or warning is produced when the compiler decides to "ignore" a directive. Ce la vie...
I could go test areas of memory for compatibility with #org and hope for a hit, but I'd rather be confident that the block I'm specifying is 1) most efficiently placed in relation to other data structures, and 2) not intersecting one of the 4 special blocks you mention. Is there a good way to approach this?
--
Jeff S. |
|
|
Ttelmah
Guest
|
| Re: #org has no effect |
| Posted: Thu Jul 01, 2004 2:59 pm |
|
|
| object01 wrote: | | Ttelmah wrote: | #org, does not affect areas that are allready 'reserved' before it is declared. The areas are:
1) The boot vector (#build allows this to be relocated).
2) The interrupt vector (#interrupt allows this to be relocated).
3) The 'delay' code.
4) The RS232 handler code.
The 'key' is that the last two, are actually placed in the bottom of memory _before_ the #org is met. The CCS compiler, does not recursively apply it's directives (which can be 'useful', allowing multiple #delay statements etc.). In this case, it means that code has allready been written into the area concerned.
You can relocate (for example) the 'delay' code, by adding an 'org' in front of this, and this would potentially allow the problem to be fixed.
Best Wishes |
Hm. It's pretty frustrating that no error or warning is produced when the compiler decides to "ignore" a directive. Ce la vie...
I could go test areas of memory for compatibility with #org and hope for a hit, but I'd rather be confident that the block I'm specifying is 1) most efficiently placed in relation to other data structures, and 2) not intersecting one of the 4 special blocks you mention. Is there a good way to approach this?
--
Jeff S. |
I'd compile the program without any memory reserved. Look in the produced symbol map for the value assined to 'main', and place the block there. This will be the lowest address 'above' this stuff.
You can use
#org default 0x104
inserted at the start of your code (in front of the #use delay, and the RS232 definitions), to force these routines to all be located after the space you require.
Best Wishes |
|
|
|
|
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
