I'm running the SS1 Bluetopia stack on both the LM4F232H5QD and TM4C123G eval boards doing significant BLE traffic. I've found that after 30-60 minutes the Bluetopia stack suddenly runs out of memory, and all future allocations via BTPS_AllocateMemory() fail.
If I monitor memory usage by calling BTPS_QueryMemoryUsage(&used, &free, &maxfree); (which calls CalcTotals in BTPSKRNL.c) once a second, memory usage is flat after the connection is established. But at some point within 1-2 seconds all the remaining memory is consumed. If I dump the memory usage at that point all segments are consumed with what appears to be repeated small allocations, generally under 80 bytes. Yet, on subsequent failures the allocations are never the same size. For example they aren't always 14 bytes. One one failure they may be 14 bytes, on the next 50 bytes, etc.
If I look at what code is attempting to allocate memory, it's slightly difficult since it occurs within the Bluetopia library, forwhich I don't have symbols. But if I single step back to code I do have symbols for, then 2 main sources are:
My calls to:
GATT_Write_Without_Response_Request(BluetoothStackID, DeviceInfo->ConnectionID, handle, bytes, data);
and:
HCITRANS.c: (*_COMDataCallback)(TRANSPORT_ID, Count, &UartContext.RxBuffer[UartContext.RxOutIndex], _COMCallbackParameter);
I can't provide the application, but the SPP BLE sample app was the starting point. It was initially running on the msp430, then ported to the ARM chip.
I can describe what is going on:
Peripheral (cc2540) is connected with a connection interval of 10ms.
Host is receiving notifications at ~10-15Hz, each notification is up to 20 bytes.
Host is sending writes without response. There are approximately 25 sent once per second.
Peripheral at times may disconnect, and a new connection request is made immediately.
Any thought or suggestions are appreciated. The current work around for the problem is to reset the entire stack, which works, but is less than ideal and I would not want to ship a product with this bug.
