CC2651R3: How do I enable HeapMem for Simple Off Chip OAD

Hi Brian,

Thank you for reaching out. Can you share the SDK version you are working on? Also, does this behavior happen on an unmodified example? Could you verify if you see it on a non-oad simple_peripheral as well? I would like to narrow down the possible causes of the potential leak.

Best Regards,

Jan

Hi Jan,

I updated to the latset SDK 7_10_02_23 and the good news is the behavior does not happen on the example SimplePeripheral_off_chip_oad.

Unfortunately, I am using a custom board with the external flash on different pins so it can still be something with the OAD.

I attached screenshots of the heap growing every time a device connects. Is it possible to use tools like HeapMem with BLE5stack? Is it possible to see what lines are allocating all of the unfreed memory?

Most of my app logic resides in a completely separate task, so I am going to start porting example code into sections of my application to see if I can find the problem. Any pointers for discovering the memory leak would be very appreciated.

Best,

Brian

Hi Jan,

I think the memory leak is from the OAD, maybe the OAD_Cancel() when devices disconnect. Maybe it is something to do with my custom external flash?

In my application I have a define that disables OAD, when I disable OAD the memory leak goes away. The define disables the OAD_open on init, the OAD callbacks, and the OAD_Cancel() on disconnect.

Any thoughts on this? I will keep diving into the OAD to see what is causing the memory leak.

Best,

Brian

Edit: The memory leak still occurs with OAD disabled but it takes many more connect and disconnects. 11 now instead of 4

Hi Brian, 

Thanks for providing these updates! It is possible that the issue you are seeing is due to the external custom flash but I am not certain. Have you attempted to recreate the issue on a launchpad as opposed to your custom board?

I can work to do this on my end as well to see if I run into the same memory leak in the meantime. 

Best regards,

Luke

Hi Luke,

The documentation says that HeapMem / Heaptrack should be available for BLE debugging. Is this outdated? I can’t get heapmem to work for any of the non-altered examples.

Are there other ways to look at what is all the unfree memory?

The leak seems to be something to do with my BLE service profiles. When I disable them it goes away. But the leak is occurring with just connecting, not interacting with the services. I’ll try to port one of my services to launchpad example code and see if it still occurs.

Best,

Brian

Hi Brian,

Could you provide a link to the documentation you are referencing so I can take a look to make sure you are not using an outdated version or so I can report any issues to our internal team?

You can utilize UniFlash and its 'Memory Browser' to look at the unfree memory.

Please keep me updated once you finish porting over to the example code and whether the issue persists!

Best regards,

Luke

Hi Luke,

Sorry for the delayed response I was traveling last week. No worries if the documentation is dated, I will try looking at the Memory Browser.

For the documentation, in BLE5Stack -> Debugging Common Heap Problems -> Troubleshooting heap problems

https://dev.ti.com/tirex/explore/node?node=A__AHaph7YfvcrVy2cDlmb4sQ__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK__BSEc4rl__LATEST (cntrl-f for "trouble shooting heap problems" on the "BLE5 User Guide" will find it)

Best,

Brian

I used the memory browser, here is what i see at the heapEnd after 6 connections and resources are full. How do I tell what this memory is pointing to?

Brian,

Thanks for sharing the documentation you were using! It looks like you were using the most recent documentation so no issue there. 

Let me take a look at the memory you included here and talk with an expert on my team and get back to you shortly to clarify the understanding of what we are seeing.

Best regards,
Luke