CC2538: Debugging Memory Leak in ZNP / Z-Stack 3.0.1

Can you please review the Zigbee Known Issues and Proposed Fixes Wiki page? processors.wiki.ti.com/.../Zigbee_Known_Issues_and_Proposed_Fixes

You can also add the compile flag OSALMEM_METRICS = TRUE to your project for additional memory variables which are defined in OSAL_Memory.c and can be used to monitor your heap.

Regards,
Ryan

Hi,

In addition to OSALMEM_METRICS=TRUE, which can tell you the current and maximum size of your heap, we also have OSALMEM_PROFILER=TRUE, which fills your unallocated heap with a known value so you can closely monitor exactly what areas of memory are being used by using the IAR memory debug view, you can search for these compile flags throughout OSAL_Memory.c for implementation details.

Ryan,

Yes I have read that and applied all relevant patches.

Jason,

There is the possibility it's fragmentation and not a leak. It seems unlikely to me with a 6k (default) heap but I suppose it's possible.

What I've done for now is increase the heap to 22k (we have the 32k CC2538's). This should buy me some time to investigate those #defines For starters I''ll work on proving that restarting the linux side of the application causes it (as opposed to say time). Then trying to work out what size the allocation is that is building up I suppose.

My main suspect is the AF:deregister (we deregister the old apps endpoints and register the new on boot) or the restarting of coordinator mode.

Hi Mathew,

Do you have any updates to provide?

Regards,
Ryan

Ryan,

Not as of yet. Increasing the heap size has bought us enough maneuvering room for this months priorities. Tracking down the leak will take place as soon as we have some free time.

Currently our priority is solving the more critical e2e.ti.com/.../673996