Thank you again for your prompt assistance, Remi. If I may, I'd like to suggest to document this limitation in a more visible fashion, rather than the release notes of the firmware file. I believe this is a serious limitation of the ST stack at this point, and knowing this limitation in advance, before committing to the ecosystem saves a lot of headache and frustration for your customers.
In addition, I'd suggest some changes in the example codes and the BLE boilerplate code generated by CubeMX:
- In app_conf.h, the CFG_BLE_NUM_LINK variable and its description might be misleading:
/******************************************************************************
* BLE Stack
******************************************************************************/
/**
* Maximum number of simultaneous connections that the device will support.
* Valid values are from 1 to 8
*/
#define CFG_BLE_NUM_LINK 8
- In app_ble.c, the Adv_Request() function swallows the return value of aci_gap_set_discoverable(), hiding the fact that the advertisement actually fails.
static void Adv_Request(APP_BLE_ConnStatus_t New_Status)
{
tBleStatus ret = BLE_STATUS_INVALID_PARAMS;
BleApplicationContext.Device_Connection_Status = New_Status;
/* Start Fast or Low Power Advertising */
ret = aci_gap_set_discoverable(
ADV_TYPE,
CFG_FAST_CONN_ADV_INTERVAL_MIN,
CFG_FAST_CONN_ADV_INTERVAL_MAX,
BLE_ADDR_TYPE,
ADV_FILTER,
0,
0,
0,
0,
0,
0);
/* Update Advertising data */
ret = aci_gap_update_adv_data(sizeof(ad_data), (uint8_t*) ad_data);
if (ret == BLE_STATUS_SUCCESS)
{
APP_DBG_MSG("Successfully Start Fast Advertising \n" );
}
else
{
APP_DBG_MSG("Start Fast Advertising Failed , result: %d \n", ret);
}
return;
}
Thank you again for your help,
Akos
