| View previous topic :: View next topic |
| Author |
Message |
Foppie
Joined: 16 Sep 2005
Posts: 138
Location: The Netherlands
|
| RAM/ROM problem |
 Posted: Tue Sep 27, 2005 4:12 am |
 |
|
Hello,
I am programming on a PIC16F877a. Things are running but now I encountered the following problem:
when I add a line in my code (even a simple one as delay_us(1);) my code doesn't function anymore. But when I remove that line. It's running perfectly. The only difference in both sithuations seems to be that when the line is added, I use 32% of my ROM and else I use 31%... I'm not out of RAM (32%-40% used in both cases).
Does someone have an idea of how to solve my problem?
thanks in advance
Jos Foppele
Last edited by Foppie on Wed Sep 28, 2005 6:44 am; edited 1 time in total |
|
 |
Foppie
Joined: 16 Sep 2005
Posts: 138
Location: The Netherlands
|
|
| Posted: Tue Sep 27, 2005 5:51 am |
|
|
| I did some more testing and it seems that if I use more then 31% ROM, the PIC crashes at startup. I'm now trying to shrink my code but still my question remains... |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
| Re: adding a line is a problem |
| Posted: Tue Sep 27, 2005 5:58 am |
|
|
Here is a "left field" one to consider..
I use a bootloader for my projects. It resides in high memory and the only other resources it uses is the first eight bytes of program memory to intercept the reset vector and therefore gain control. The user's program must execute a long jump within the first four instructions. This type of bootloader is very efficient for applications that have critical interrupt handlers as it avoids a double jump required with low memory bootloaders. The bootloader works well and, for the most part, transparently. However, the CCS compiler attempts to maximise the use of memory by using the memory between 0x0004 and 0x0007 for very small code fragments. This manifests itself with the symptoms you describe. The solution is to prevent the CCS compiler from using this memory. I include the following line (PIC18Fxxx specific) in all my projects:
| Code: | | #build(reset=0x0000:0x0007) |
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Foppie
Joined: 16 Sep 2005
Posts: 138
Location: The Netherlands
|
| Re: adding a line is a problem |
| Posted: Tue Sep 27, 2005 6:13 am |
|
|
| asmallri wrote: | The bootloader works well and, for the most part, transparently. However, the CCS compiler attempts to maximise the use of memory by using the memory between 0x0004 and 0x0007 for very small code fragments. This manifests itself with the symptoms you describe. The solution is to prevent the CCS compiler from using this memory. I include the following line (PIC18Fxxx specific) in all my projects:
| Code: | | #build(reset=0x0000:0x0007) |
|
this could be a solution, but I use a PIC16 and not a PIC18. So my next question is: Is there a way to execute #build(reset=0x0000:0x0007) on a PIC16?
a minor point I'd like to add: I use a bootloader, but when I take the bootloader out of my code. The problem remains (but at 26% instead of 32%), so I do think it is not likely the bootloader gives the problem in the firstplace... |
|
|
Foppie
Joined: 16 Sep 2005
Posts: 138
Location: The Netherlands
|
|
| Posted: Tue Sep 27, 2005 7:18 am |
|
|
I managed to avoid the problem by adding to my code. But I don't like my solution.
It has risen only more questions...
Why can't the compiler handle my problem?
Do I need to define all memory addresses off my code in the future?
Why does #separate not work? if I put #seperate in place of the #org it still crashes... |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Tue Sep 27, 2005 8:00 am |
|
|
Are you doing anything in assembler? You might be messing up the processor paging or banking.
Are you modifying program memory?
Are you overrunning the stack?
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Foppie
Joined: 16 Sep 2005
Posts: 138
Location: The Netherlands
|
|
| Posted: Wed Sep 28, 2005 12:47 am |
|
|
| asmallri wrote: | | Are you doing anything in assembler? You might be messing up the processor paging or banking. |
No assembler code, only C...
| asmallri wrote: | | Are you modifying program memory? |
Not that I'm aware off... (I've not written any code to do so, but tthere is a bootloader in my code. But as I mentioned earlier, when I remove the bootloader the problem remains...)
| asmallri wrote: | | Are you overrunning the stack? |
Nope... |
|
|
Foppie
Joined: 16 Sep 2005
Posts: 138
Location: The Netherlands
|
|
| Posted: Wed Sep 28, 2005 6:47 am |
|
|
I encountered another similar problem in my code. I'm running out of RAM. Atleast I get the error message: "Not enough RAM for all variables" but my LST file tells me I only use 42% RAM in worst case.
I do use one array and want it to be 128 bytes but I can only make it 80 bytes big. When I make it between 80 and 90 bytes big, it gives an out of ROM  error message and when I make it even bigger I get an out of RAM error message.
What should I do to solve this problem, I do not know it anymore... |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Wed Sep 28, 2005 7:13 am |
|
|
Foppie wrote:
| Quote: |
"Not enough RAM for all variables" but my LST file tells me I only use 42% RAM in worst case.
|
Did you add *=16 to enable full RAM access ?
#include <16F877a.H>
#device *=16
Humberto
Last edited by Humberto on Thu Sep 29, 2005 8:15 am; edited 1 time in total |
|
|
Foppie
Joined: 16 Sep 2005
Posts: 138
Location: The Netherlands
|
|
| Posted: Wed Sep 28, 2005 7:22 am |
|
|
| Humberto wrote: | Foppie wrote:
| Quote: |
"Not enough RAM for all variables" but my LST file tells me I only use 42% RAM in worst case.
|
Did you add the #device preprocessor to enable full RAM access ?
#include <16F877a.H>
#device *=16
Humberto |
yes, here is a piece of my code, including my fuses. Is it correct?
| Code: | #device PIC16F877A *=16 ADC=10
#include <drivers/16F877A.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES HS //High speed Osc (> 4mhz)
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOLVP //Low Voltage Programming on B3
#FUSES NOCPD //No EE protection
#FUSES NOWRT //Program memory not write protected
#use delay(clock=20000000)
#use rs232(baud=9600, BRGH1OK, parity=n, bits=8, xmit=PIN_C6, rcv=PIN_C7, ERRORS, stream=UWEAVE) |
|
|
|
Foppie
Joined: 16 Sep 2005
Posts: 138
Location: The Netherlands
|
|
| Posted: Thu Sep 29, 2005 3:31 am |
|
|
could it be a problem with my compiler?
I did check the recent changes in versions but I didn't see it mentioning enything about my problem, that's why I didn't thought of it before.
I use: CCS PCM C Compiler, Version 3.087 |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Thu Sep 29, 2005 8:34 am |
|
|
mmmh... your problem is not visible for us if you only post the header.
Anyway, the CCS Compiler version you are using was released in 2001 and almost
all early 3.0xx versions were very unstable.
Most of us had been used those versions just to test and smell whats new, but the real
projects had being done with the old battle horse V2.748.
Humberto |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Thu Sep 29, 2005 12:44 pm |
|
|
Not me. 2 most recent projects are on 3.233
right, right,
3.0xx was a little flacky. But I have moved way past V2.748.
Last edited by treitmey on Thu Sep 29, 2005 3:23 pm; edited 4 times in total |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Thu Sep 29, 2005 1:53 pm |
|
|
@treitmey wrote:
| Quote: |
Not me. 2 most recient porjects are on 3.233
|
Hi treitmey, may be you miss understand me or I wasn�t clear enough, my reference
was for 3.0xx Versions NOT for 3.2xx
Humberto |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Sep 29, 2005 2:36 pm |
|
|
| Quote: | | I do use one array and want it to be 128 bytes but I can only make it 80 bytes big. |
You can't make an array larger than the PIC's largest RAM bank size
with CCS. Also, for PICs that have "common RAM" (accessible with
any bank setting), the compiler likes to reserve that area for its own use.
So for the 16F877A, the largest possible array size is 96 bytes.
If you have a lot of other variables, you may not have enough RAM
left to make a 96 byte array. The array must be contained within
one bank. It cannot span two or more banks. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
