3. BLE Development Environment and First Application

3.1. Development Environment

3.1.1. Overview

This section first provides an overview for the DA1453x/DA1458x development environment that consists of the:

• Arm Keil uVision IDE/Debugger, Arm C/C++ Compiler, and its essential middleware components Keil IDE and the Keil build tools

• Arm Segger JTAG cables and software that is fully supported by the Keil environment

• DA1453x/DA1458x Software Development Kit (SDK)

The development environment is also supported by a number of other utilities and tools such as:

SmartSnippets™ Toolbox, which is a framework of PC-based utilities to control the DA1453x/DA1458x development kit, and consists of:

• Booter that is used to download hex files to DA1453x/DA1458x RAM over UART and to reset the chip to execute from there

• Board Setup is used to manage communication with the chip

• UART Terminal is available only for connection over UART. After the selected file is successfully downloaded to the DA1453x/DA1458x chip, the ‘Start Terminal’ button is activated and the user can click the button to receive data from UART

• Terminal Scripting tool is a Terminal Emulation tool bundled with SmartSnippents Toolbox that enables users to download a firmware and interact with a target device in real time

• Power Profiler is used for plotting the current (and associated charge) drawn by the DA1453x/DA1458x on the DK in real time over USB

• Battery Lifetime Estimator tool is available for DA1458x families. This tool is used to estimate the battery lifetime for a selected device family

• OTP Programmer tool is used to burn the OTP Memory and OTP Header

• SPI Flash/EEPROM Programmer is used to download an image file to the SPI Flash Memory or EEPROM

• RF Master is an implementation of Bluetooth SIG standardized receiver and transmitter HCI commands and additional custom test HCI commands. RF Master has replaced the Connection Manager tool. RF Master supports the following tests:

  • LE Tx/Rx

  • Unmodulated Tx/Rx

  • Continuous Tx

  • XTAL

  • Sleep

The “User Guide” html for all these utilities is available under the “help” drop down menu of the SmartSnippets™ Toolbox application. This is installed by SmartSnippets™ Studio.

3.1.2. Software Development Kit (SDK) Structure

The SDK structure is defined in the following sections.

3.1.2.1. root Directory

The SDK contains the following main directories.

Figure 16 root Directory Structure

3.1.2.2. binaries Directory

This directory holds the executable binaries of the PC applications stored in the host_apps directory as well as the binary file of the production test tool firmware. These binaries are provided so that the developer can run/test the applications with no need to compile the projects.

Figure 17 binaries Directory Structure

3.1.2.3. config Directory

This directory contains the DA1453x/DA1458x configuration files for the SmartSnippets tool and binary/hex files of flash programmer and secondary_boatloader.

3.1.2.4. doc Directory

This directory contains the SDK license files and chm files with the API documentation for each device family.

3.1.2.5. projects Directory

This directory contains the various SDK example projects. The projects directory is divided into two main directories:

• host_apps

• target_apps

Figure 18 projects Directory Structure

3.1.2.5.1. host_apps Directory

This directory holds example applications that run on an external processor (PC or other CPU). Actually, it contains the proximity and SUOTA initiator applications that run on PCs.

Figure 19 host_apps Directory Structure

3.1.2.5.2. target_apps Directory

This directory holds example applications that run on the DA1453x/DA1458x SoC. Each project directory contains Keil project files, along with the specific project’s source code and configuration files as shown in Figure 20.

Figure 20 target_apps Directory Structure

The ble_examples directory contains DA1453x/DA1458x SoC BLE application examples for “Integrated processor” or “External processor” configuration. The ble_examples demonstrate the BLE functionality of the DA1453x/DA1458x SoC. The following list describes briefly each BLE example.

• ble_app_barebone: BLE example that demonstrates basic BLE procedures such as advertising, connection, connection parameters update and implementation of the device information service. It is based on the “Integrated processor” configuration.

• ble_app_profile: BLE example that demonstrates the same as the ble_app_barebone project, plus the implementation of a custom service (128-bit UUID) defined by the user. The application demonstrates only the custom database creation. It is based on the “Integrated processor” configuration.

• ble_app_peripheral: BLE example that demonstrates the same as the ble_app_profile. The application also adds some basic interaction over the provided custom service (read/write/notify values). It is based on the “Integrated processor” configuration.

