CC1312R: Heap Track

Hi Elin,

Thanks for your reply. Yes, checking the .map file would tell me the amount of RAM that has been allocated to the heap. It's the amount of RAM left over after the static allocations have been made. However, I'm trying to obtain the amount of heap memory used or available as my projects mallocs and frees memory. The main purpose of this is that I have implemented fragmented data messages which are saved using malloc which saves to the heap memory. Together with this, I'm attempting to increase the number of child devices the Collector can have up from 50. To get an idea of the maximum possible (with some headroom) it would be great to know what percentage of heap memory has been used. I suppose the maximum ever allocated would be ideal. Then I can run my system on long-term test and monitor heap resources.

I've tried with no success to use heap stats and am starting to come to the conclusion it is not possible. I would need to use a different heap manager with tracking but a simple switch to this (0x82) in app.cfg causes the IAR compiler to halt at the app.cfg file.

Going forward, do I need to set 0x82 in app.cfg? And if so, what are the consequences of changing the heap manager?

Many thanks,

Andy

Hi,

I have created a completely fresh Collector project in IAR which has not been modified in any way. The good news is that I get the same errors as my own heavily modified project, so it looks like I haven't done anything to stop MEAPMGR_METRICS working. The bad news is that I still get errors.

It seems that rtos_heaposal.h needs including into the project so I can use HEAPMGR_GETMETRICS();

However, including directly causes a lot of compilation problems.

What I need to understand is:

1) Is HEAPMGR_METRICS compatible with 0x80 = osal Heap manager as set in app.cfg?

* The heap manager to use is selected by setting HEAPMGR_CONFIG to the corresponding value (see below)
* 0 = osal Heap manager, size is static.
* 0x80 = osal Heap manager, with auto-size: The remainning RAM (not used by the system) will be fully assign to the Heap.
* 1 = HeapMem with Static size
* 0x81 = HeapMem with auto-size. The remainning RAM (not used by the system) will be fully assign to the Heap.
* 2 = HeapTrack (with HeapMem) with fixe size
* 0x82 = HeapTrack (with HeapMem) with auto-size: The remainning RAM (not used by the system) will be fully assign to the Heap.

This snippet taken from osal_port.c seems to suggest so (line 51 here), but osal_port.c does not seem to be used in my project.

/***** Private function definitions *****/

// DMM currently uses ICall Heap
#ifdef USE_DMM
extern void *ICall_heapMalloc(uint32_t size);
extern void *ICall_heapRealloc(void *blk, uint32_t size);
extern void ICall_heapFree(void *blk);

#define OsalPort_heapMalloc ICall_heapMalloc
#define OsalPort_heapRealloc ICall_heapRealloc
#define OsalPort_heapFree ICall_heapFree
#else
/***** Public function definitions *****/
/* Implementing a simple heap using heapmgr.h template.
* This simple heap depends on critical section implementation
* and hence the template is used after critical section definition. */
static void *OsalPort_heapMalloc(uint32_t size);
static void *OsalPort_heapRealloc(void *blk, uint32_t size);
static void OsalPort_heapFree(void *blk);

#define HEAPMGR_INIT OsalPort_heapInit
#define HEAPMGR_MALLOC OsalPort_heapMalloc
#define HEAPMGR_FREE OsalPort_heapFree
#define HEAPMGR_REALLOC OsalPort_heapRealloc
#define HEAPMGR_GETSTATS OsalPort_heapGetStats
#define HEAPMGR_MALLOC_LIMITED OsalPort_heapMallocLimited

#ifdef HEAPMGR_METRICS
void OsalPort_heapMgrGetMetrics(uint32_t *pBlkMax,
uint32_t *pBlkCnt,
uint32_t *pBlkFree,
uint32_t *pMemAlo,
uint32_t *pMemMax,
uint32_t *pMemUB);

#define HEAPMGR_GETMETRICS OsalPort_heapMgrGetMetrics
#endif

#define HEAPMGR_LOCK() \
do { OsalPort_heapCSState = OsalPort_enterCS(); } while (0)
#define HEAPMGR_UNLOCK() \
do { OsalPort_leaveCS(OsalPort_heapCSState); } while (0)
#define HEAPMGR_IMPL_INIT()

