Pairing fails if OTP is programmed

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at https://www.dialog-semiconductor.com/support . We’ll be fixing bugs / optimising the searching and tagging over the coming days.
4 posts / 0 new
Last post
bojanpotocnik
Offline
Last seen: 1 year 1 month ago
Joined: 2019-11-26 11:41
Pairing fails if OTP is programmed

Hi,

our application is based on ble_app_all_in_one, everything was working well (PC, Android, iOS devices, USER_CFG_FEAT_SEC_REQ set to GAP_SEC1_SEC_PAIR_ENC or GAP_SEC1_AUTH_PAIR_ENC) during development on DA14580DEVKT-P_VC, but pairing stopped working when deployed on existing boards.

If USER_CFG_FEAT_SEC_REQ is set to GAP_SEC1_AUTH_PAIR_ENC, the pairing fails with:
> Authentication failed with status BLE_GAP_SEC_STATUS_CONFIRM_VALUE

If USER_CFG_FEAT_SEC_REQ is set to GAP_SEC1_SEC_PAIR_ENC, the pairing fails with:
> Authentication failed with status BLE_GAP_SEC_STATUS_DHKEY_FAILURE

With help of many DA14585_WLCSP34 and DA14585_QFN40 dautherboards, we located the cause: using the same FW and SmartSnippets Toolbox - Booter, we discovered that all dautherboards with OTP programmed fail pairing procedure, and all dautherboards with empty OTP are successfully paired.

Which OTP field/value cause that and what is the workaround? We cannot debug that because... well.. OTP, unless we have 100 dautherboards to brute-force.

Thank you,
Bojan

Device: 
PM_Dialog
Offline
Last seen: 6 months 3 weeks ago
Staff
Joined: 2018-02-08 11:03
Hi bojanpotocnik,

Hi bojanpotocnik,

Thanks for your question online. Please read the OTP Header and you will see that there isn’t any filed related to the security. This behavior is not related to OTP. Would it be possible to use a BLE sniffer and share a log file, so that we can understand what is happening over the air?

Thanks, PM_Dialog

bojanpotocnik
Offline
Last seen: 1 year 1 month ago
Joined: 2019-11-26 11:41
It turned out that it is not

It turned out that it is not OTP's direct fault.

As written in comment in this C-code snippet, if OTP is not programmed then CFG_NVDS_TAG_BD_ADDRESS will be used to get BD address value. It just happens that value of CFG_NVDS_TAG_BD_ADDRESS was the same as our testing BD address, so it was never actually changed.

When we started to actually set real BD addresses, value of CFG_NVDS_TAG_BD_ADDRESS was not correct and the address was changed in runtime - causing pairing to fail, as described in separate question - Pairing fails after changing device BD address. So when FW run on production device with OTP not programmed, BD address was set via command - causing pairing to fail. But when testing on dautherboards with OTP programmed - the adresses in OTP were different than our testing address (the same as CFG_NVDS_TAG_BD_ADDRESS), again triggering address change (changing it to our testing address) - pairing to fail.

It does not help to set CFG_NVDS_TAG_BD_ADDRESS to all 0's (co_null_bdaddr), the behaviour is the same. If nvds_get_func is changed to return NVDS_FAIL, then default Dialog BT address is applied in ROM (a8:89:67:45:...).

PM_Dialog
Offline
Last seen: 6 months 3 weeks ago
Staff
Joined: 2018-02-08 11:03
Hi Bojan,

Hi Bojan,

We have taken this offline from forum - an email has been sent in your registered address.

Thanks, PM_Dialog