So I am using a K22F with 512K Flash and 128K RAM. Therefore, I have LOTS of RAM and should not in any way run out of RAM for the relatively little code I have developed so far, assuming the RAM space is adequately allocated.
Given that Processor Expert (PE) basically creates a main.c and you have a limited space to place your code, and my code is actually in C++, I make a call from main in the user section to a main.cpp that then instantiates all the C++ code, including prepping threads to execute once the OSA (FreeRTOS flavor) scheduler kicks in.
All of that has been running great. However, as I added a little more "meat" to some of the lower level classes, I began getting a trap in the new operator. Of course, you would suspect the new code, but the funny thing is that it allocates 4 classes before it barfs on the 5th one. It looks more like a possible memory allocation issue. Below is the code:
//--------------------
//Constructor
//--------------------
Model::Model()
{
//Provide access to the one instance
theModel_p = this;
//Allocate the hardware support
hw_p = new Hardware;
//Allocate the User Experience Managers
for(int i=0; i < cfg_numHeads; i++)
{
uxManagers_p[i] = new UxManager; //<---***Trap is here on 5th iteration***
}
//Allocate the System Status
sysStatus_p = new SysStatus;
//Allocate the communications
comms_p = new Comm;
}
Now, this whole problem got me to thinking about something. PE is running its init before my code even runs, so there could be some black magic going on there. However, I would assume that any classes that are instantiated before the scheduler runs come out of the general C/C++ heap. However, I would assume that any memory allocations, including the new operator, will come out of the allocated FreeRTOS heap when executed from a thread. The begs the question:
Should I continue to allocate my classes and OS elements prior to starting the OSA scheduler, or should I kick of a start up thread that then goes and instantiates all the classes from the FreeRTOS heap?
Given my understanding that the new operator was not running out of the FreeRTOS heap I am not surprised, but bumping up the FreeRTOS heap allocation did nothing to address my issue.
For what it's worth, here is the call stack when the trap fires:
Any thoughts or insights would be most appreciated. Perhaps I simply need to increase the amount of data allocated to the C/C++ heap if anyone knows where to change that? I was up late working on this and I am not looking forward to pulling my hair out all afternoon this fine Sunday. Rest assured, I will be Googling this ad infinitum, but wanted to put this out, especially before our dear friends in Europe went to bed.
"I'm taking what they're giving 'cause I'm working through the weekend."