/* Note that a static variable can be used to contain critical section
* state since heapmgr.h template ensures that there is no nested
* lock call. */
static uint32_t OsalPort_heapCSState;

#if defined(HEAPMGR_CONFIG) && ((HEAPMGR_CONFIG == 0) || (HEAPMGR_CONFIG == 0x80))
#include <rtos_heaposal.h>
#elif defined(HEAPMGR_CONFIG) && ( (HEAPMGR_CONFIG == 1) || (HEAPMGR_CONFIG == 0x81))
#include <rtos_heapmem.h>
#elif defined(HEAPMGR_CONFIG) && ( (HEAPMGR_CONFIG == 2) || (HEAPMGR_CONFIG == 0x82))
#include <rtos_heaptrack.h>
#else
#include <rtos_heaposal.h>
#endif
#endif // USE_DMM

2) What files are being used for heap management? I'm confused between rtos_heaposal.h, icall.c and osal_port.c. How do these files relate to my project? What is osal_port? Is icall deprecated?

Sorry about all the questions, but I think understanding the file structure here will help me to get heap stats working.

Many thanks,

Andy

Hi Andy, 

Thanks for your patience, I'll look into this and get back to you as soon as possible. Please note that I'm out on vacation next week so expect a response within two weeks. 

Thanks, 
Elin 

Hi,

Is there any news on this? I could really do with getting this working.

For your web guys: I replied to this message in 'Activity' after clicking on 'My Profile'. Every time I hit return while typing it published the reply and went a bit strange.

Regards,

Andy

Thanks for this. I'm trying now and will post back.

Hi Elin,

I have two questions, please see 5) & 6) below.

I have heap metrics working which I'm very happy about so thank you. Some points which may help others, although this is on a modified non-standard collector project, it may still apply to the standard version:

1) I had to also include util_timer.c

2) I was using SysConfig 1.6.0 which didn't have the option of disabling generated files, so I updated to 1.8.0.

3) I removed the declaration of from osal_port.c and moved it to osal_port.h:

#ifdef HEAPMGR_METRICS
void OsalPort_heapMgrGetMetrics(uint32_t *pBlkMax,
                             uint32_t *pBlkCnt,
                             uint32_t *pBlkFree,
                             uint32_t *pMemAlo,
                             uint32_t *pMemMax,
                             uint32_t *pMemUB);

#define HEAPMGR_GETMETRICS      OsalPort_heapMgrGetMetrics
#endif

then added #include osal_port.h to my file where I needed the heap metrics. I suppose I could have used 'extern' instead.

4) This is how I call the metrics function:

/**
 * @brief   obtain heap usage metrics
 * @param   pBlkMax   pointer to a variable to store max cnt of all blocks ever seen at once
 * @param   pBlkCnt   pointer to a variable to store current cnt of all blocks
 * @param   pBlkFree  pointer to a variable to store current cnt of free blocks
 * @param   pMemAlo   pointer to a variable to store current total memory allocated
 * @param   pMemMax   pointer to a variable to store max total memory ever allocated at once
 * @param   pMemUB    pointer to a variable to store the upper bound of memory usage
 */
    
     uint32_t BlkMax;
     uint32_t BlkCnt;
     uint32_t BlkFree;
     uint32_t MemAlo;
     uint32_t MemMax;
     uint32_t MemUB;
    
     HEAPMGR_GETMETRICS(&BlkMax, &BlkCnt, &BlkFree, &MemAlo, &MemMax, &MemUB);

5) I have an issue with my network I'm trying to track down and getting heap metrics working will help a lot. However, in getting it working I realised that due to migrating stack versions the .syscfg file still referenced an old stack:

/**
 * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
 * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
 * @cliArgs --board "/ti/boards/CC1312R1_LAUNCHXL" --product "simplelink_cc13x2_26x2_sdk@4.10.00.78"
 * @versions {"data":"2021031521","timestamp":"2021031521","tool":"1.8.0+1863","templates":null}
 */

I have changed the version to the stack I'm using, but my question is will this affect anything and could there be issues because of this?

6) In a similar way to 5) could upgrading SysConfig from 1.6.0 to 1.8.0 make any difference to my network or is the change purely in the GUI?

Many thanks,

Andy