• ble_app_sleepmode: BLE example that demonstrates the same as the ble_app_profile. The application adds the use of the sleep mode API, and makes use of the two available sleep modes – Extended sleep mode (with or without OTP copy) with OTP copy. It is based on the “Integrated processor” configuration.

• ble_app_security: BLE example that demonstrates the same as the ble_app_profile. The application adds the various security/privacy features. It is based on the “Integrated processor” configuration.

• ble_app_ota: BLE example that demonstrates the same as the ble_app_profile. The application adds the over-the-air programming feature. It is based on the “Integrated processor” configuration.

• ble_app_all_in_one: only for DA1458x targets, BLE example that combines in one example the features of the previous ble_app_<example> projects. It is based on the “Integrated processor” configuration.

• prox_monitor_ext: BLE example that demonstrates the proximity monitor service. It also includes the device information client service. It uses the “External processor” configuration.

• prox_reporter: BLE example that demonstrates the proximity reporter service. It also includes the device information server service, the battery server service and the software patching over the air receiver (SUOTAR) service. It uses the “Integrated processor” configuration.

The hci directory contains a DA1453x/DA1458x SoC application example for HCI interface over UART.

• hci: example that demonstrates HCI over serial interface that allows the development of the host on a separate processor.

The misc directory contains miscellaneous application examples for the DA1453x/DA1458x SoC. The following list describes briefly each example.

• aes: AES Encryption demo application is a simple application example, which demonstrates how the CryptoAPI can be used to encrypt or decrypt user data using the AES algorithm.

• ancs_client: only for DA1458x targets, ANCS Client example application is a sample implementation of an Apple Notification Center Service (ANCS) Client.

• ble_app_noncon: BLE example that demonstrates non-connectable advertising.

• ble_app_lecb: BLE example that demonstrates LE credit based channels.

The peripheral_examples directory contains DA1453x/DA1458x SoC peripheral examples. The examples demonstrate some of the non-BLE functionality of the DA1453x/DA1458x SoC. The following list describes briefly each peripheral example.

• adc: analog to digital conversion example

• blinky: blinks a led

• i2c: i2c interface example

• quadrature_decoder: quadrature decoder example

• shared: shared library for peripheral examples

• spi: spi interface example

• systick: SysTick timer control example

• timer0: timer0 control example

• timer2: timer2 control example

• uart: uart communication example

The Keil projects contained in the ble_examples SDK directories are based on the structure shown in Figure 21.

Figure 21 Project Directory Example Layout

The Keil_5 directory contains the Keil project files *.uvprojx and *.uvoptx.

The src directory contains the user’s application source code and header files (e.g. user_<example_name>.c, user_<example_name>.h or more) and two directories: config and platform. These two directories contain files that must be included in a user project structure. The names of these files must not be altered by the user.

Note

The custom_profile directory can be omitted when the user does not use a Custom profile in his application.

Figure 22 src Project Directory Example Layout

• da1458x_config_advanced.h: holds DA1453x/DA1458x advanced configuration settings.

• da1458x_config_basic.h: holds DA1453x/DA1458x basic configuration settings.

• user_callback_config.h: callback functions that handle various events or operations.

• user_config.h: holds advertising parameters, connection parameters, etc.

• user_config_sw_ver.h: holds user-specific information about the software version.

• user_custs1_def.c: defines the structure of the Custom 1 profile database structure.

• user_custs_config.c: defines the cust_prf_funcs[] array, which contains the Custom profiles API functions calls.

• user_modules_config.h: defines which application modules are included or excluded from the user’s application.

• user_periph_setup.h: holds hardware-related settings.

• user_profiles_config.h: defines which BLE profiles (Bluetooth SIG adopted or custom ones) will be included in the user’s application.

• user_periph_setup.c: source code file that handles peripheral configuration and initialization.

3.1.2.6. sdk Directory

This directory holds the core files of the SDK. The directory structure of the core SDK modules is depicted below.

Figure 23 sdk Directory Structure

3.1.2.6.1. app_modules Directory

This directory holds the application source and header files.

• api: contains the application header files.

• src: contains the application’s project specific code for some BLE profiles and handling functions for BLE operations, like advertising, connection, security/encryption, etc.

