• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 15 replies
  • Answers 4 answers
  • Subscribers 6 subscribers
  • Views 3272 views
  • Users 0 members are here
Options
Related

BLE Bonding Issue with DA14531 as BLE Central Device

Quoc Bui

**Hi Support Team,**

I am working on a project that uses the DA14531 as a BLE Central Device. We are planning to use the BLE Bonding feature, leveraging the BLE Security Layer to ensure secure data transmission. The user callback configuration events are set up as follows:

```c
static const struct app_callbacks user_app_callbacks = {
.app_on_connection = user_on_connection,
.app_on_disconnect = user_on_disconnect,
.app_on_update_params_rejected = NULL,
.app_on_update_params_complete = NULL,
.app_on_set_dev_config_complete = user_on_set_dev_config_complete,
.app_on_adv_nonconn_complete = NULL,
.app_on_adv_undirect_complete = NULL,
.app_on_adv_direct_complete = NULL,
.app_on_db_init_complete = user_on_db_init_complete,
.app_on_scanning_completed = user_on_scanning_completed,
.app_on_adv_report_ind = user_on_adv_report_ind,
.app_on_connect_failed = user_on_connect_failed,
.app_on_get_dev_name = default_app_on_get_dev_name,
.app_on_get_dev_appearance = default_app_on_get_dev_appearance,
.app_on_get_dev_slv_pref_params = default_app_on_get_dev_slv_pref_params,
.app_on_set_dev_info = default_app_on_set_dev_info,
.app_on_data_length_change = NULL,
.app_on_update_params_request = user_gapc_param_update_req_ind_handler,
.app_on_generate_static_random_addr = NULL,
.app_on_svc_changed_cfg_ind = NULL,
.app_on_get_peer_features = NULL,
#if (BLE_APP_SEC)
.app_on_pairing_request = default_app_on_pairing_request,
.app_on_tk_exch = user_app_on_tk_exch,
.app_on_irk_exch = NULL,
.app_on_csrk_exch = default_app_on_csrk_exch,
.app_on_ltk_exch = default_app_on_ltk_exch,
.app_on_pairing_succeeded = user_app_on_pairing_succeeded,
.app_on_encrypt_ind = NULL,
.app_on_encrypt_req_ind = default_app_on_encrypt_req_ind,
.app_on_security_req_ind = NULL,
.app_on_addr_solved_ind = default_app_on_addr_solved_ind,
.app_on_addr_resolve_failed = default_app_on_addr_resolve_failed,
.app_on_ral_cmp_evt = default_app_on_ral_cmp_evt,
.app_on_ral_size_ind = NULL,
.app_on_ral_addr_ind = NULL,
#endif // (BLE_APP_SEC)
};

#if (BLE_APP_SEC)
static const struct app_bond_db_callbacks user_app_bond_db_callbacks = {
.app_bdb_init = NULL,
.app_bdb_get_size = remote_bdb_get_size,
.app_bdb_add_entry = remote_bdb_add_entry,
.app_bdb_remove_entry = NULL,
.app_bdb_search_entry = remote_bdb_search_entry,
.app_bdb_get_number_of_stored_irks = remote_bdb_get_number_of_stored_irks,
.app_bdb_get_stored_irks = remote_bdb_get_stored_irks,
.app_bdb_get_device_info_from_slot = remote_bdb_get_device_info_from_slot,
};
#endif // (BLE_APP_SEC)
```

We have a BLE Peripheral device that also uses the DA14531, and we have successfully tested the BLE Bonding functionality with a mobile app.

**Testing Issue:**

I tested the bonding connection on the BLE Central device. It successfully connected and bonded with the BLE Peripheral device on the first BLE connection, triggering the **app_bdb_add_entry** event. However, during the subsequent disconnect/connection cycle (without resetting or power cycling the BLE Peripheral), it still requested the bonding event again, triggering the **app_bdb_add_entry** event. This behavior is unexpected as it should remember the bonding information.

Upon further investigation and debugging, I found that it does not trigger events to check the existing bonding information in RAM memory (such as **app_bdb_search_entry**, **app_bdb_get_number_of_stored_irks**, and **app_bdb_get_stored_irks** function callbacks). Instead, it only requests bonding from the SDK.

