Jump to content
Sign in to follow this  
danutz

Wrong Memory Usage Report

Recommended Posts

SourceBoost 6.60

Compiler - BoostC

Target - PIC16F767

 

The linker's memory usage report is incorrect.

It seems to consider the last memory location occupied, which is not correct if there are holes in the code memory (for example, by putting data at the end of code memory space).

 

The following code will reproduce the problem:

 

#include <system.h>

 

#pragma DATA 0x1500, 1

 

int main()

{

while(1)

{

}

return 0;

}

 

Memory Usage Report

===================

RAM available:368 bytes, used:3 bytes (0.9%), free:365 bytes (99.1%),

Heap size:365 bytes, Heap max single alloc:111 bytes

ROM available:8192 words, used:5377 words (65.7%), free:2815 words (34.3%)

 

Dan

Share this post


Link to post
Share on other sites

Hi,

 

I also seem to have this same problem. Few time already, the memory usage can suddenly reduce. I expect the memory usage to go up after I added more codes into the project.

 

SourceBoost 6.60

Compiler - BoostC

Target - PIC16F877A

 

Memory Usage Report

===================

RAM available:368 bytes, used:239 bytes (65.0%), free:129 bytes (35.0%),

Heap size:129 bytes, Heap max single alloc:95 bytes

ROM available:8192 words, used:7431 words (90.8%), free:761 words (9.2%) <-- Just a while ago it reported that I only had 5.2% free words.

 

Previously, I had the same problem too when my memory usage also reduced from 15% to 20% free. During that time I thought I saw it wrongly. But now happened again.

 

Now I am thinking if this is the problem that caused my thing to go wild now. :D

 

Br,

John

Share this post


Link to post
Share on other sites

jcding,

I also seem to have this same problem. Few time already, the memory usage can suddenly reduce. I expect the memory usage to go up after I added more codes into the project.

 

SourceBoost 6.60

Compiler - BoostC

Target - PIC16F877A

 

Memory Usage Report

===================

RAM available:368 bytes, used:239 bytes (65.0%), free:129 bytes (35.0%),

Heap size:129 bytes, Heap max single alloc:95 bytes

ROM available:8192 words, used:7431 words (90.8%), free:761 words (9.2%) <-- Just a while ago it reported that I only had 5.2% free words.

 

Previously, I had the same problem too when my memory usage also reduced from 15% to 20% free. During that time I thought I saw it wrongly. But now happened again.

This is a different issue.

Its quite possible that as variables and code is added the placement of variables and code in memory changes and results in less code being required (less bank switching and code page crossing instructions required).

 

If you can provide a project that does this I would be interested to look at it.

Send it to support@sourceboost.com.

 

Now I am thinking if this is the problem that caused my thing to go wild now. 
This is possible but highly unlikely :D

 

Regards

Dave

Share this post


Link to post
Share on other sites

How does the linker calculate the used/unused space?

From the last used block or is it smart enough to count all the holes

in between?

 

If its from the last used block then anytime you assign a specific location

you will not get a correct unused memory reading.

Share this post


Link to post
Share on other sites
How does the linker calculate the used/unused space?

From the last used block or is it smart enough to count all the holes

in between?

Currently there are no gaps left, so it goes by the last location used.

 

I'm looking into improving this.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Hi Dave,

 

Thanks for your reply.

 

Its quite possible that as variables and code is added the placement of variables and code in memory changes and results in less code being required (less bank switching and code page crossing instructions required).

You are right about this. When I try to see the difference between the assembly code generated between the latest codes and the older codes, a lot of bank switching for the variables are removed. This justifies why the memory usage reduced. ;)

 

However, regarding the problem I had earlier, I found out that there is some problem with the C compiler. I gave the example as below.

 

//main.c file

...

..

while (1) //Program memory address:1992

{

if ( A )

{

}

else if ( B )

{

}

else if ( C )

{

}

else if ( D )

{

}

else if ( E )

{

}

else if ( F )

{

}

}

//After i added in "else if ( F )" conditions, my thing won't work. It will hang when the (F) condition is hit.

 

So i rearrange the conditions as follows:

..

..

while (1) //Program Memory address:1992

{

if ( E )

{

}

else if ( F )

{

}

else if ( A )

{

}

else if ( B )

{

}

else if ( C )

{

}

else if ( D )

{

}

}

//Now my thing working fine again. All conditions are tested OK. I suspect there is some program memory page crossing problem here. Please check if this is really a C compiler bug or just my silly mistake.

 

Thanks.

 

Best regards,

John

Share this post


Link to post
Share on other sites
However, regarding the problem I had earlier, I found out that there is some problem with the C compiler. I gave the example as below.

 

//main.c file

...

....

 

Now my thing working fine again. All conditions are tested OK. I suspect there is some program memory page crossing problem here. Please check if this is really a C compiler bug or just my silly mistake.

Please provide a sample project that causes the issue so we can investigate. Zip it and send it to support@sourceboost.com

 

Regards

Dave

Share this post


Link to post
Share on other sites

Fixed in BoostC V6.70

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

×
×
  • Create New...