topic Re: Trap on operator new: Thoughts and Questions... in Kinetis Design Studio

Trap on operator new: Thoughts and Questions...

tharonhall — Sun, 25 Jan 2015 20:11:16 GMT

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."

Re: Trap on operator new: Thoughts and Questions...

tharonhall — Sun, 25 Jan 2015 20:43:54 GMT

OK, so HEAP_SIZE in ProcessorExpert.ld is only 0x0400! OUCH!

But of course, that is an auto-generated file. If only I can figure out HOW to change that somewhere in PE? Still looking...

Re: Trap on operator new: Thoughts and Questions...

tharonhall — Sun, 25 Jan 2015 21:02:46 GMT

Bingo! Under Processors in PE Panel select the CPU, then Component Inspector, Build Options tab, then the Generate linker file tab. :smileyhappy:

However, the code is trapping in exactly the same way even though I tripled the stack size and increased the heap size by several times. :smileysad:

Any thoughts on another approach to debugging this? Is there a compelling argument for doing this using from within an OSA/FreeRTOS thread instead and using the OS heap?

???- Any tricks to knowing exactly what the new operator is barfing on? Since that is in a library, I don't know that I have visibility into what is going on there. :smileysad:

Re: Trap on operator new: Thoughts and Questions...

tharonhall — Sun, 25 Jan 2015 21:18:50 GMT

OK! Finally. It looks like in my effort to address the problem initially, I upped the OSA/FreeRTOS heap without also upping the linker heap. Therefore, there really wasn't enough memory for FreeRTOS to pull it's own heap from the general heap. :smileyhappy: While the small-ish heap may have been the initial heap, not increasing the C heap along with the FreeRTOS heap probably prolonged the pain. :smileysad:

??? - Now if anyone has a compelling reason to consider instantiating my classes from OSA/FreeRTOS's heap from a startup thread, vs. doing it initially using the C heap, I am all ears. Perhaps debugging this issue would have been better, for example? I don't necessarily want to create another thread if there is no compelling reason to otherwise.

Thanks!

Re: Trap on operator new: Thoughts and Questions...

tharonhall — Sun, 25 Jan 2015 22:14:31 GMT

I guess I am the only person working on Sunday, so it looks like I am talking to myself. :smileywink:

So as I think about it, it probably doesn't matter whether or not the new operator is used from within a thread or not, since it will go to the same library regardless, correct? I can't see the OS creating some kind of hook to redirect the operation to its heap, or am I missing something?

I have my code working now but ultimately need to tune my memory allocations to match my usage.