3.1.2.6.2. ble_stack Directory

This directory contains BLE stack related files.

3.1.2.6.3. common_project_files Directory

This directory contains the following folders plus three configuration header files.

Figure 24 common_project_files Directory Structure

• ldscripts: contains GNU LD linker scripts for the DA1453x/DA1458x SoC.

• misc: contains the ROM symbol definition files. This file will be used as input into the linker to create the final executable. The executable files, as well as the compilation outputs, are saved in a newly created directory named out_DA14531, out_DA14531_01,out_DA14535, out_DA14585 or out_DA14586, depending on the selected SoC.

• scatterfiles: contains Keil scatter files for the DA1453x/DA1458x SoC.

The three configuration files are:

• da1458x_periph_setup.h: definitions of the used hardware platform.

• da1458x_scatter_config.h: definitions of the memory layout.

• da1458x_stack_config.h: definitions of the stack.

3.1.2.6.4. platform Directory

This directory contains the platform specific files for the Arm Cortex-M0 processor and its supported peripherals (BLE, serial interfaces, GPIOs, etc.).

• arch: contains the system files and the main() application function.

• core_modules: contains core system modules, like the kernel that implements the message handling, the GTL implementation, the non-volatile data storage manipulation, RF drivers, etc.

• driver: contains all the supported drivers for the Arm Cortex-M0 peripherals.

• include: header files of the core source files.

• system_library: contains the object files of the patched ROM functions and the code for the RF calibration. More information for the patched functions is given in the Release Notes of the SDK distribution.

• utilities: contains the system utilities modules, like OTP header and OTP Configuration Script, it contains also the Flexible Software Package (FSP) external processor user applicatioon source code.

3.1.2.7. third_party Directory

This directory holds any third-party source file that is used within the SDK.

Figure 25 third_party Directory Structure

3.1.2.8. utilities Directory

This directory holds utilities and tools that supplement the SDK.

Figure 26 utilities Directory Structure

• flash_programmer: Flash programmer for DA1453x/DA1458x SoC. For more detailed information, see Appendix Section 6.4.

• prod_test: production test utility. For more detailed information, see Appendix Section 6.3.

• secondary_bootloader: secondary bootlader utility. For more detailed information, see Appendix Section 6.2.

• mkimage: make image tool. For more detailed information, see Appendix Section 6.2.4.4.

3.2. Proximity Reporter: Your First Bluetooth Low Energy Application

3.2.1. Application Description

The Proximity profile defines the behavior of a Bluetooth device when it moves away from a peer device so that either the connection is dropped or the path loss increases above a predefined level. Either of these conditions will cause an immediate alert. This alert can be used to notify the user that the devices have become separated.

The Proximity profile can also be used to define the behavior of two devices which are coming closer together such that either a connection is made or the path loss decreases below a predefined level.

The Proximity profile defines two roles:

• Proximity Monitor (PM): The Proximity Monitor shall be a GATT client

• Proximity Reporter (PR): The Proximity Reporter shall be a GATT server

This section describes only the Proximity Reporter application.

Note

The Proximity Reporter application supports entering deep sleep mode (e.g. shipping mode – when the device is not yet activated by the end customer). Upon wakeup, application execution will not restart. To restart execution after wakeup the developer must program the code to OTP or to external flash memory resource (e.g. SPI flash).

3.2.2. User Interface

The application will notify the user when an alert indication, link loss and immediate alert are triggered. The Alert Notification will be:

• High level alert: A fast (500 ms) LED blinking

• Low level alert: A slow (1500 ms) LED blinking

The user can stop alert notification by pressing a push button. The selected LED and push button (port and pin number of the DA1453x/DA1458x) are defined by the user configuration depending on the target device (DA1453x/DA1458x). The user file user_periph_setup.h holds the peripheral configuration settings of the LED and push button.

3.2.3. Loading the Project

The Proximity Reporter application, in particular, may be built and run, using any of the following IDEs, out of the box: Keil; e² studio, Eclipse AND IAR. For each of the aforementioned IDEs, there is a dedicated folder – including all the necessary project files – residing in <sdk_root_directory>\projects\target_apps\ble_examples\prox_reporter, namely Keil_5, Eclipse, e² studio and IAR, respectively.

