Memory Leak in Connection Parameters Negotiation module

[ArmatureCurrent]

Good day!

In my BLE project I use connection parameters negotiation module. In order to ensure software consistency there is a test for memory leakage. After some investigations I've found, that function

ret_code_t ble_conn_params_init(const ble_conn_params_init_t * p_init)

invokes API to create a timer. In case of using, for example FreeRTOS portable API, it leads to software timer creation. It's inherent to use dynamic memory allocation in these process, but there is no any method to deallocate memory back to the heap. In accordance with documentation, there is a function:

ret_code_t ble_conn_params_stop(void)

that "must be called when the application is disabling the SoftDevice or the application does not want the parameters to be negotiated any longer. This must be called to ensure the timers used by the library are not longer active."

But, it doesn't free memory allocated for software timer as it is expected. It's not huge amount of memory to carry about due to it's directly dependence on SDK configuration parameter:

NRF_SDH_BLE_PERIPHERAL_LINK_COUNT

However, the test fails and it wouldn't be acceptable to ignore memory leak even that we really know what is the matter of fail. I can suggest to use for example FreeRTOS macros:

#define xTimerDelete( xTimer, xTicksToWait ) xTimerGenericCommand( ( xTimer ), tmrCOMMAND_DELETE, 0U, NULL, ( xTicksToWait ) )

But this solution has to be placed in SDK software somehow in order to save encapsulation level. My clients rejected it due to in case of next SDK upgrades it would become un-managable.

So, the question is: Could we expect in upcoming upgrades any modifications in software timers management in order to eliminate memory leaks?

[Einar Thorsrud]

Hi,

The normal (non-FreeRTOS) app-timer implementation relies entirely on static memory. As you have commented, this is not the case for the FreeRTOS implementation since it use xTimerCreate(). However, I do not see this as a memory leak as the higher level app-timer API still treats this conceptually as a static allocation with the number of instances is fixed by the configuration define. And equally important: there is no app-timer API to tear down a timer once it has been created, so there is no reason to think that the memory should be freed at any point.

If you want to change this behavior properly, then you need to expand the app-timer API with a teardown function. Alternatively you could replace the call to xTimerCreate() with xTimerCreateStatic(). I do not see a significant benefit of it, though. I have created an internal ticket for this, but you should not probably expect this to be added in the next nRF5 SDK release (you are of course free to implement it yourself if you like).

[ArmatureCurrent]

Thanks for your answer