After updating from SDK V2.1.3 OTA to SDK V2.9.0, iOS cannot correctly read data such as the model number, but Android can read it normally.
Turn off Bluetooth in the system, turn it back on, and it can be read normally after connecting.
After updating from SDK V2.1.3 OTA to SDK V2.9.0, iOS cannot correctly read data such as the model number, but Android can read it normally.
Turn off Bluetooth in the system, turn it back on, and it can be read normally after connecting.
Hello,
Can you check whether the device actually restores the bond data and the CCCD when the new firmware boots? Are you seeing a new pairing dialog after the OTA/reboot?
I see that you have enabled CONFIG_BT_SETTINGS=y, but in the application, after enabling Bluetooth, you also need to call settings_load(). This call restores the bonds and CCCDs, see this here.
Try enabling the logs CONFIG_BT_LOG_LEVEL_DBG and CONFIG_SETTINGS_LOG_LEVEL_DBG and check if there are any log messages indicating that CCCD data is being loaded from flash after boot.
Kind regards,
Abhijith
Hello,
Can you check whether the device actually restores the bond data and the CCCD when the new firmware boots? Are you seeing a new pairing dialog after the OTA/reboot?
I see that you have enabled CONFIG_BT_SETTINGS=y, but in the application, after enabling Bluetooth, you also need to call settings_load(). This call restores the bonds and CCCDs, see this here.
Try enabling the logs CONFIG_BT_LOG_LEVEL_DBG and CONFIG_SETTINGS_LOG_LEVEL_DBG and check if there are any log messages indicating that CCCD data is being loaded from flash after boot.
Kind regards,
Abhijith
Hello,
There are no new pairing dialog after OTA/reboot.
Log：
*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
[00:00:00.008,697] <dbg> settings: settings_nvs_backend_init: Initialized
[00:00:00.044,067] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision:
2d 79 a1 c8 6a 40 b7 3c f6 74 f9 0b 22 d3 c4 80 |-y..j@.< .t.."...
74 72 82 ba |tr..
[00:00:00.052,551] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.052,581] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.052,612] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 45.41337 Build 3074452168
[00:00:00.053,131] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:00.053,314] <dbg> settings: settings_call_set_handler: set-value OK. key: bt/ccc/f0051b64f7c00
[00:00:00.053,61
This seems like:Confusing warning: "No ID address. App must call settings_load" · Issue #65817 · zephyrproject-rtos/zephyr
Log:
*** Booting nRF Connect SDK v2.9.0-7787b2649840 *** *** Using Zephyr OS v3.7.99-1f8f3dc29142 *** [00:00:00.002,838] <dbg> bt_gatt: gatt_register: attr 0x200029cc handle 0x002a uuid 2800 perm 0x01 [00:00:00.002,868] <dbg> bt_gatt: gatt_register: attr 0x200029e0 handle 0x002b uuid 2803 perm 0x01 [00:00:00.002,990] <dbg> bt_gatt: gatt_register: attr 0x200029f4 handle 0x002c uuid da2e7828-fbce-4e01-ae9e-261174997c48 perm 0x02 [00:00:00.003,051] <dbg> bt_gatt: gatt_register: attr 0x20002a08 handle 0x002d uuid 2902 perm 0x03 [00:00:00.008,361] <dbg> settings: settings_nvs_backend_init: Initialized [00:00:00.049,743] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x0c03 param_len 0 --- 83 messages dropped --- [00:00:00.049,774] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x20036c18 [00:00:00.049,774] <dbg> bt_hci_core: bt_hci_cmd_send_sync: buf 0x20036c18 opcode 0x0c03 len 3 [00:00:00.049,804] <dbg> bt_hci_core: bt_tx_TX
There are too many logs, and 'messages dropped' often appears.
Hi Menon,
I have captured the logs; please see the attachment.
The BLE behavior on iOS and Android is a bit different.
IOS Address: 6C:3A:FF:11:53:B0
[00:00:16.234,741] <dbg> bt_gatt: bt_gatt_connected: conn 0x2000c470
[00:00:16.236,480] <dbg> bt_gatt: ccc_set_direct: key: bt/ccc/6c3aff1153b00
[00:00:16.237,792] <dbg> bt_gatt: ccc_set: Read CCC: handle 0x0004 value 0x0002
[00:00:16.239,074] <dbg> bt_gatt: ccc_set: Read CCC: handle 0x0026 value 0x0001
[00:00:16.240,356] <dbg> bt_gatt: ccc_load: Restoring CCC: handle 0x0004 value 0x0002
[00:00:16.241,851] <dbg> bt_gatt: ccc_load: Unable to restore CCC: handle 0x0026 cannot be found
[00:00:16.243,621] <dbg> bt_gatt: ccc_set: Restored CCC for id:0 addr:6C:3A:FF:11:53:B0 (public)
[00:00:16.248,321] <dbg> bt_gatt: gatt_ccc_changed: ccc 0x20002724 value 0x0002
[00:00:16.249,664] <dbg> bt_gatt: find_sc_cfg: id: 0, addr: 6C:3A:FF:11:53:B0 (public)
[00:00:16.251,068] <dbg> bt_gatt: sc_restore: no SC data found
[00:00:16.252,166] <dbg> bt_att: bt_att_status: chan 0x20027084 status 0x20027094
[00:00:16.272,857] <dbg> bt_att: bt_att_recv: Received ATT chan 0x20027080 code 0x1d len 6
[00:00:16.274,291] <dbg> bt_att: att_indicate: chan 0x20027080 handle 0x0008
[00:00:16.275,512] <dbg> bt_gatt: bt_gatt_notification: handle 0x0008 length 4
[00:00:16.276,855] <dbg> bt_att: chan_send: code 0x1e
[00:00:16.277,832] <dbg> bt_att: att_tx_destroy: 0x200367b0
[00:00:16.278,808] <dbg> bt_att: att_on_sent_cb: opcode 0x1e
[00:00:16.279,815] <dbg> bt_att: att_on_sent_cb: UATT bearer, calling att_sent
[00:00:16.281,066] <dbg> bt_att: att_sent: conn 0x2000c470 chan 0x20027084
[00:00:16.282,257] <dbg> bt_att: bt_att_sent: chan 0x20027080
[00:00:16.512,908] <dbg> bt_att: bt_att_encrypt_change: chan 0x20027084 conn 0x2000c470 handle 16 sec_level 0x02 status 0x00
[00:00:16.514,801] <dbg> bt_gatt: bt_gatt_encrypt_change: conn 0x2000c470
[00:00:16.516,082] <dbg> bt_gatt: gatt_ccc_changed: ccc 0x20002724 value 0x0002
[00:00:16.517,395] <dbg> bt_gatt: find_sc_cfg: id: 0, addr: 6C:3A:FF:11:53:B0 (public)
[00:00:16.518,798] <dbg> bt_gatt: sc_restore: no SC data found
Android Address: F0:05:1B:64:F7:C0
[00:00:20.023,956] <dbg> bt_gatt: bt_gatt_connected: conn 0x2000c540
[00:00:20.026,550] <dbg> bt_gatt: ccc_set_direct: key: bt/ccc/f0051b64f7c00
[00:00:20.027,832] <dbg> bt_gatt: ccc_set: Read CCC: handle 0x0004 value 0x0002
[00:00:20.029,174] <dbg> bt_gatt: ccc_set: Read CCC: handle 0x0026 value 0x0001
[00:00:20.030,639] <dbg> bt_gatt: ccc_set: Read CCC: handle 0x002c value 0x0001
[00:00:20.031,921] <dbg> bt_gatt: ccc_load: Restoring CCC: handle 0x0004 value 0x0002
[00:00:20.033,386] <dbg> bt_gatt: ccc_load: Unable to restore CCC: handle 0x0026 cannot be found
[00:00:20.034,942] <dbg> bt_gatt: ccc_load: Unable to restore CCC: handle 0x002c cannot be found
[00:00:20.036,529] <dbg> bt_gatt: ccc_set: Restored CCC for id:0 addr:F0:05:1B:64:F7:C0 (public)
[00:00:20.040,863] <dbg> bt_gatt: gatt_ccc_changed: ccc 0x20002724 value 0x0002
[00:00:20.042,205] <dbg> bt_gatt: find_sc_cfg: id: 0, addr: F0:05:1B:64:F7:C0 (public)
[00:00:20.043,609] <dbg> bt_gatt: sc_restore: peer F0:05:1B:64:F7:C0 (public) start 0x0001 end 0xffff
Hi Menon，
Three devices are connected.
1. Android MAC: F0:05:1B:64:F7:C0 (public)
2. iOS MAC: 6C:3A:FF:11:53:B0 (public)
3. iOS MAC: 7C:04:D0:6C:A2:4A (public)
Two random addresses appeared:
1. 4B:4F:D8:FE:15:CA (random)
2. 47:CF:4D:30:CD:4A (random)
Then OTA was performed, updating from sdk-v2.1.3 to sdk-v2.9.0. After the OTA succeeded, the iOS devices could not communicate normally.
In sdk-v2.9.0, the battery service has a new characteristic: BT_GATT_CPF(&level_cpf).
Because iOS uses random addresses, there is no bond here, so the SC is not stored.
static void sc_save(uint8_t id, bt_addr_le_t *peer, uint16_t start, uint16_t end)
{
struct gatt_sc_cfg *cfg;
bool modified = false;
BT_WARN("peer %s start 0x%04x end 0x%04x", bt_addr_le_str(peer), start,
end);
cfg = find_sc_cfg(id, peer);
if (!cfg) {
/* Find and initialize a free sc_cfg entry */
cfg = find_sc_cfg(BT_ID_DEFAULT, BT_ADDR_LE_ANY);
if (!cfg) {
BT_ERR("unable to save SC: no cfg left");
return;
}
cfg->id = id;
bt_addr_le_copy(&cfg->peer, peer);
}
/* Check if there is any change stored */
if (!(cfg->data.start || cfg->data.end)) {
cfg->data.start = start;
cfg->data.end = end;
modified = true;
goto done;
}
modified = update_range(&cfg->data.start, &cfg->data.end, start, end);
done:
if (IS_ENABLED(CONFIG_BT_SETTINGS) &&
modified && bt_addr_le_is_bonded(cfg->id, &cfg->peer)) {
sc_store(cfg);
}
}