Can you provide guidance on how to resolve this issue so that the bonding information is correctly remembered across connections?

Thank you for your assistance.

Parents Reply
  • 0 in reply to Quoc Bui

    Hi Quoc,

    Thank you for the reply.

    Quoc Bui said:
    I tried to use the central_Security_Demo example that you suggested and encountered an issue with the UART log. I used the Dialog SDK 6.0.18, as mentioned in the Readme.md file for this example. After following the guideline for 'Linking the project environment and the Dialog 6.0.18 SDK', I tried to build the project and encountered an issue with linking to the hex file. I am aware that the Dialog 6.0.18 SDK requires using ARM Compiler Version 6, but I am unsure if this is causing the issue.

    Could you please share the issues/errors you faced during compilation?
    On my side, I tested with SDK v6.0.18 and SDK v6.0.22 and it worked as expected.
    You will need ARM Compiler v6 and Link Time Optimization enabled. For LTO enabled a license is required, if you do not have a license please refer here: (+) Link-Time optimization error - Bluetooth Low Energy - Wireless Connectivity - Renesas Engineering Community



    Quoc Bui said:
    Therefore, there is a high possibility that there are some missing UART configurations in the central_Security_Demo example, which prevent it from sending out the log. Could you please help me take a look at that?

    Could you please zip and attach the project here so I can take a look?
    Please include the python script you used to fix the paths.

    Best Regards,
    OV_Renesas

