Hi.
I'm working on implementing firmware for a device that uses observer role to get sensor data and cache it. It also uses the peripheral role to send collected data to the phone when it's available. Because It's not possible to run a scan and advertise (required for a phone to connect) at the same time the code was implemented to switch between this functions periodically. I've noticed that after a few connect/disconnect events gScanCommandFailed_c/gAdvertisingCommandFailed_c are generated. After some time I've found that this happens due to 100% usage of the heap (MemManager). I've activated the MEM_STATISTICS/MEM_TRACKING/MEM_DEBUG_OUT_OF_MEMORY capabilities and reproduce this issues. MEM_TRACKING reports that most memory is used by:
allocAdr - 0x37843 <L2ca_HciEventCallback+14>
pCaller - 0x298e9 <Ble_HciRecv+780>
Unfortunately, these functions are in the pre-compiled libraries.
Any ideas how to fix it?
The second issue is related to whitelist: It's not possible to connect to the device the second time (I assume that pair/bond was done during first connection ) if the `gAdvParams.filterPolicy = gProcessWhiteListOnly_c;` is used. I've tested on three different example projects from the SDK (I've enabled paring/bonding for them in the app_preinclude.h). I've checked that IRK is distributed from the phone.
SDK: SDK_2.2_QN908xCDK_Beta
IDE: mcuxpressoide-10.0.2_411
System : Ubuntu 16.04
P.S: I've found a few issues with SDK, but they are not critical for me :
Regards,
Max.
HI,
About the memory leak issue - it seems that it happens every time when android opens
> android.bluetooth.BluetoothDevice.connectGatt(Context context, boolean autoConnect, BluetoothGattCallback callback)
when another instance is already active.
FYI: One more issue that was resolved - default example of OTA update calls `OTA_CommitImage(uint8_t* pBitmap)` with bitmap equal to erase all storage. This erases all storage corresponded to NVM module including pairing\bonding information.
Hello Max,
The memory leak should now be fixed with the RFP (Ready for Production) build of the QN9080 SDK.
Let me know if you still have issues with this version of the SDK.
Regards,
Gerardo
Hello Max,
Thanks for letting us know about this issues, I will try to replicate and report them to the SW team so a fix can be pushed to the next release of the QN9080 SDK.
Regards,
Gerardo
Hi,
Thanks for the info. Any ideas when the new release will be available?
FYI: It seems that FLASH_VerifyErase is not implemented in the SDK. It may be the root cause of the failed Flash init mentioned in the release notes.
Regards,
Max.