SmartBond™ DA14682 and DA14683
Single-chip high-security Bluetooth 5 solution with expandable memory
The SmartBond DA14682 and DA14683 are the world’s first single-chip solutions for Smart Home, Industrial and wearable devices that meets the highest security standards. These highly integrated System-on-Chip (SoC) devices support Bluetooth 5 as well as Bluetooth mesh, and include a range of dedicated features to ensure cutting-edge security for both consumers and developers.
As part of our SmartBond range, both SoCs offer industry-leading performance from the lowest power consumption and smallest footprint. Their flexible architecture ensures plenty of processing capacity when you need it while saving power when you don’t. It also allows the devices to manage multi-sensor arrays and enables always-on sensing.
Both devices offer extensive memory capacity and differ only in their memory configuration. Specifically, the DA14683 supports unlimited external Flash for maximum design flexibility while the DA14682 includes 8 Mbits of onboard Flash, making it ideal for applications with tight space constraints. Both options allow you to benefit from over-the-air updates.
To further simplify your development, our SmartSnippets™ software and versatile Hardware Development Kits help you optimize your software for power consumption.
Lifecycle status
Benefits
Highest level of security
IPv6 connectivity
Lowest system power
Lowest system BoM
Smallest system size
Applications
Wearables
Smart Home
Cloud connected applications
Industrial
Human Interface Devices
Virtual reality remotes
Banking
Packages
AQFN-60 (6.0 x 6.0 x 0.9 mm)
WLCSP-53 (3.4 x 3.0 x 0.5 mm)
Stay connected
Get in touch with us directly through our worldwide sales offices, or contact one of our global distributors and representatives.
Inquiries Distributors and Representatives Register for newslettersDevelopment Kits and Reference Designs
Hardware Development Kits based on DA14682 and DA14683 |
---|
DA14683 Development Kit USB |
DA14683 Development Kit Pro |
Relevant reference designs |
---|
Smart USB Dongle |
SmartBond™ DA14583 IoT Sensor Development Kit - Quick Start Video
SmartBond™ DA14583 IoT Sensor Development Kit
SDK 5.0.x Introduction
SDK 5.0.x Introduction (Chinese)
Production Line Tool Kit Webinar
You can no longer post questions or comments on this page. All product forum activity on the Dialog Semiconductor website has been migrated to a new platform called RenesasRulz. Renesas Electronics Corporation (“Renesas”) will be the service provider and processor managing this move on behalf of Dialog Semiconductor PLC. (“Dialog Semiconductor”). Please post your questions there:
DA1468x
4 months ago
Add a 128-bit AND 16-bit UUID in the same advertising packet
Posted by andrewhh 190 points 5 repliesHi,
I would like a method to advertise both a 128-bit UUID and a 16-bit UUID. I want to initially advertise the 128-bit UUID, but then 15-300s later, add the 16-bit UUID to activate iOS' "State Preservation and Restoration" feature that wakes up my iOS app in the background.
I currently have an advertisement that works and can be seen, but sometimes my firmware will crash on the OS_ASSERT.
This is the method that currently works:
/* Advertising data */
gap_adv_ad_struct_t adv_data[2];
adv_data[0] = (gap_adv_ad_struct_t) GAP_ADV_AD_STRUCT(GAP_DATA_TYPE_UUID128_LIST_INC,sizeof(hpy_hcs_uuid.uuid128),hpy_hcs_uuid.uuid128);
/* If the wakeup UUID is not advertised then iOS will probably kill the BLE connection
* to the ring when Happy iOS app is in background */
adv_data[1] = (gap_adv_ad_struct_t) GAP_ADV_AD_STRUCT_BYTES(GAP_DATA_TYPE_UUID16_LIST_INC,
0x69, 0x69); // Happy Wakeup UUID
OS_ASSERT(BLE_STATUS_OK == ble_gap_adv_ad_struct_set(ARRAY_LEN(adv_data), adv_data, ARRAY_LEN(scan_rsp) , scan_rsp));
The two UUIDs appear:
I think that method is vulnerable to stack corruption because I see crash logs from my firmware crashing in that OS_ASSERT.
Is there a simpler method to achieve the same thing? Do I need to use a static array for my advertising data? I tried using this code and the 16-bit UUID did not appear in my BLE scanner.
char device_name[HPY_DEVICE_NAME_STR_LEN];
uint8_t device_name_len = hpy_get_device_name_str(device_name);
//set up device name
ble_gap_device_name_set(device_name,ATT_PERM_READ);
/* Setup advertising */
att_uuid_t hpy_hcs_uuid;
ble_uuid_from_string(UUID_HPY_HCS, &hpy_hcs_uuid);
/* Scan Response object to be populated with <Complete Local Name> AD type */
/* Define Scan Response object internals dealing with retrieved name */
gap_adv_ad_struct_t scan_rsp[1];
scan_rsp[0] = (gap_adv_ad_struct_t) GAP_ADV_AD_STRUCT(GAP_DATA_TYPE_LOCAL_NAME, device_name_len, device_name);
/* We advertise HCS (Happy Communication Service UUID) and another service to
* help the mobile app wake up.
All other services will be resolved at connection time.
It means that only our app will ever find our devices and it won't be obvious
that the ring supports Device Information Service or Battery Service. */
/* If the wakeup UUID is not advertised then iOS will probably kill the BLE connection
* to the ring when Happy iOS app isits in background */
/* Advertising data */
uint8_t adv_data[] = {
17, /* Length */
GAP_DATA_TYPE_UUID128_LIST_INC,
/* 128-uuid in bytes, */
hpy_hcs_uuid.uuid128[0],
hpy_hcs_uuid.uuid128[1],
hpy_hcs_uuid.uuid128[2],
hpy_hcs_uuid.uuid128[3],
hpy_hcs_uuid.uuid128[4],
hpy_hcs_uuid.uuid128[5],
hpy_hcs_uuid.uuid128[6],
hpy_hcs_uuid.uuid128[7],
hpy_hcs_uuid.uuid128[8],
hpy_hcs_uuid.uuid128[9],
hpy_hcs_uuid.uuid128[10],
hpy_hcs_uuid.uuid128[11],
hpy_hcs_uuid.uuid128[12],
hpy_hcs_uuid.uuid128[13],
hpy_hcs_uuid.uuid128[14],
hpy_hcs_uuid.uuid128[15],
0x03, /* Length */
GAP_DATA_TYPE_UUID16_LIST_INC,
/* 16-bit iOS service UUID */
0x69,
0x69,
};
uint8_t size_of_adv_data = sizeof(adv_data);
uint8_t scan_rsp_with_len[scan_rsp[0].len + 2 ]; /* 2 = 1 len + 1 type */
scan_rsp_with_len[0] = scan_rsp[0].len,
scan_rsp_with_len[1] = scan_rsp[0].type;
for(int8_t i = 0; i < scan_rsp[0].len; i++){
scan_rsp_with_len[i + 2] = scan_rsp[0].data[i];
}
ble_error_t result = ble_gap_adv_data_set(size_of_adv_data, adv_data, ARRAY_LEN(scan_rsp_with_len) , scan_rsp_with_len);
OS_ASSERT(BLE_STATUS_OK == result);
}
4 months ago
The debugger shows BLE_STATUS_OK the first time it runs. The second time it runs, the debugger sometimes shows BLE_STATUS_OK, sometimes shows "BLE_ERROR_FAILED".
Yes. I want to change from advertising 1 UUID to 2 UUIDs. Not stop advertising. I tried stopping and starting and then later saw this comment explaining the "stop advertising" is unnecessary, so I removed the stop.
/**
* \brief Set advertising Data and scan response data
*
* This API call is used to modify the advertising data and scan response Data used. It can be used
* while an advertising operation is in progress. If an advertising operation is not in progress,
* the new Advertising Data and/or new Scan Response Data will be used the next time function
* ble_gap_adv_start() is called. The maximum Advertising Data length for undirected connectable
* advertising is BLE_ADV_DATA_LEN_MAX bytes (31 minus 3 that are reserved to set the Advertising Data
* type flags - which shall not be set in Advertising Data using this function). The equivalent max
* length for non-connectable advertising is BLE_NON_CONN_ADV_DATA_LEN_MAX bytes.
*
* \param [in] adv_data_len Length of the Advertising Data
* \param [in] adv_data Pointer to the Advertising Data
* \param [in] scan_rsp_data_len Length of the Scan Response Data
* \param [in] scan_rsp_data Pointer to the Scan Response Data
*
* \return result code
*/
ble_error_t ble_gap_adv_data_set(uint8_t adv_data_len, const uint8_t *adv_data,
uint8_t scan_rsp_data_len, const uint8_t *scan_rsp_data);
Attachment | Size |
---|---|
Screen Shot 2021-12-23 at 01.34.36 .png | 998.84 KB |
4 months ago
Hi andrewhh,
The following advertising data set is working fine on my side :
/* Advertising data */
static uint8_t adv_data[] = {
0x11, /* Length */
GAP_DATA_TYPE_UUID128_LIST_INC,
/* 128-uuid in bytes, */
0x59,
0x5A,
0x08,
0xE4,
0x86,
0x2A,
0x9E,
0x8F,
0xE9,
0x11,
0xBC,
0x7C,
0x98,
0x43,
0x42,
0x18,
0x03, /* Length */
GAP_DATA_TYPE_UUID16_LIST_INC,
/* 16-bit iOS service UUID */
0x69,
0x69
};
In the application task :
/* Set advertising data */
ble_gap_adv_data_set(sizeof(adv_data), adv_data, 0, NULL);
Can you please test it on your side?
Initially, you could set the advertising data only with the 128-bit UUID and then memcopy the 16-bit UUID .
Something like this :
/* Advertising data */
uint8_t adv_data[22] = {
0x11, /* Length */
GAP_DATA_TYPE_UUID128_LIST_INC, /* Try also GAP_DATA_TYPE_UUID128_LIST_INC */
/* 128-uuid in bytes, */
0x59,
0x5A,
0x08,
0xE4,
0x86,
0x2A,
0x9E,
0x8F,
0xE9,
0x11,
0xBC,
0x7C,
0x98,
0x43,
0x42,
0x18
};
/* Advertising data update */
uint8_t adv_data_update[] = {
0x03, /* Length */
GAP_DATA_TYPE_UUID16_LIST_INC,
/* 16-bit iOS service UUID */
0x69,
0x69
};
In the application task :
memcpy((adv_data + 18) , adv_data_update, sizeof(adv_data_update));
/* Set advertising data */
ble_gap_adv_data_set(sizeof(adv_data), adv_data, 0, NULL)
PS: Of course, I am using my own 128-bit UUID...
Thanks, PM_Dialog
4 months ago
it worked and has not crashed yet. The advertising switches successfully.
4 months ago
Hi andrewhh,
Thank you for confirming that it is working now. If you have more questions please raise a new forum ticket. We will be happy to help.
Kind regards, AA_Dialog
4 months ago
Hi andrewhh,
Can you kindly run it with the debugger attached and share what is the error code of the ble_gap_adv_ad_struct_set ( in the 1st code snippet). Otherwise, you could print the error code in case you are not able to run it with the debugger attached.
“initially advertise the 128-bit UUID, but then 15-300s later, add the 16-bit UUID to activate iOS'
Question : the advertisement is stopped after 15-300s, update the adv string and re-start advertising?
Thanks, PM_Dialog