For the sake of simplicity, we will proceed to refer to the Keil IDE, unless explicitly mentioning e² studio, Eclipse or IAR.

Figure 27 shows the Keil project layout with emphasis on the user related files. These are included in the Keil project folders user_config, user_platform and user_app. These folders contain the user configuration files of the Proximity Reporter application.

Figure 27 Proximity Reporter Keil Project Layout

Important

e² studio SDK 6 Getting Started Guide

To start building a fully working solution on e2 studio and SDK6 you can refer to the e² studio SDK 6 Getting Started Guide.

3.2.4. Going Through the Code

3.2.4.1. Basic Operation

The Proximity Reporter application supports the following services:

• Immediate Alert service (UUID 0x1802)

• Link Loss service (UUID 0x1803)

• Tx Power service (UUID 0x1804)

• Device Information service (UUID 0x180A)

• Battery service (UUID 0x180F)

• Software Update Over The Air Receiver (SUOTAR) service (UUID 0xFEF5)

The Proximity Reporter application has the following features:

• Two levels of Alert Indications. Low/High -> Slow/Fast green LED blinking.

• 500 ms advertising interval.

• Extended sleep without OTP copy mode after 3 minutes of inactivity.

• Push button.

• Stop Alert indications.

• Exit Extended sleep without OTP copy mode.

• Pairing / bonding / encryption.

• Supports Extended / Deep sleep mode/ Hibernation / Stateful hibernation (the last two modes being applicable to DA1453x only).

The Proximity Reporter operation is implemented in C source file user_proxr.c.

3.2.4.2. Initialization

The previously mentioned Keil project folders (user_config, user_platform and user_app), contain the files that initialize and configure the Proximity Reporter application.

user_config

• da1458x_config_advanced.h: holds DA1453x/DA1458x advanced configuration settings

• da1458x_config_basic.h: holds DA1453x/DA1458x basic configuration settings

• user_callback_config.h: callback functions that handle various events or operations

• user_config.h: holds advertising parameters, connection parameters, etc.

• user_modules_config.h: defines which application modules are included or excluded from the user’s application For example:

#define EXCLUDE_DLG_DISS          (0)

In this case the Device information application profile is included in the core SDK and the SDK takes care of the Device information application profile message handling internally.

#define EXCLUDE_DLG_DISS          (1)

In this case the Device information application profile is excluded from the core SDK. The user application must take care of the Device information application profile message handling.

• user_profiles_config.h defines which BLE profiles (Bluetooth SIG adopted or custom ones) will be included in the user’s application. The BLE profiles that are included in the user_profile_config.h file are:

/***************************************************************************************/
/* Used BLE profiles (used by "rwprf_config.h").                                       */
/***************************************************************************************/

#define CFG_PRF_DISS
#define CFG_PRF_PXPR
#define CFG_PRF_SUOTAR
#define CFG_PRF_BASS

• CFG_PRF_DISS: includes the Device Information service

• CFG_PRF_PXPR: includes the Immediate Alert, Link Loss and Tx Power services

• CFG_PRF_SUOTAR: includes the Software Update Over The Air service

• CFG_PRF_BASS: includes the Battery service

user_platform

• user_periph_setup.h: holds hardware related settings relative to the Development Kit

• user_periph_setup.c: source code file that handles peripheral (GPIO, UART, etc.) configuration and initialization relative to the selected Development Kit

user_app

• user_proxr.c & user_proxr.h: proximity reporter application source and header files

These files provide the main application, and define what to do when a button is pressed, when a connection is dropped or when adverting stops. These are all implemented as user callbacks as described in the next section. The trigger mechanism used to wake up from deep sleep or hibernation is also defined, as it is demonstrated in the proximity reporter application:

• CFG_DEEP_SLEEP_WAKEUP_GPIO – An external wake up interrupt (instantaneous button press) triggers the system to wake up from deep sleep.

• CFG_DEEP_SLEEP_WAKEUP_POR – A power on reset (POR) source (continuous button press for approximately 3 seconds, by default) triggers the system to wake up from deep sleep.

• CFG_DEEP_SLEEP_WAKEUP_RTC – An RTC interrupt triggers the system to wake up from deep sleep after 10 seconds (applicable to DA1453x only).

