CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Out of Rom, A segment or the program is too large...

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
edhaslam



Joined: 15 Jul 2005
Posts: 89
Location: UK

View user's profile Send private message

Out of Rom, A segment or the program is too large...
PostPosted: Thu Nov 24, 2005 7:34 am     Reply with quote

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 Wink
newguy



Joined: 24 Jun 2004
Posts: 1903

View user's profile Send private message

PostPosted: Thu Nov 24, 2005 8:46 am     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Nov 24, 2005 9:26 am     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Nov 24, 2005 1:39 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Fri Nov 25, 2005 6:56 am     Reply with quote

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

View user's profile Send private message

PostPosted: Fri Nov 25, 2005 2:00 pm     Reply with quote

Well, you were the one who wanted to do this. I was just supplying
the technical information so you could do it. Mr. Green

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








PostPosted: Wed Nov 30, 2005 8:23 am     Reply with quote

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. Mr. Green

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 Wink

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







PostPosted: Wed Nov 30, 2005 11:26 am     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Feb 02, 2006 7:45 am     Reply with quote

In my LST file... i can't find... #org


to change...

#org 0x07F0, 0x07FF

ROM 0x7F0 = {"v0.01",
"24/11/05"}
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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