14. Enabling features on the Proximity Reporter application¶
The following paragraphs explain how to enable SmartSnippets™ DA1468x SDK features on the Proximity Reporter application (the same can be applied on any project). Modifications are needed depending the specific implementation of each project.
14.1. Enabling the Charger¶
A very useful feature that Proximity Reporter provides is the ability to enable the charger. The configuration of the Charger can be divided in three parts:
- Configuration of the USB.
- Charging algorithm configuration.
- Charging parameters.
For more information about the charger please refer to the Platform Reference Manual [Ref_04].
All these configuration options are defined in
config/custom_config_qspi_suota.h header file.
#define dg_configBATTERY_TYPE (BATTERY_TYPE_CUSTOM)
#define dg_configBATTERY_CHARGE_VOLTAGE 0xD // 4.35V
#define dg_configBATTERY_TYPE_CUSTOM_ADC_VOLTAGE (3563)
//#define dg_configBATTERY_LOW_LEVEL (2457) // 3V
#define dg_configPRECHARGING_THRESHOLD (2462) // 3.006V
#define dg_configCHARGING_THRESHOLD (2498) // 3.05V
#define dg_configBATTERY_CHARGE_CURRENT 2 // 30mA
#define dg_configBATTERY_PRECHARGE_CURRENT 20 // 2.1mA
#define dg_configBATTERY_CHARGE_NTC 1 // disabled
#define dg_configPRECHARGING_TIMEOUT (30 * 60 * 100) // N x 10msec
#define dg_configUSE_USB 1
#define dg_configUSE_USB_CHARGER 1
#define dg_configALLOW_CHARGING_NOT_ENUM 1
#define dg_configUSE_NOT_ENUM_CHARGING_TIMEOUT 0
14.2. Configuration for SUOTA¶
The following sections describe the Proximity Reporter demo from the SUOTA point of view. The steps need to enable/configure SUOTA in an application are the following:
- Create or modify a header file containing information about the version used for creating images.
- Add code to include the SUOTA in an application.
- Configure the application start address.
14.2.1. Version header file¶
Code 11 shows the content of sw_version.h, which is the header file that
should be modified whenever a new version is produced. This header file
is important because it is required by the mkimage tool in order to
create the new image file.
#define BLACKORCA_SW_VERSION "1.0.0.1"
#define BLACKORCA_SW_VERSION_DATE "2016-01-28 15:00"
#define BLACKORCA_SW_VERSION_STATUS "REPOSITORY VERSION"
14.2.2. Code analysis¶
All SUOTA-related lines of code are inside #if
dg_configSUOTA_SUPPORT #endif blocks. The preprocessor macro for
enabling the SUOTA is already in a configuration header file located in
<sdk_root_directory>/projects/dk_apps/demos/pxp_reporter/config/custom_config_qspi_suota.h:
#define dg_configSUOTA_SUPPORT (1)
The desired SUOTA version is defined using the SUOTA_VERSION definition.
SUOTA version v1.1 (SUOTA_VESRION_1_1) allows the application to be
upgraded only over GATT, whereas versions v1.2, v1.3 (SUOTA_VERSION_1_2,
SUOTA_VERSION_1_3) allow the application to be upgraded both over GATT
and L2CAP COC. To enable SUOTA over L2CAP COC, SUOTA_PSM should also be
defined, in addition to SUOTA_VERSION. This definition specifies the PSM
that must be used to establish the L2CAP COC connection.
/*
* SUOTA loader configuration:
* - To enable SUOTA over GATT only, set SUOTA_VERSION to any version >= SUOTA_VERSION_1_1
* and leave SUOTA_PSM undefined.
* - To enable SUOTA over GATT and L2CAP CoC, set SUOTA_VERSION to any version >= SUOTA_VERSION_1_2
* and also define SUOTA_PSM to match the desired PSM. In this case the central device
* can use either of both according to its preference.
*/
#define SUOTA_VERSION SUOTA_VERSION_1_3
#define SUOTA_PSM 0x81
In addition, when support for L2CAP COC is enabled (SUOTA_PSM is
defined), L2CAP related events should be passed from the application to
the SUOTA service as shown in Code 14.
#if dg_configSUOTA_SUPPORT && defined (SUOTA_PSM)
case BLE_EVT_L2CAP_CONNECTED:
case BLE_EVT_L2CAP_DISCONNECTED:
case BLE_EVT_L2CAP_DATA_IND:
suota_l2cap_event(suota, hdr);
break;
#endif
For SUOTA to be enabled in the Proximity Reporter application, the
pxp_reporter_task.c should be modified accordingly. The code snippet
presented in Code 15 should be included in the pxp_reporter_task()
function to declare the variable that handles the service:
ble_service_t *suota;
Additionally, the SUOTA service should be initialized and added to the BLE framework, inside the same function. This service is the starting point where all services are created. In addition, it is important to add the Device Information Service (DIS) as Android and iOS applications relies on DIS, as shown in Code 16.
/* Register SUOTA
*
* SUOTA instance should be registered in ble_service framework in order for events
* inside service to be processed properly.
*/
suota = suota_init(&suota_cb);
OS_ASSERT(suota != NULL);
/*
* Register DIS
*
* DIS doesn't contain any dynamic data thus it doesn't need to be registered in
* ble_service framework (but it's not an error to do so).
*/
dis_init(NULL, &dis_info);
Code 17 shows the required data for the DIS standard BLE service. This project uses the same header file version for both building the image and for providing data for the DIS.
/* Device Information Service data
*
* Manufacturer Name String is mandatory for devices supporting HRP.
*/
static const dis_device_info_t dis_info = {
.manufacturer = "Dialog Semiconductor",
.model_number = "Dialog BLE",
.serial_number = "123456",
.hw_revision = "REV.D",
.fw_revision = "1.0",
.sw_revision = BLACKORCA_SW_VERSION,
};
The header files shown in Code 18 must be included to build these changes.
#include "dis.h"
#include "dlg_suota.h"
#include "sw_version.h"
In order to make the SUOTA process operational, the SUOTA service has to be included in the advertising data.
/*
* PXP advertising and scan response data
* While not required, PXP specification states that PX reporter device using
* peripheral role can advertise support for LLS. Device name is set in scan
* response to make it easily recognizable.
*/
static const uint8_t adv_data[] = {
#if dg_configSUOTA_SUPPORT
0x07, GAP_DATA_TYPE_UUID16_LIST_INC,
0x03, 0x18, // = 0x1803 (LLS UUID)
0x02, 0x18, // = 0x1802 (IAS UUID)
0xF5, 0xFE, // = 0xFEF5 (DIALOG SUOTA UUID)
#if dg_configSUOTA_SUPPORT
0x07, GAP_DATA_TYPE_UUID16_LIST_INC,
0x03, 0x18, // = 0x1803 (LLS UUID)
0x02, 0x18, // = 0x1802 (IAS UUID)
0xF5, 0xFE, // = 0xFEF5 (DIALOG SUOTA UUID)
14.2.3. Application start address¶
SUOTA-enabled applications should be compiled for execution from address
0x20000.
The following lines are already there but it is likely that
CODE_BASE_ADDRESS is always set to 0x8000000. This does not work when a
bootloader is present. The modification required to CODE_BASE_ADDRESS is
highlighted with red font in Code 20.
# if (dg_configEXEC_MODE == MODE_IS_MIRRORED)
#warning "QSPI mirrored execution mode is not supported!"
#undef CODE_SIZE
#define CODE_SIZE 0
# else
#define CODE_BASE_ADDRESS 0x8000000 + dg_configIMAGE_FLASH_OFFSET
#define RAM_BASE_ADDRESS 0x7FC0000
# endif
These changes are not sufficient in themselves and the application still
builds from address 0 unless dg_configIMAGE_FLASH_OFFSET is defined.
In case of the Proximity Reporter application, this macro is defined in
the config/custom_config_qspi_suota.h file. Code 21 defines the correct
starting address.
#define dg_configIMAGE_FLASH_OFFSET (0x20000)
The Proximity Reporter includes two configurations: one without the
SUOTA functionality, which allows building an application for address
0x0, and another one with the SUOTA functionality, which builds for
address 0x20000.