Hi all,
We have 2 FRDM-KW38 that are paired. We are using the wireless UART feature of it. From the slave part, we send advertisement packets to the master and the master can scan and receive them. However, if we send the "extended advertisement" packet, the master cannot read them. So the question is: Is extended advertisement mode supported in wireless UART? Please note we want to be able to receive extended advertisement packets while we are paired.
We are using MCUexpresso and Bluetooth® Low Energy Demo Applications
User’s Guide document from NXP.
Regards,
Nader
Hi Gavin, I am trying to use the Wireless UART project and add Extended Advertising to the project.
I used lib_ble_5-0_AE_host_peripheral_cm0p_gcc.a library on the peripheral side.
sofar i am able to connect to NXP_WU with IOT_TOOLBOX Wireless UART,
and if I start ExtAdvertising i can see Ad. Data in IOT_Toolbox Beacons.
I can send data from the Iot_toolbox WUart to the KW38 device but on the other side no data comes to the ToolBox.
I checked and saw that BleServDisc_Finished in ble_service_discovery.c is never called and neither is BleApp_ServiceDiscoveryCallback.
Is lib_ble_5-0_AE_host_peripheral_cm0p_gcc.a supporting ble_service_discovery or not?
Henry Gazeri
Hi @ArianRF ,
Thanks for contacting NXP support.
Can you provide more detailed descriptions? Which project from the SDK are you using? The phenomenon described seems strange, as the UART should not stop receiving due to the extended advertisement. If possible, could you provide the portion of code that was modified?
Hope you are doing well!
B.R.
Gavin
app_Config.c
gapExtAdvertisingParameters_t gExtAdvParams =
{
/* SID */ 1, \
/* handle */ 1, \
/* minInterval */ 1600 /* 1 s */, \
/* maxInterval */ 3200 /* 2 s */, \
/* ownAddrType */ gBleAddrTypePublic_c,\
/* ownAddress */ {0, 0, 0, 0, 0, 0}, \
/* peerAddrType */ gBleAddrTypePublic_c,\
/* peerAddress */ {0, 0, 0, 0, 0, 0}, \
/* channelMap */ (gapAdvertisingChannelMapFlags_t) (gAdvChanMapFlag37_c | gAdvChanMapFlag38_c | gAdvChanMapFlag39_c), \
/* filterPolicy */ gProcessAll_c, \
/* extAdvProperties */ (bleAdvRequestProperties_t)gAdvIncludeTxPower_c | (bleAdvRequestProperties_t)gAdvReqConnectable_c, \
/* TxPower */ mDefaultTxPower, \
/* primaryPHY */ (gapLePhyMode_t)gLePhy1M_c, \
/* secondaryPHY */ (gapLePhyMode_t)gLePhy1M_c, \
/* secondaryAdvMaxSkip */ 0, \
/* enableScanReqNotification*/ FALSE \
};
//extern uint8_t extAdData2[26];
extern uint8_t extAdData3[200];
//uint8_t extAdData2[16]= {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1};//"AGAria-1234-5678"};
uint8_t extAdData3[200]={0};
static gapAdStructure_t extAdvScanStruct[] = {
{
.length = NumberOfElements(adData0) + 1,
.adType = gAdFlags_c,
.aData = (uint8_t*)adData0
},
{
.length = NumberOfElements(uuid_service_wireless_uart) + 1,
.adType = gAdManufacturerSpecificData_c,//gAdShortenedLocalName_c,//gAdManufacturerSpecificData_c,
.aData = (uint8_t *)uuid_service_wireless_uart
},
{
.length = SizeOfString(extAdData3) + 1,
.adType = gAdShortenedLocalName_c,//gAdManufacturerSpecificData_c,
.aData = (uint8_t*)extAdData3
}
};
gapAdvertisingData_t gAppExtAdvertisingData =
{
NumberOfElements(extAdvScanStruct),
(void *)extAdvScanStruct
};
static gapAdStructure_t extAdvScanStructNoData[] = {
{
.length = NumberOfElements(adData0) + 1,
.adType = gAdFlags_c,
.aData = (uint8_t*)adData0
}
};
gapAdvertisingData_t gAppExtAdvertisingNoData =
{
NumberOfElements(extAdvScanStructNoData),
(void *)extAdvScanStructNoData
};
////////////////////
in function void BleApp_GenericCallback(gapGenericEvent_t *pGenericEvent)
case gExtAdvertisingParametersSetupComplete_c:
{
gapAdvertisingData_t* pExtAdvData;
if(mAppTargetState == mAppState_PeriodicAdv_c)
{
pExtAdvData = &gAppExtAdvertisingNoData;
}
else
{
pExtAdvData = &gAppExtAdvertisingData;
}
// Serial_Print(gAppSerMgrIf, "gExtAdvertisingParametersSetupComplete_c\n\r", 0);
if(gBleSuccess_c != Gap_SetExtAdvertisingData(gExtAdvParams.handle, pExtAdvData, NULL))
{
panic(0, 0, 0, 0);
}
}
break;
case gExtAdvertisingDataSetupComplete_c:
{
// Serial_Print(gAppSerMgrIf, "gExtAdvertisingDataSetupComplete_c\n\r", 0);
if(gBleSuccess_c != App_StartExtAdvertising(BleApp_AdvertisingCallback, NULL, gExtAdvParams.handle, gBleExtAdvNoDuration_c, gBleExtAdvNoMaxEvents_c))
{
panic(0, 0, 0, 0);
}
}
break;
///////////
in finction BleApp_HandleKeys(key_event_t events)
{
uint8_t mPeerId = 0;
switch (events)
{
case gKBD_EventPressPB1_c:
{
bleResult_t ret;
ret = SetExtAdvertisingNewParameters();
if (gBleSuccess_c == ret)
{
(void)TMR_StartLowPowerTimer(mAppTimerExtData,gTmrLowPowerIntervalMillisTimer_c,TmrSeconds(2), SetExtAdvertisingDataCallback, NULL);
}// gTmrLowPowerSecondTimer_c | gTmrSetSecondTimer_c
break;
}
case gKBD_EventPressPB2_c:
{
(void)TMR_StopTimer(mAppTimerExtData);
mAdvState.advOn=1;
BleApp_Advertise();
break;
}
////////
in function static void BleApp_Config(void)
{
BleServDisc_RegisterCallback(BleApp_ServiceDiscoveryCallback);
Thanks,
Henry
Hi @hgazeri ,
Thanks for your additional details. I will confirm with our team about whether the "Wireless UART" project support "extended advertisement" packet or not.
And for the extended advertisement sending and receiving, could you please try the project "adv_ext_central" and "adv_ext_peripheral" ? They definitely support this feature.
Their detailed use can be found in section 5.15 of the document "Bluetooth Low Energy Demo Applications User's Guide.pdf".
Hope you are doing well!
B.R.
Gavin
@Gavin_Jia @hgazeri @iaingalloway
Thanks Gavin. Here are a few updates and questions.
1) We started with 2 KW38 (master and slave) and paired them. The normal advertisement works just fine. We used (lib_ble_5-0_host_cm0p_gcc.a) lib.
2) With the same code, we used (lib_ble_5-0_AE_host_peripherial_cm0p_gcc.a) library to KW38 of slave side but the master is still using the same lib (lib_ble_5-0_host_cm0p_gcc.a). It shows we are paired and we can send data via the ext-adv from the slave. But the master KW38 does not receive any data from the master KW38 in pair mode. The Slave KW38 still receives data from master KW38 and transmits data to it, but the master KW38 cannot receive the data from the slave KW38. We realized one of the functions (BleApp_ServiceDiscoveryCallback) is not called when the slave KW38 is using the (lib_ble_5-0_AE_host_peripherial_cm0p_gcc.a) library. I have attached the code to this message. The mValidDevices seems to be "false" as the slave KW38 does not find the master KW38.
3) Can we pair in extended advertisement mode?
Regards,
Nader
Hi @ArianRF ,
Sorry for my late reply. My colleagues and I are following up on this issue internally.
Could you use the lib_ble_5-0_AE_host_central_cm0p_gcc.a or lib_ble_5-0_AE_host_cm0p_gcc.a for the Master side? please try it.
If you can get the sniffer log, that will be very useful for analyzing problems.
B.R.
Gavin
Hi @Gavin_Jia (CC @iaingalloway )
We ( @hgazeri ) tried it again and still face the same issue. We believe this function (BleApp_ServiceDiscoveryCallback) needs to be added to the library (lib_ble_5-0_AE_host_peripherial_cm0p_gcc.a) to make it work.
Also, we still wonder if you can answer us the following question:
Can we pair two KW38 device in extended advertisement mode?
Regards,
Nader
Hi @ArianRF ,
Thanks for your patient and detailed test.
Our Team is still working on this issue and expert have confirmed that this function was built into this lib file.
And for the second question, we can pair two KW38 device in extended advertisement mode. At the project "adv_ext_central" and "adv_ext_peripheral", they are using "_AE_....a" for corresponding roles(Master and Slave).
In additional, the three lib file's differences:
That's why we need to change the lib file using at the master side. So at the slave side, we can using lib_ble_5-0_AE_host_cm0p_gcc.a as well.
At the same time, would you please try with this Application Note? Since there is not a sniffer log, it is hard to locate where the bug is.
B.R.
Gavin
Thanks @Gavin_Jia for your prompt response.
We tried as you suggested but no difference. We also checked the AN and have already followed the steps.
Please see below for more detail:
Our base is Wireless UART as we need to connect two UART wirelessly.
Per your email, we have the following options:
If we use 1 or 2 of the above libraries on the “Central” side, and 2 or 3 on the “peripheral” side, the Wireless UART gets messed up and not working anymore.
If we use lib_ble_5-0_host_cm0p_gcc.a on the "central" side and 2 or 3 on the “peripheral” side then the following happens:
If NXP can give us a version of 2 (lib_ble_5-0_AE_host_cm0p_gcc.a ) that supports Wireless UART and supports pairing, this can solve our issue.
Regards,
Nader