Children
  • 0 in reply to OV_Renesas

    Hi , thank you for your quick response:
    1. Regarding issue number one, the image below shows the linking error:

    central_Security_Demo_6.0.18 SDK.zip

    2. I have attached the zip file that contains the central_Security_Demo folder. You must run the Python script dlg_make_keil5_env_v2.000.py and link the SDK: SDK_6.0.16.1144 to your environment, because it was linked using absolute paths instead of relative paths on my computer.

    Additionally, you can check out and build the central_Security_Demo example, which supports the Dialog 6.0.16 SDK. The commit hash is ea1fc19327b207539b3f023f4d6c7ed1b6026fdd. Then, please try to print out the UART2 log to the terminal on your side, as I cannot see any UART log on my side (DA14531 Development Kit Pro).

    central_Security_Demo.zip
    • Add to Phrasebook
      • No word lists for English → Vietnamese...
      • Create a new word list...
    • Copy
  • 0 in reply to Quoc Bui

    Hi Quoc,

    Thank you for the reply.
    Regarding the Central Security example on SDK v6.0.18, on my side with ARM Compiler v6.19 and LTO enabled I am able to built the project without any errors.

    Regarding the Central security example on SDK v6.0.16, indeed I was not able to see any output on UART.
    I think the project was not running at all.
    I ported the example from v6.0.18 back to v6.0.16 and it worked.
    Please find it attached.7624.central_Security_Demo.zip
    Please use the python script to fix the paths and make sure that the correct scatter file has been assigned on the Linker tab:


    Best Regards,
    OV_Renesas

  • 0 in reply to OV_Renesas

    Great, thank you for your support. I will check on that, and if there is a problem, I will let you know.

  • 0 in reply to OV_Renesas
    Hi  ,
    Thank you for the central_Security_Demo.zip file. I have tested it, and the UART log is working. However, I still have an issue with bonding, which is similar to what was mentioned at the beginning of this thread. Note that I will be focusing on running the example using SDK Version 6.0.16.1144, as this is the SDK currently used in my project. You can see the details below:

    My setup:

    • SDK Version: 6.0.16.1144
    • BLE Central Example: central_Security_Demo.zip
    • BLE Peripheral Example: ble_app_security (sdk\projects\target_apps\ble_examples\ble_app_security)
    • Hardware Test: DA14531 Development Kit Pro
    I am using two Dialog Development Kits, one for BLE Central and one for BLE Peripheral. You can see the UART log output from the BLE Central below:

    Step 1: I initiated scanning on the BLE Central. I modified the firmware code to only find a specific BD Address that I specified. As a result, only one device was found after scanning.

    Step 2: After scanning, establish a connection to the BLE Peripheral. Once the connection is established, send the bonding request. The request is successful, as indicated by the log message "Pairing succeeded." Subsequently, you will see the log message "default_app_bdb_add_entry," which I added to the SDK (in the app_bond_db.c file) to check the BLE security event. This log indicates that a new bonding device has been added to the database. Furthermore, an LTK key (16 bytes) is generated for encryption/decryption during data exchange between the BLE Central and BLE Peripheral.

    Step 3: I forced the BLE Peripheral to disconnect by using a command on the BLE Central. I customized the code a bit to achieve this. You can see in the log that after receiving the command, the BLE Central and BLE Peripheral were disconnected.

    Step 4: I scanned and tried to connect with the BLE Peripheral again, and the connection was successfully established. However, unfortunately, the BLE Central still performed pairing again. You can see in the log, as shown in the image above, that it still shows "Pairing succeeded" and "default_app_bdb_add_entry," generating a different LTK key compared to the old one. I expected it to trigger the "default_app_bdb_search_entry," "default_app_bdb_get_number_of_stored_irks," and "default_app_bdb_get_stored_irks" events to identify that this BLE Peripheral was already in the database, eliminating the need for bonding again. I also added log entries for these events, but they did not appear in the terminal.

    A few questions:

    1. Could you take a look and give us a suggestion on whether I’m missing or wrong something in the configuration?
    2. If you have enough hardware (2 devices), could you please help me test and reproduce this case on your side? I would greatly appreciate it.

    Thank you in advance.
  • 0 in reply to Quoc Bui

    Hi Quoc,

    Thank you for the reply.
    Let me try to test this on my side and I will get back to you.
    In the meantime, have you placed the jumpers on J1 in order to enable the integrated SPI Flash on the Dev Kit?
    If the SPI Flash is not enabled, the bonding table will not be stored.
    Please also make sure you have defined the USER_CFG_APP_BOND_DB_USE_SPI_FLASH on user_config.h file.

    Best Regards,
    OV_Renesas

  • 0 in reply to OV_Renesas

    Hi ,

    Thank you for your quick response and for giving me some suggestions for that. I tested it as per your suggestion and unfortunately, the result was the same, as it still requests a new bonding event and generates a new LTK key.


    Below are all the changes I made:
    1. I enabled the USER_CFG_APP_BOND_DB_USE_SPI_FLASH config in the user_config.h file.


    2. I placed the jumpers on J1 to enable the integrated SPI Flash on the Dev Kit.

    Looking forward to the test results on your side. Thank you.

  • 0 in reply to Quoc Bui

    Hi Quoc,

    Thank you for the reply and apologies for the delay.
    I have reached out to you directly via a Private Message.
    Please check your inbox.

    Best Regards,
    OV_Renesas

  • 0 in reply to OV_Renesas

    HI ,

    Thank you for testing and providing me with some videos that demonstrate the BLE security features on your side. I really appreciate it. I was able to get the BLE Central Security Demo working on the Dev-kit. You can see the image below:

    The issue I was testing is caused by the external flash. I was unable to erase it, although I was able to use JLink and Keilc to flash the firmware. Unfortunately, I flashed the BLE Central code into this board, which led to a failure to retain bonding information in the flash memory. I have already replaced the board, and it is now working as expected.

    My next step is to try disabling the storage of bonding information in flash memory and instead storing it in RAM because my project does not have external flash. The idea is to delegate the storage of bonding information to another MCU, which will then sync this bonding information back to Dialog BLE Central. What do you think about this approach? Could you please give me some advice on it? Thanks.

    Additionally, I would like to repost your direct messages into this thread so that everyone can refer to them if they need to implement BLE Central or BLE Peripheral security features.

    • Add to Phrasebook
      • No word lists for English → Vietnamese...
      • Create a new word list...
    • Copy
  • +1 in reply to Quoc Bui

    HI ,

    Thank you for testing and providing me with some videos that demonstrate the BLE security features on your side. I really appreciate it. I was able to get the BLE Central Security Demo working on the Dev-kit. You can see the image below:

    The issue I was testing is caused by the external flash. I was unable to erase it, although I was able to use JLink and Keilc to flash the firmware. Unfortunately, I flashed the BLE Central code into this board, which led to a failure to retain bonding information in the flash memory. I have already replaced the board, and it is now working as expected.

    My next step is to try disabling the storage of bonding information in flash memory and instead storing it in RAM because my project does not have external flash. The idea is to delegate the storage of bonding information to another MCU, which will then sync this bonding information back to Dialog BLE Central. What do you think about this approach? Could you please give me some advice on it? Thanks.

    Additionally, I would like to repost your direct messages into this thread so that everyone can refer to them if they need to implement BLE Central or BLE Peripheral security features.

    Video demo & Zip file: 

    https://community.renesas.com/cfs-file/__key/conversationfiles/0aacb515-4d8b-4e76-9e53-3f2d9fcd6df7/531_5F00_central_5F00_peripheral_5F00_security_5F00_justworks.mp4
