|
|
View previous topic :: View next topic |
Author |
Message |
edhaslam
Joined: 15 Jul 2005 Posts: 89 Location: UK
|
Out of Rom, A segment or the program is too large... |
Posted: Thu Nov 24, 2005 7:34 am |
|
|
Hi all,
I'm converting some code from an old F877A project and running it on a an 18F452. I'm getting the "Out of Rom, A segement or the program is too large" error message. If I comment out the following org statement that I use for storing info in EEPROM, then everything is fine:
Code: |
#org 0x07F0, 0x07FF
const char version[] = {"v0.01"};
const char date[] = {"24/11/05"};
|
The internal EEPROM size of the 'F452 is the same as the 'F877A, so I wouldn't have expected any problems there. Is there some other trick (I'm new to the 18Fxxxx range of devices). Any tips would be appreciated...
Cheers,
Ed
PS: I'm using: #device *=16 and v3.239 PCWH |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Thu Nov 24, 2005 8:46 am |
|
|
I suspect the problem lies with where you're trying to put that data with the #org.
In the 18F's, the EEPROM starts at address 0xf00000, as opposed to 0x2100 for the 16F's. If you search for "#rom 0xf00000" you'll find lots of posts dealing with the same issue. If you relocate your version and date information into the pic's data EEPROM, then you'll probably avoid your "out of rom" error.
Hope this helps. |
|
|
edhaslam
Joined: 15 Jul 2005 Posts: 89 Location: UK
|
|
Posted: Thu Nov 24, 2005 9:26 am |
|
|
newguy wrote: | I suspect the problem lies with where you're trying to put that data with the #org.
In the 18F's, the EEPROM starts at address 0xf00000, as opposed to 0x2100 for the 16F's. If you search for "#rom 0xf00000" you'll find lots of posts dealing with the same issue. If you relocate your version and date information into the pic's data EEPROM, then you'll probably avoid your "out of rom" error.
Hope this helps. |
Thanks newguy, i'll do a search and ammend the address. Many thanks,
Ed |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Nov 24, 2005 1:39 pm |
|
|
Quote: |
I'm converting some code from an old F877A project and running it on a
an 18F452. I'm getting the "Out of Rom, A segement or the program is
too large" error message. |
The problem is caused by the way the program memory is addressed
in the 16F and the 18F. If you look at the .LST file for you program
you'll see that for a 16F program, it uses one address per 14-bit ROM
word. (To see this code in the .LST file, you have to edit the 16F877A.H
file and comment out the #nolist statement. Then recompile.)
Code: |
07E0: BSF PCLATH.0
07E1: BSF PCLATH.1
07E2: BSF PCLATH.2
07E3: ADDWF PCL,F
07E4: RETLW 76
07E5: RETLW 30
07E6: RETLW 2E
07E7: RETLW 30
07E8: RETLW 31
07E9: RETLW 00
07EA: RETLW 00
|
But in the 18F below, notice how the program memory is addressed as
bytes, so it takes two "ROM addresses" to store one ROM word. Notice how
how they go up by 0, 2, 4, 6, 8, etc., and compare that to the 16F.
Code: |
07C0: CLRF TBLPTRH
07C2: ADDLW D0
07C4: MOVWF TBLPTRL
07C6: MOVLW 07
07C8: ADDWFC TBLPTRH,F
07CA: TBLRD*+
07CC: MOVF TABLAT,W
07CE: RETURN 0
07D0: DATA 76,30
07D2: DATA 2E,30
07D4: DATA 31,00
|
So to move your code from the 16F to the 18F, you need to increase
the size of the #org range to accommodate this new addressing method.
Example for 18F:
Notice that I have increased each ROM address range to 32 bytes.
Also notice that each line has its own #org statement. .
If I left off the 2nd #org statement, the compiler ignored the date[] line.
Code: |
#org 0x07C0, 0x07DF
const char version[] = {"v0.01"};
#org 0x07E0, 0x7FF
const char date[] = {"24/11/05"};
|
The same thing was necessary with the 16F code. Two #org statements
were needed. I couldn't get your 16F code, as posted, to store both lines.
Code: |
#org 0x07E0, 0x07EF
const char version[] = {"v0.01"};
#org 0x07F0, 0x7FF
const char date[] = {"24/11/05"};
|
Finally, because the 18F has a much larger ROM space, you could move
the two strings up much higher in ROM, if you wanted to. |
|
|
edhaslam
Joined: 15 Jul 2005 Posts: 89 Location: UK
|
|
Posted: Fri Nov 25, 2005 6:56 am |
|
|
Many thanks PCM, that was very useful indeed. I'll test the new settings and perhaps move them to the end of the ROM.
What is the benefit of doing this? Does it matter where they reside in ROM?
Ed |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Nov 25, 2005 2:00 pm |
|
|
Well, you were the one who wanted to do this. I was just supplying
the technical information so you could do it.
Let's speculate on reasons for locating the version strings in a
specific location:
1. Assuming that you're using MPLAB to program the PICs, it would
allow the user to look in the Program Memory window and easily
locate the version information, and thereby confirm that the proper
version is being programmed.
2. If you were doing a bootloader, and the bootloader code was
located in a specific area of the ROM, and you wanted to put the
bootloader version information there as well, then you might do this.
3. Perhaps you want to assist the compiler in partitioning functions and
data in ROM, and so you decide to "help" the compiler by putting
the version information in some out-of-the-way location like the
end of ROM memory.
I assume you have some reason for doing it. It's up to you to decide
if you need to do it. |
|
|
Guest
|
|
Posted: Wed Nov 30, 2005 8:23 am |
|
|
PCM programmer wrote: | Well, you were the one who wanted to do this. I was just supplying
the technical information so you could do it.
Let's speculate on reasons for locating the version strings in a
specific location:
1. Assuming that you're using MPLAB to program the PICs, it would
allow the user to look in the Program Memory window and easily
locate the version information, and thereby confirm that the proper
version is being programmed.
2. If you were doing a bootloader, and the bootloader code was
located in a specific area of the ROM, and you wanted to put the
bootloader version information there as well, then you might do this.
3. Perhaps you want to assist the compiler in partitioning functions and
data in ROM, and so you decide to "help" the compiler by putting
the version information in some out-of-the-way location like the
end of ROM memory.
I assume you have some reason for doing it. It's up to you to decide
if you need to do it. |
Ok, so I was a little ambiguous with my question
I know why I want to do it - because I want to store the version no./date somewhere where I can see it in the Program Memory window and locate the information. However...
I'll rephrase the question:
- For what reason should you put the information towards the end of the ROM memory?
Cheers,
Ed |
|
|
Ttelmah Guest
|
|
Posted: Wed Nov 30, 2005 11:26 am |
|
|
Basically. you increase the 'segmentation' of the memory, requiring the compiler to not only optimise to deal with the processor limitations, but also to work out how to cope with this immovable block. It is a bit like adding a codicil to a book. If you add it at the end, the book can remain unchanged, as can the indexes etc.. However it you insisted on adding it in the middle, all the indexes have to change, and if the book is sectional, you may end up spliting a 'chapter', making it impossible to fit in either part.
Now ignoring this, seperately, there is the question of how much space is actually needed for a declaration. If you declare a 'const', then the compiler includes the code to access the constant, _in_ the declaration. So what you declare will not fit in the space you are allowing. This was the point made by PCM programmer, together with the point that an ORG like this, only places the next declaration at the specified address, so two declarations are needed.
If instead you make a ROM declaration, only the declared data is generated. So, if you had declared your data as:
Code: |
#org 0x07F0, 0x07FF
ROM 0x7F0 = {"v0.01",
"24/11/05"}
|
You would not have had the error message (since this would now fit in the space), and is a single declaration.
You talk about the 'EEPROM', yet this address is not part of the EEPROM memory on either processor. You would not use the #ORG declaration on the EEPROM, since this prevents code being put into the area concerned, and can therefore only be used on the program memory. So if you put the data into the EEPROM memory, you could just use:
Code: |
ROM 0xF00000 = {"v0.01",
"24/11/05"}
|
and the data would now sit at the start of the EEPROM memory, and not interfere with the code at all.
Best Wishes |
|
|
sonicdeejay
Joined: 20 Dec 2005 Posts: 112
|
|
Posted: Thu Feb 02, 2006 7:45 am |
|
|
In my LST file... i can't find... #org
to change...
#org 0x07F0, 0x07FF
ROM 0x7F0 = {"v0.01",
"24/11/05"} |
|
|
|
|
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
|