Current heap pointer monitoring on MCUXpresso

[dimaios]

Dear Sirs,

                I've a problem concerning the heap pointer monitoring.

CONFIGURATION :

1. MCUXpresso

2. MCU NXP 4078

3. C++ 11.0 and STL

Declaring variables in this way :

register void * stack_ptr asm ("sp");
extern char _pvHeapLimit __attribute__((weak));
extern char _pvHeapStart __attribute__((weak));

I can read the heap Limit and Start  but I cannot monitor the current heap pointer position.

I've read about the function unsigned __check_heap_overflow (void * new_end_of_heap) in the file

_cr_check_heap.c but is not what I'm looking for because it's a "manual" check.

Is it possible to verify the current heap pointer value by reading some variable like _pvHeapLimit ?

What's the right procedure to monitor the heap while allocating C++ STL object memory ( not by using "C" malloc )?

Best regards

[lpcxpresso_supp]

OK, I think I understand the confusion here.

__end_of_heap indicates the current end of the heap - but this includes any last block that has been free'd. In other words it effectively provides the maximal extent of the the heap so far, not the end of the currently "active" last block.

In the K22 example posted above by  EmilioBrivio‌, the code first of all calls printf - which causes a small amount of heap space to be grabbed (to hold the character string that is then passed out to the debugger console over semihosting, as one block). At the end of printf, that heap space is free'd. But __end_of_heap stays pointing to the maximum extent of the heap so far.

Then when the example code tries to grab just a few characters worth of heap space, this heap request can be fulfilled using the free'd block. So there is no need to extend the heap further.

If you try grabbing making additional or larger calls into malloc(), you will see __end_of_heap does then increase.

We'll look at improving the IDE documentation for a future release to encompass the above details.

Regards,

MCUXpresso IDE Support

[lpcxpresso_supp]

The behaviour of the " __end_of_heap" variable has not changed for some considerable time (certainly what I wrote should have worked in LPCXpresso IDE v8.2.2, though older versions differed - as per the old LPCXpresso IDE FAQ at: https://community.nxp.com/message/630622 ). So what you say makes little sense, certainly if you are using MCUXpresso IDE.

Again, please post an example project, or at least your map file. Certainly the code snippet I posted previously seemed to work as expected here.

Regards,

MCUXpresso IDE Support

[dimaios]

So what you say makes little sense, certainly if you are using MCUXpresso IDE

I agree with you but the sample code works after the complete cleaning of all IDEs/drivers and fresh installation of the last MCUXpresso.

The project I've attached seems to work after IDE re-installation ( __end_of_heap changes according to the dynamic memory allocation ).

I cannot roll back the previous PC configuration but my colleagues have a similar problem so I'm looking for a configuration that shows the problem.

Here is a picture about the debug on my PC.

Best regards

[EmilioBrivio]

Dear all,

I've the same situation using MCUXPRESSO latest version 10.1.1 and  K22 with a FRDM board.

Here below the project.

Emilio.

[lpcxpresso_supp]

Can you export and post an example project that shows up your problem? Or else, please at least post the .map file generated by the linker when you build your project.

Regards,

MCUXpresso IDE Support

[dimaios]

After several trials I've uninstalled the LPCXpresso and MCUXpresso version from PC also removing the JTAG interface drivers.

Reinstalling only the last version of the MCUXpresso and related drivers the code behaviour is completely different.

I suspect that there is some compatibility issue between the various IDE versions ( or programming interface drivers ).

I will post the results soon.

Thanks for you support.

Best regards

[lpcxpresso_supp]

You should be able to monitor the "__end_of_heap" variable.

Regards,

MCUXpresso IDE Support

[dimaios]

Thank you for your kind replay.

The variable you suggested has always the same value.

I don't know if the extern variables declaration is correct but the following code fragment shows that end_of_heap ( before malloc ) and new_end_of_heap ( after malloc ) have the same value.

register void * stack_ptr asm ("sp");extern char _pvHeapLimit __attribute__((weak));extern char _pvHeapStart __attribute__((weak));
extern char __end_of_heap __attribute__((weak));


....
....
....
    end_of_heap = (void* )& __end_of_heap;

    myBuffptr=(uint32_t*)malloc(20*sizeof(uint32_t));

    new_end_of_heap = (void* )&__end_of_heap;


...
...
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

What's wrong ?

Thanks in advance.

Best regards.

[lpcxpresso_supp]

_pvHeapStart/Limit are linker symbols rather than true variables, so are accessed differently.

Try using 

extern unsigned int __end_of_heap;

and accessing it thus:

end_of_heap = __end_of_heap;
myBuffptr=(uint32_t*)malloc(20*sizeof(uint32_t));
new_end_of_heap = __end_of_heap;

[or use the IDE's Live Variables view to see it updating as you run the application].

Regards,

MCUXpresso IDE Support

[dimaios]

I've changed the variable type according to your suggestion but the result is anyway wrong.

Before and after the check the __end_of_heap variable has the same value.

I don't understand why the __end_of_heap variable doesn't change according to the current heap pointer.

Any other suggestion ?

Thanks

[converse]

I suspect that __end_of_heap s a pointer. The value displayed above 268439552 is actually 0x10001000...

[dimaios]

Yes. The problem is that the __end_of_heap doesn't change after the memory allocation as expected.