https://community.renesas.com/cfs-file/__key/conversationfiles/0aacb515-4d8b-4e76-9e53-3f2d9fcd6df7/central_5F00_justworks_5F00_sec_5F00_test.mp4
https://community.renesas.com/cfs-file/__key/conversationfiles/0aacb515-4d8b-4e76-9e53-3f2d9fcd6df7/central_5F00_le_5F00_secure_5F00_test.mp4
https://community.renesas.com/cfs-file/__key/conversationfiles/0aacb515-4d8b-4e76-9e53-3f2d9fcd6df7/Security_5F00_tests_5F00_v6.0.16.zip

    Save
    CONTINUE
    view saved words →
    Don't translate on double-click
    Don't show floating button
    Check the localized version of the site
    Upgrade to Pro to unlock more features
    No Internet Connection
  • 0 in reply to Quoc Bui

    Hi Quoc,

    Thank you for the reply and the feedback.
    Glad you were able to test the security features on your side.

    Quoc Bui said:
    My next step is to try disabling the storage of bonding information in flash memory and instead storing it in RAM because my project does not have external flash. The idea is to delegate the storage of bonding information to another MCU, which will then sync this bonding information back to Dialog BLE Central. What do you think about this approach? Could you please give me some advice on it?

    The Bonding information can be found in app_bond_db.c file, everything is stored in the bond_db struct:

    struct bond_db
{
    uint16_t start_hdr;
    uint8_t valid_slot[APP_BOND_DB_MAX_BONDED_PEERS];
    uint32_t timestamp_counter;
    uint32_t timestamp[APP_BOND_DB_MAX_BONDED_PEERS];
    struct app_sec_bond_data_env_tag data[APP_BOND_DB_MAX_BONDED_PEERS];
    uint16_t end_hdr;
};

// on app_securiy.h file you can find the app_sec_bond_data_env_tag bonding data as well

/// Application Security Bond Data environment structure
struct app_sec_bond_data_env_tag
{
    /// Valid bonding keys
    enum keys_present valid_keys;
    /// LTK (LTK, EDIV, RANDNB, Key size)
    /// Key to use for link encryption
    struct gapc_ltk ltk;
    /// Remote LTK (LTK, EDIV, RANDNB, Key size),
    /// Key sent by initiator for future reversed-role usage
    struct gapc_ltk rltk;
    /// Remote IRK (IRK, Identity Address, Identity Address Type)
    /// Key to resolve Resolvable Private Address address of peer
    struct gapc_irk rirk;
    /// Local CSRK
    /// Key used by local device to sign data
    struct gap_sec_key lcsrk;
    /// Remote CSRK
    /// Key used by remote device to sign data
    struct gap_sec_key rcsrk;
    /// BD address of peer (BD address, BD address type)
    struct gap_bdaddr peer_bdaddr;
    /// Authentication level (BOND, MITM, SEC, KEY)
    uint8_t auth;
    /// slot in database
    uint8_t bdb_slot;
};

    As long as you have the RAM retained and there is steady power supply on the DA14531, the Bonding Information will be retained in SRAM as well.
    You will need to send the bond_db struct on your Host MCU and you will also need to modify the callback functions in order to search the Bonding Table from the Host MCU side and not in the internal storage memories. 

    Best Regards,
    OV_Renesas