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.
如果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
如果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
嗨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
It turned out that it is not OTP's direct fault.
As written in commentin 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:...).
Hi Bojan,
We have taken this offline from forum - an email has been sent in your registered address.
Thanks, PM_Dialog