 |
 |
| View previous topic :: View next topic |
| Author |
Message |
vsmguy
Joined: 13 Jan 2007
Posts: 91
|
| [BUG] Buggy behaviour of the CCS compiler. |
 Posted: Sun Aug 16, 2009 12:23 pm |
 |
|
I am noticing an unusual behaviour of the CCS compiler.
The scenario is such:
1. I have a large fixed size array (more than what can be accomodated in PIC ROM)
2. I ask CCS to save these arrays in ROM
3. CCS does that WITHOUT complaining and in fact, telling me that I am using ~16% (this can change to 77% as one changes the contents of the fixed size array!)
4. The hex file that it generates has truncated information/data from the arrays .
For example, consider the code:
| Code: |
#include <18F2550.h>
/* 32k Flash; 2k SRAM; 256byte EEPROM */
#fuses INTRC, NOWDT, PUT, BROWNOUT, NOLVP
#device CONST=ROM
#use delay(clock=8000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
#include <stdlib.h>
#include "array.h"
void main()
{
unsigned int16 dz = 0, dy = 0;
//unsigned int16 dz = sizeof(bigArray), dy = 0;
const char *ptr = NULL;
//const char *ptr = bigArray;
setup_oscillator(OSC_8MHZ | OSC_INTRC); // 90% precision or 98%?
ptr = bigArray; //
dz = sizeof(bigArray); //
printf("\r\nSize = %Lu bytes. Dump follows\r\n{", dz);
for(dy = 0; dy < dz; ++dy)
{
printf("0x%X", ptr[dy]);
if(0x7 == (dy & 0x7)) printf("\r\n");
printf(",");
}
printf("\b\r\n};\r\nDone.");
while(1);
}
|
Contents of array.h : [http://sites.google.com/site/vimalsshankar/ccs]
Array.h exceeds 65536 bytes starting at end of line number 8199.
Thus on line number 8200 of array.h (that means the 65537th byte onwards) I have put a special value, to serve as a marker:
| Code: | | 0xDE,0xAD,0xBE,0xEF,0xAD,0xAD,0xAD,0xAD |
This line does not appear anywhere else in the array.
When I capture the output of the program, I see, what seems like
a. CCS assumes arrays cannot be > 65536 bytes long (it does not warn the user if that happens)
b. it shows AND writes only the residual value over and above the 65536 boundary
So in effect, after the first 65536 bytes of my array were written out, CCS went to index 0 and overwrote all the existing values from then on till the original array contents were exhausted.
Hence, the first few bytes of the array that is finally written out into the hex file is
| Code: | | 0xDE,0xAD,0xBE,0xEF,0xAD,0xAD,0xAD,0xAD |
As you can see, since my array is 70008 bytes long, CCS essentially wrote (70008 - 65536) = 4472 bytes
This "wrap around" behaviour does not seem to be documented anywhere, NOR does the compiler warn/complain/blowup saying that I am trying to be insane.
Another behaviour that was noticed is, in this scenario, even if I keep the size of the array fixed, just by changing the array contents/elements, the % used ROM fluctuates widly! A "compression" anomaly?
I will document this "compression" anomaly later, but right now, I would like to know how to get around the first issue (array truncation) without writing my own tool to keep track of the array size!
Bug report filed with ID : {9H4136}
Last edited by vsmguy on Sun Aug 23, 2009 8:00 pm; edited 1 time in total |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Aug 16, 2009 12:59 pm |
|
|
| It's a bug. Report it. (But a lot more briefly than you did here). |
|
|
vsmguy
Joined: 13 Jan 2007
Posts: 91
|
|
| Posted: Sun Aug 16, 2009 6:20 pm |
|
|
Report filed.
Any suggestions how I can get around this for the time being? (Except a separate compiler/assembly) |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Aug 16, 2009 6:31 pm |
|
|
I'm not sure what you mean by a work-around. The solution would be
to use an array that fits into the available ROM space of the PIC. |
|
|
vsmguy
Joined: 13 Jan 2007
Posts: 91
|
|
| Posted: Sun Aug 16, 2009 7:00 pm |
|
|
Yes .. how do I understand how much I can fit in?
Do I create an empty array first and see the compiler diagnostics file to see how much memory is left and then fill in the real data accordingly? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Aug 16, 2009 9:29 pm |
|
|
You can compile it with a small array and look at the number of bytes
of ROM that are used, given at the top of the .LST file. Subtract that from
the total ROM size of the PIC, and that will give you approximately the
number of bytes that you can add to the array size. |
|
|
vsmguy
Joined: 13 Jan 2007
Posts: 91
|
|
| Posted: Sun Aug 23, 2009 8:02 pm |
|
|
That's exactly what I am doing!
Am I doing things the wrong way or have other people been bitten by this bug before? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Aug 23, 2009 8:17 pm |
|
|
Most programmers note the size of the ROM available in the PIC from
the data sheet. They don't attempt to create a 'const' array that's larger
than the PIC can hold. So while it's a bug, it's a minor bug. Most people
don't get hit by it. |
|
|
|
|
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