• CFG_DEEP_SLEEP_WAKEUP_TIMER1 – A Timer1 interrupt triggers the system to wake up from deep sleep after 136.47 ms (= 2047 clock cycles * (1 / 15 ms/clock cycle)) if Timer1 uses the internal RCX oscillator whose typical frequency is 15 kHz or after 62.47 ms (= 2047 clock cycles * (1 / 32.768 ms/clock cycle)) if Timer1 uses an external XTAL oscillator whose typical frequency is 32.768 kHz (applicable to DA1453x only).

• CFG_APP_GOTO_HIBERNATION – Wake up the system from specific GPIO (P0_3) (applicable to DA1453x only).

• CFG_APP_GOTO_STATEFUL_HIBERNATION – Wake up the system from specific GPIO (P0_3) (applicable to DA1453x only).

Note

When defining either CFG_APP_GOTO_HIBERNATION or CFG_APP_GOTO_STATEFUL_HIBERNATION, CFG_SPI_FLASH_ENABLE in da1458x_config_basic.h shall be undefined. Otherwise, a compilation error – “Config error: Can not define both CFG_SPI_FLASH_ENABLE and CFG_APP_GOTO_HIBERNATION/CFG_APP_GOTO_STATEFUL_HIBERNATION.” – will occur.

Furthermore, if SUOTAR is to be used, CFG_I2C_EEPROM_ENABLE in da1458x_config_basic.h shall be defined instead (if not, a compilation error – “SUOTA application is enabled but both I2C EEPROM and SPI Flash are disabled” – will occur). If SUOTAR will not be used, #define EXCLUDE_DLG_SUOTAR (1) in user_modules_config.h shall be defined and CFG_PRF_SUOTAR in user_profiles_config.h shall be undefined.

Note

For more information about the Hibernation mode of DA1453x, see the respective datasheet.

Note

If none of the above-mentioned DEEP_SLEEP flags is defined, the system does not enter the Deep sleep mode, but the selected Extended sleep mode (as defined in the user_config.h file). The system exits the Extended sleep mode, if the user presses the button that causes advertising to restart. In the case of DA1453x, the system may alternatively exit the Extended sleep mode through an RTC interrupt (if CFG_EXT_SLEEP_WAKEUP_RTC is defined) or a Timer1 interrupt (if CFG_EXT_SLEEP_WAKEUP_TIMER1 is defined).

Note

When the system enters the Deep sleep mode, all the RAM blocks are switched off. No application code or data are retained.

Note

When the system exits the Deep sleep mode, the boot rom code is executed and the application code has to be loaded again, either from OTP memory or external memory source (e.g. SPI flash).

3.2.4.3. Events Processing and Callbacks

Several events can occur during the lifetime of the Bluetooth low energy application and these events need to be handled in a specific manner. The application is responsible to select which events and operations to handle and which to leave to be handled by the default SDK behavior.

The SDK uses a mechanism that registers callbacks for every event or operation that defines the system behavior. The C header file user_callback_config.h, which is part of the user application, contains the registration of callback functions.

The Proximity Reporter application registers the following callback functions:

• General BLE events:

static const struct app_callbacks user_app_callbacks = {
    .app_on_connection                  = default_app_on_connection,
    .app_on_disconnect                  = user_app_on_disconnect,
    .app_on_update_params_rejected      = NULL,
    .app_on_update_params_complete      = NULL,
    .app_on_set_dev_config_complete     = default_app_on_set_dev_config_complete,
    .app_on_adv_nonconn_complete        = NULL,
    .app_on_adv_undirect_complete       = app_advertise_complete,
    .app_on_adv_direct_complete         = NULL,
    .app_on_db_init_complete            = default_app_on_db_init_complete,
    .app_on_scanning_completed          = NULL,
    .app_on_adv_report_ind              = NULL,
    .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       = default_app_update_params_request,
    .app_on_generate_static_random_addr = default_app_generate_static_random_addr,
    .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                     = default_app_on_tk_exch,
    .app_on_irk_exch                    = NULL,
    .app_on_csrk_exch                   = NULL,
    .app_on_ltk_exch                    = default_app_on_ltk_exch,
    .app_on_pairing_succeeded           = NULL,
    .app_on_encrypt_ind                 = NULL,
    .app_on_encrypt_req_ind             = NULL,
    .app_on_security_req_ind            = NULL,
    .app_on_addr_solved_ind             = NULL,
    .app_on_addr_resolve_failed         = NULL,
#if !defined (__DA14531_01__) && !defined (__DA14535__)
    .app_on_ral_cmp_evt                 = NULL,
    .app_on_ral_size_ind                = NULL,
    .app_on_ral_addr_ind                = NULL,
#endif // not for DA14531-01, DA14535
};
#endif // (BLE_APP_SEC)

