Is there any way I can monitor the memeory usage of netburner? I actually use SB72 model. I am doing performace testing for my app. If there is some function call I can use to give me a summarise about the memory usage, it can be very useful to check memory leaking.
I actually found one fundtion "spaceleft()" at Bsp.h which looks like what I want, I tested it by allocating memory. It's woking.
But one thing is in one case, when I "new" and then "delete" one C++ construct, the space was not freed through checking the function call, but only once. At the moment, it's ok. I am not sure that was cause by my own fault or the system fault.
A Build Summary was added a few releases ago. If you don't see it, an upgrade is recommended.
In Eclipse, select the project in the ProjectExplorer or the C/C++Projects tab. Pull down the Project/Clean menu. Then look at the Console view for the build summary. If compilation completes successfully, the summary should look something like this depending on your project and platform: (this was for a Mod5282):
Block starts at 2000000
Block ends at 204c1f8
Block size= 304K
Execution starts at 2000000
compressed 311800 bytes into 183296 bytes
Code CheckSum= 572fefdc
Struct CheckSum= e71dd47a
S records output with a base address of ffc08000
S records output with a final address of ffc34c18
About to write S7...
******************************Build summary ******************************
Used 183320 bytes of 491520 available flash (37.30%)
Used 1029792 bytes of 8388608 available ram (12.28%)
NNDK release tag version:Rel24_rc2_L2eBeta
Build complete for project Your_Project_Name
Time consumed: 51969 ms.
Ridgeglider wrote:A Build Summary was added a few releases ago. If you don't see it, an upgrade is recommended.
In Eclipse, select the project in the ProjectExplorer or the C/C++Projects tab. Pull down the Project/Clean menu. Then look at the Console view for the build summary. If compilation completes successfully, the summary should look something like this depending on your project and platform: (this was for a Mod5282):
Block starts at 2000000
Block ends at 204c1f8
Block size= 304K
Execution starts at 2000000
compressed 311800 bytes into 183296 bytes
Code CheckSum= 572fefdc
Struct CheckSum= e71dd47a
S records output with a base address of ffc08000
S records output with a final address of ffc34c18
About to write S7...
******************************Build summary ******************************
Used 183320 bytes of 491520 available flash (37.30%)
Used 1029792 bytes of 8388608 available ram (12.28%)
NNDK release tag version:Rel24_rc2_L2eBeta
Build complete for project Your_Project_Name
Time consumed: 51969 ms.
Thanks for the information. May I didn't explain my intention clearly. I want to watch the memeory usage when my app is running, not only after compiling. I want to know whether or not there is any memeory leaking durng long-term running of my app. May spaceleft() work?
spaceleft just reports the amount of memory still available by the system for dynamic memory allocation, it doesn't help for anything else. I'm not sure about this system (because I try to avoid dynamic memory), but usually when you free memory the system will know the memory can be reused, but the system won't "deallocate" that memory. It will just leave the allocated memory pointer (that spaceleft uses) where it is and the next time your code calls a function that needs dynamic memory it will use the space that is already reserved. If your code needs more dynamic memory than it did before, the system will take more memory and spaceleft will reflects that. Its kind of like a high water mark. It will also allocate in some minimum block size, not just the bytes it needs.
So this covers dynamic memory, but if your leak or memory corruption has to do with a coding problem, this won't help at all. This is only good for a properly running system. If you did have a dynamic memory leak in your code, and you are checking all the return values, then you would see it that way too. But I would really try to avoid any dynamic memory usage if at all possible. There are so many different runtime issues that can crate a leak, and if a dynamic memory allocation fails on an embedded system with no video screen, what do you do?
Again, I'm hypothesizing based on other embedded systems where I had to write a spaceleft function and handle the allocation. I have not had to go that indepth with the netburner stuff, so please take this commentary as a possible answer.
If you have a memory leak, the memory for the task running the bad code will exceed the bounds of the alloted stack space. You can keep tabs on this usage in two ways:
(from a previous post by Paul:)
edit nburn\include\predef.h and uncomment
#define UCOS_STACKCHECK (1)
Recompile everything.
1)By using taskscan:
#include <taskmon.h>
EnableTaskMonitor();
Then use the taskscan application (see C:\Nburn\docs\NetBurnerPcTools\NetBurnerTools.pdf).
This will report the stack usage, current and max on a per task basis. If you creat the tasks using either:
OSTaskCreatewName() or OSSimpleTaskCreatewName(), the name of each task will also be reported.
By the way NB folks, neither OSTaskCreatewName, nor OSSimpleTaskCreatewName() are described in
C:\Nburn\docs\NetBurnerRuntimeLibrary\uCOSLibrary.pdf although there is an example in C:\nburn\examples\RTOS\OSFlags\main.cpp
2)The other choice is to call
void OSDumpTCBStacks( void );
(see "OSDumpTCBStacks" in C:\Nburn\docs\NetBurnerRuntimeLibrary\uCOSLibrary.pdf )
This prints out stack info to stdout.
Hello guys,