AnsweredAssumed Answered

Current heap pointer monitoring on MCUXpresso

Question asked by Stefano Di Maio on Jan 30, 2018
Latest reply on Feb 9, 2018 by LPCX presso support

Like • Show 0 Likes0
Comment • 12

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

No one else has this question

Outcomes

12 Replies

LPCX presso support Jan 31, 2018 8:23 AM
Mark Correct
Correct Answer
You should be able to monitor the "__end_of_heap" variable.

Regards,
MCUXpresso IDE Support
Like • Show 0 Likes0
Actions
- Stefano Di Maio @ LPCX presso support on Jan 31, 2018 8:47 AM
  Mark Correct
  Correct Answer
  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.
  Like • Show 0 Likes0
  Actions
  - LPCX presso support @ Stefano Di Maio on Jan 31, 2018 8:59 AM
    Mark Correct
    Correct Answer
    _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
    Like • Show 0 Likes0
    Actions
    - Stefano Di Maio @ LPCX presso support on Jan 31, 2018 10:07 AM
      Mark Correct
      Correct Answer
      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
      Like • Show 0 Likes0
      Actions
      - Con Verse @ Stefano Di Maio on Feb 3, 2018 10:01 AM
        Mark Correct
        Correct Answer
        I suspect that __end_of_heap s a pointer. The value displayed above 268439552 is actually 0x10001000...
        Like • Show 0 Likes0
        Actions
        Stefano Di Maio @ Con Verse on Feb 5, 2018 9:15 AM
        Mark Correct
        Correct Answer
        Yes. The problem is that the __end_of_heap doesn't change after the memory allocation as expected.
        Like • Show 0 Likes0
        Actions
LPCX presso support Feb 3, 2018 9:40 AM
Mark Correct
Correct Answer
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
Like • Show 0 Likes0
Actions
- Stefano Di Maio @ LPCX presso support on Feb 5, 2018 9:15 AM
  Mark Correct
  Correct Answer
  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
  Like • Show 0 Likes0
  Actions
LPCX presso support Feb 5, 2018 10:26 AM
Mark Correct
Correct Answer
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: Heap allocation/checking in Redlib ). 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
Like • Show 0 Likes0
Actions
- Stefano Di Maio @ LPCX presso support on Feb 6, 2018 2:38 AM
  Mark Correct
  Correct Answer
  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
  Attachments
  - ArchiveFileLPC4088TEST.zip4.3 MB
  Like • Show 0 Likes0
  Actions
  - Emilio Brivio @ Stefano Di Maio on Feb 9, 2018 4:32 AM
    Mark Correct
    Correct Answer
    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.
    Attachments
    TestMCUEXK22HEAP.zip2.2 MB
    Like • Show 0 Likes0
    Actions
LPCX presso support Feb 9, 2018 6:42 AM
Mark Correct
Correct Answer
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 Emilio Brivio, 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
Like • Show 0 Likes0
Actions

Incoming Links

Re: Heap usage in MCUXpresso

Current heap pointer monitoring on MCUXpresso

Outcomes

Attachments

Attachments

Related Content

Recommended Content

Incoming Links