The structure above defines whether each event is processed by a default handler, by a user-defined handler or is not processed at all (NULL entries). The user defined handlers (e.g. app_advertise_complete()) are defined in a C source file user_proxr.c.

• System specific events:

static const struct arch_main_loop_callbacks user_app_main_loop_callbacks = {
    .app_on_init            = default_app_on_init,

    // By default the watchdog timer is reloaded and resumed when the system wakes up.
    // The user has to take into account the watchdog timer handling (keep it running,
    // freeze it, reload it, resume it, etc.), when the app_on_ble_powered() is being
    // called and may potentially affect the main loop.
    .app_on_ble_powered     = NULL,

    // By default the watchdog timer is reloaded and resumed when the system wakes up.
    // The user has to take into account the watchdog timer handling (keep it running,
    // freeze it, reload it, resume it, etc), when the app_on_system_powered() is being
    // called and may potentially affect the main loop.
    .app_on_system_powered  = NULL,

    .app_before_sleep       = NULL,
    .app_validate_sleep     = NULL,
    .app_going_to_sleep     = NULL,
    .app_resume_from_sleep  = NULL,
};

The above structure defines that a certain event is processed by a default handler or by a user-defined handler or is not processed at all (NULL entries). In this case the default SDK application initialization function is used and all other events are not handled.

• BLE operations:

static const struct default_app_operations user_default_app_operations = {
    .default_operation_adv = default_advertise_operation,
};

The above structure defines that a certain operation is processed by a default handler or by a user-defined handler or is not processed at all (NULL entries). In this case only the default advertising operation is used.

Note

DA1453x/DA1458x SDK supports the URI data type in advertising and/or scan response packets. The URI data type allows the representation of a URI. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource, as defined in IETF STD66.

An example implementation of a URI can be seen in the advertising data of the proximity reporter demo application. Please check ADV_TYPE_URI in the USER_ADVERTISE_DATA definition in the usef_config.h file of the project.

#define USER_ADVERTISE_DATA   ("\x09"\
                              ADV_TYPE_COMPLETE_LIST_16BIT_SERVICE_IDS\
                              ADV_UUID_LINK_LOSS_SERVICE\
                              ADV_UUID_IMMEDIATE_ALERT_SERVICE\
                              ADV_UUID_TX_POWER_SERVICE\
                              ADV_UUID_SUOTAR_SERVICE\
                              "\x10"\
                              ADV_TYPE_URI\
                              "\x16\x2F\x2F\x77\x77\x77\x2E\x69\x61\x6E\x61\x2E\x6F\x72\x67")

3.2.5. BLE Application Abstract Code Flow

Figure 28 shows the abstract code flow diagram of the Proximity Reporter application. The diagram depicts the SDK interaction with the callback functions registered in user_callback_config.h and the functions implemented in user_proxr.c. The user configuration block purely executes the callbacks defined for these operations and events. It simply calls the default handlers for each of the events until adverting is started. The first user-defined callback is app_advertise_complete(), which is plugged into the callback table as .app_on_adv_undirect_complete().

Figure 28 Proximity Reporter - User Application Code Flow

The default advertising function is default_advertise_operation(), as shown in the following code snippet, and is located in <sdk_default_directory>\sdk\app_modules\src\app_default_hnd.

void default_advertise_operation(void)
{
    if (user_default_hnd_conf.adv_scenario == DEF_ADV_FOREVER)
    {
        app_easy_gap_undirected_advertise_start();
    }
    else if (user_default_hnd_conf.adv_scenario == DEF_ADV_WITH_TIMEOUT)
    {
        app_easy_gap_undirected_advertise_with_timeout_start(user_default_hnd_conf.advertise_period, NULL);
    }
}

