**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:
```cstatic 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.
Hi Quoc,Thank you for posting your question online.Please refer on the Central Security Example on our Git Repo: BLE_SDK6_examples/connectivity/central_Security_Demo at main · dialog-semiconductor/BLE_SDK6_examples (github.com)For the Peripheral device, please use the ble_app_security example from the SDK6 as reference.Have you flashed your Firmware into the SPI Flash/I2C EEPROM or are you only testing this via RAM?The Bonding Table is stored in the SPI Flash or I2C EEPROM and the access to these Peripheral blocks should be enabled.Please also refer on our Security Tutorial: DA1453x Tutorial BLE Security — DA1453x&DA1458x Tutorial BLE security (renesas.com)Best Regards,OV_Renesas
Hi OV_Renesas, thanks for your quick response. I will look over your instructions and provide feedback if there are any issues
Hi OV_Renesas, I hope you are doing well. I have encountered an issue with the UART log as described below:
The Dialog 6.0.16 SDK uses ARM Compiler Version 5. After linking the project environment and following the Dialog 6.0.16 SDK guidelines, I was able to build the central_Security_Demo example. Then, I successfully set up the debug environment and flashed the firmware into the DA14531 Development Kit Pro.
In the next step, I encountered an issue with the UART print log, where it does not print out to the terminal. This is important for verifying the BLE security functionality in this example.
I looked at the code and found that the UART print log uses UART2, and the mapping for the TX line is defined in connectivity/central_Security_Demo/src/config/user_periph_setup.h: github.com/.../user_periph_setup.h
connectivity/central_Security_Demo/src/config/user_periph_setup.h: github.com/.../user_periph_setup.h
I also checked the configuration where the UART log was enabled: connectivity/central_Security_Demo/src/config/da1458x_config_basic.h.: github.com/.../da1458x_config_basic.h
connectivity/central_Security_Demo/src/config/da1458x_config_basic.h
I also made sure to correctly connect and map the UART TX line to the FTDI chip. After running the UART example on the Dialog 6.0.16 SDK, I observed output on the terminal. The UART TX line used in the UART example matches the UART TX line pin used in the central_Security_Demo example.
#define UART2_TX_PORT GPIO_PORT_0 #define UART2_TX_PIN GPIO_PIN_6
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?
Thank you in advance.
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
Hi OV_Renesas, 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).
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.zipPlease 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
Great, thank you for your support. I will check on that, and if there is a problem, I will let you know.
My setup:
A few questions:
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
Hi OV_Renesas,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.