The parameters of the default_advertise_operation() can be configured in the user_config.h file located in <sdk_default_directory>\projects\target_apps\ble_examples\prox_reporter\src\config as shown in the following code snippet. This specifies that the advertising is to last 3 minutes and that there is no security defined for the connection.

static const struct default_handlers_configuration  user_default_hnd_conf = {
    // Configure the advertise operation used by the default handlers
    // Possible values:
    //  - DEF_ADV_FOREVER
    //  - DEF_ADV_WITH_TIMEOUT
    .adv_scenario = DEF_ADV_WITH_TIMEOUT,

    // Configure the advertise period in case of DEF_ADV_WITH_TIMEOUT.
    // It is measured in timer units (3 min). Use MS_TO_TIMERUNITS macro to convert
    // from milliseconds (ms) to timer units.
    .advertise_period = MS_TO_TIMERUNITS(180000),

    // Configure the security start operation of the default handlers
    // if the security is enabled (CFG_APP_SECURITY)
    // Possible values:
    //  - DEF_SEC_REQ_NEVER
    //  - DEF_SEC_REQ_ON_CONNECT
    .security_request_scenario = DEF_SEC_REQ_NEVER
};

The app_advertise_complete() user function is used to define the specific behavior that the application has when the 3-minute advertising period is finished. As shown in the code snippet below, this is to stop any active alert, enable a button to wake up from deep sleep and then to enter deep sleep. For DA1453x the wake-up source may alternatively be RTC or Timer1.

It should be highlighted that two power modes have been introduced for DA1453x only, namely hibernation and stateful hibernation. Both modes are clockless ones, while RAM block(s) may or may not be retained:

• When in hibernation, no code/data is retained (see the hibernation mode configuration in user_proxr.h).

• When in stateful hibernation, all three RAM blocks are retained (see the stateful hibernation mode configuration in user_proxr.h). As soon as the device wakes up from stateful hibernation, both the processor state and system register content will be restored – code execution will resume from the point the device went to stateful hibernation onwards: the orange LED – D5 on the 376-18-B Motherboard – will be turned on for a couple of seconds. Then, the device will get idle (in the ARCH_SLEEP_OFF case) or go to extended sleep (in the ARCH_EXT_SLEEP_ON case), waiting for an interrupt to occur – by pressing the SW2 button on the 376-18-B Motherboard, the device will get active and restart advertising.

void app_advertise_complete(const uint8_t status)
{
    if ((status == GAP_ERR_NO_ERROR) || (status == GAP_ERR_CANCELED))
    {
#if (BLE_PROX_REPORTER)
         app_proxr_alert_stop();
#endif
    }

    if (status == GAP_ERR_CANCELED)
    {
        arch_ble_ext_wakeup_on();

#if defined (__DA14531__)
    // Configure PD_TIM
#if defined (CFG_EXT_SLEEP_WAKEUP_RTC) || defined (CFG_EXT_SLEEP_WAKEUP_TIMER1) || \
    defined (CFG_DEEP_SLEEP_WAKEUP_RTC) || defined (CFG_DEEP_SLEEP_WAKEUP_TIMER1)
    // Ensure PD_TIM is open
    SetBits16(PMU_CTRL_REG, TIM_SLEEP, 0);
    // Wait until PD_TIM is opened
    while ((GetWord16(SYS_STAT_REG) & TIM_IS_UP) != TIM_IS_UP);
#else
    // Close PD_TIM
    SetBits16(PMU_CTRL_REG, TIM_SLEEP, 1);
    // Wait until PD_TIM is closed
    while ((GetWord16(SYS_STAT_REG) & TIM_IS_DOWN) != TIM_IS_DOWN);
#endif
#endif

#if defined (CFG_APP_GOTO_DEEP_SLEEP)
    // Put system into deep sleep
    put_system_into_deep_sleep();
#elif defined (__DA14531__) && defined (CFG_APP_GOTO_HIBERNATION)
    // Put system into hibernation
    arch_set_hibernation(HIB_WAKE_UP_PIN_MASK,
                         CFG_HIBERNATION_RAM1,
                         CFG_HIBERNATION_RAM2,
                         CFG_HIBERNATION_RAM3,
                         CFG_HIBERNATION_REMAP,
                         CFG_HIBERNATION_PAD_LATCH_EN);
#elif defined (__DA14531__) && defined (CFG_APP_GOTO_STATEFUL_HIBERNATION)
    // Put system into stateful hibernation
    arch_set_stateful_hibernation(HIB_WAKE_UP_PIN_MASK,
                                  CFG_STATEFUL_HIBERNATION_RAM1,
                                  CFG_STATEFUL_HIBERNATION_RAM2,
                                  CFG_STATEFUL_HIBERNATION_RAM3,
                                  CFG_STATEFUL_HIBERNATION_REMAP,
                                  CFG_STATEFUL_HIBERNATION_PAD_LATCH_EN);
    #if (DEVELOPMENT_DEBUG)
        // Turn on the orange LED (D5 on the 376-18-B Motherboard)
        SetWord16(P09_MODE_REG, ((uint32_t) OUTPUT) | ((uint32_t) PID_GPIO));
        SetWord16(P0_SET_DATA_REG, 1 << GPIO_ALERT_LED_PIN);
        // Keep it on for a couple of seconds
        for (uint32_t i = 4*2000000; i != 0; i--)
        {
            __NOP();
        }
        // Turn it off
        SetWord16(P0_RESET_DATA_REG, 1 << GPIO_ALERT_LED_PIN);
    #endif // DEVELOPMENT_DEBUG

    // Configure button to trigger wake-up interrupt from extended sleep
    app_button_enable();
#elif defined (__DA14531__) && defined (CFG_EXT_SLEEP_WAKEUP_RTC)
    // Configure RTC to trigger wake-up interrupt from extended sleep
    configure_rtc_wakeup();
#elif defined (__DA14531__) && defined (CFG_EXT_SLEEP_WAKEUP_TIMER1)
    // Configure TIMER1 to trigger wake-up interrupt from extended sleep
    configure_timer1_wakeup();
#else
    // Configure button to trigger wake-up interrupt from extended sleep
    app_button_enable();
#endif
    }
}

Note

As far as stateful hibernation is concerned, besides defining CFG_APP_GOTO_STATEFUL_HIBERNATION in user_proxr.h, CFG_STATEFUL_HIBERNATION shall be defined as well in the project (assembly) settings, as shown in Figure 29, Figure 31, and Figure 32 for Keil, Eclipse, and IAR IDEs, respectively.

Figure 29 Defining CFG_STATEFUL_HIBERNATION in the Keil IDE

Figure 30 Defining CFG_STATEFUL_HIBERNATION in the e² studio IDE

Figure 31 Defining CFG_STATEFUL_HIBERNATION in the Eclipse IDE

Figure 32 Defining CFG_STATEFUL_HIBERNATION in the IAR IDE

3.2.6. Building the Project for Different Targets

The Proximity Reporter application can be built for different target processors, DA14585, DA14586, DA14531, DA14531_01, DA14535 and DA14533.

The selection is done with the Keil tool as shown in Figure 33.

Figure 33 Building the Project for Different Targets

In order to build proximity reporter project for DA14533 target, you select the DA14535 target and then add DA14533 define __DA14533__.

Figure 34 Building the Project for DA14533 Target

After the proper selection of the target processor, the application is ready to be built.

The Proximity Reporter application does not use the UART and so the only jumpers that must be present are those for the debugger interface as mentioned in Table 5.

Table 5 Debugger Jumper Configuration

Target	SW_CLK PIN	SW_CLK PIN DK connection	SW_DIO PIN	SD_DIO PIN DK connection
DA1458x	SW_CLK	Connect J1.21 with J1.22	SW_DIO	Connect J1.23 with J1.24
DA1453x	P0_2	Connect J1.21 with J1.22	P0_10	Connect J1.23 with J1.24

3.2.7. Interacting with BLE Application

The SmartBond™ application, available on iOS or Android, is a mobile application that works as a generic tool for interacting with Bluetooth® Low Energy devices. It used to scan for, and connect to, the DIALOG-PRXR. The iPhone/Android mobile acts as a BLE Central and the application as a BLE Peripheral.

Figure 35 Smartbond Application Connected to Proximity Reporter Application