1. Introduction

The aim of this document is to serve as a reference to the Embedded Software Developers, to provide a kick-start with a practical and high-level comprehension on Bluetooth low energy (BLE) standards. It gives a system architecture and software architecture overview for the DA1453x/DA1458x System on Chip (SoC) family of integrated circuit (IC) devices.

Important

Document Updates for SDK6.0.22 Release

The latest features and enhancements introduced in the recent SDK 6.0.22 release are detailed in the document, here is a quick summary. The new SDK:

  • Includes support for e² studio and LLVM compiler for enhanced development support. Refer to Section 3.2.3.

  • Implement necessary modifications to enable the DA1453x to boot from an external Renesas microcontroller via UART interface. Refer to Section 4.2.1.

  • Experimental supports for new device DA14533. Refer to Section 3.2.6.

  • Incorporate support for profiles Pulse Oximetry Service Server Role (PLXS) and Continuous Glucose Monitoring Service Server Role (CGMS). Refer to Section 2.4.4.

  • Includes various fixes and improvements. Refer to the SDK6 Known Limitations List.

Note

In this document:

  • DA1453x is refering to DA14531-00, DA14531-01, DA14530 and DA14535.

  • DA1458x is refering to DA14585 and DA14586.

  • The DA14531-00 is the main DA14531 device. The -00 is just a new naming to introduce the variant DA14531-01. The DA14531-01 is a ROM variant of the main DA14531-00.

  • The DA14535 is a DA14531 upgrade.

Table 1 presents the differentiation among the variants of the DA1453x concerning the BLE features and SDK support.

Table 1 DA1453x Product Variants Differentiation

BLE Features

DA14531

DA14531-01

DA14535

BLE Central support

YES

NO

YES

BLE Observer support

YES

NO

YES

LL Privacy feature (privacy on the controller side)

YES

NO

NO

Compatible with SDK 6.0.12 or higher

YES

NO

NO

Compatible with SDK 6.0.18

YES

YES

NO

Compatible with SDK 6.0.22 or higher

YES

YES

YES

Note

  • The DA14530 is pin-for-pin compatible with the DA14531 and provides cost savings by operating from an internal LDO (no internal DCDC converter), eliminating the cost of a DC/DC inductor.

Note

  • The SmartBond™ DA14586 is a SoC with an integrated Flash (2 Mbit). The DA14586 is pin-to-pin compatible with the DA14585.

1.1. Target Audience

This document is aimed at Embedded Software Developers / Embedded Firmware Engineers that work on application development with SmartBond™ DA1453x/DA1458x devices based on the DA1453x/DA1458x System on Chip (SoC) platform.

Developers who are new to the DA1453x/DA1458x System on Chip (SoC) platform are advised to scan through the entire document in order to get familiar with what is covered, and where to find specific information.

Experienced Embedded Firmware developers will be able to to dive deep into the SDK after going through some key chapters and technical documentation along with the provided example applications. This will give a better understanding on Renesas’s DA1453x/DA1458x Bluetooth® low energy devices and how to best utilize the capabilities offered by Renesas’s DA1453x/DA1458x SoC platform.

1.2. Device Modes

Devices that support both BLE and Basic Rate (BR) / Enhanced Data Rate protocol (EDR) are referred as dual-mode devices. Typically, inside the Bluetooth ecosystem a mobile phone or laptop computer is considered a dual-mode device, unless specifically stated otherwise. Devices that only support BLE are referred to as single-mode devices.

1.2.1. Single Mode Devices

A single-mode (BLE or Bluetooth Low Energy) device, implements only BLE and is able to communicate with both single-mode and dual-mode devices. However, not with devices that support only BR/EDR. BLE support is a must-have for single-mode devices to handle incoming messages and issue a response.

1.2.2. Dual Mode Devices

A dual-mode BR/EDR/LE, Bluetooth Low Energy Ready device, implements both BR/EDR and BLE and is able to communicate with any Bluetooth device.

1.3. Main Building Blocks

In the classic Bluetooth standard, the protocol stack consists of two blocks: the Controller and the Host. In Bluetooth BR/EDR devices, these two are usually implemented separately. However, more up-to-date Bluetooth devices include an increased number of building blocks. The main building blocks that exist in almost every Bluetooth device are the following:

  • The Application that uses the Bluetooth protocol stack interface to implement a particular use case

  • The Host that contains the upper layers of the Bluetooth protocol stack

  • The Controller that contains the lower layers of the Bluetooth protocol stack, including the radio

Bluetooth specifications also offer a standard communication protocol between the host and the controller called Host Controller Interface (HCI), which allows interoperability between hosts and controllers when these are developed by different entities.

1.4. Hardware Configurations

These main building blocks can be implemented in a single integrated circuit (IC) or System on Chip (SoC) device, or can be split and executed in more than one IC that is connected through a suitable communication interface and protocol (UART, USB, SPI, or other).

1.4.1. Integrated Processor

Most sensor applications tend to use the integrated processor (SoC) hardware configuration as it drives overall system complexity and associated printed circuit board (PCB) realization costs lower.

1.4.2. External Processor

Powerful computing devices like smartphones and tablets usually opt for the external processor, with the corresponding HCI protocol, which may be either proprietary or standard. This approach also allows additional BLE connectivity with specialized microcontrollers to be integrated without modifying the overall design.

Figure 1 shows a comparison between the two approaches when Bluetooth is implemented:

../_images/image1.png

Figure 1 Integrated vs. External Processor BLE Hardware Configurations

1.5. Network Modes

BLE devices use two distinct communication methods, each with certain benefits and limitations: Broadcasting and Connecting. Both methods follow certain procedures established by the Generic Access Profile (GAP).

1.5.1. Broadcasting

When connectionless broadcasting is used, a BLE device sends data out to any scanning device or receiver that is within acceptable listening range. Essentially, this mechanism allows a BLE device to send data out one-way to anyone or anything that is capable of picking up the transmission.

Broadcasting defines two separate roles:

  • Broadcaster: Sends non-connectable advertising packets periodically to anyone willing to receive them.

  • Observer: Repeatedly scans the pre-set frequencies to receive any non-connectable advertising packets.

Broadcasting is the only way for a device to transmit data to more than one peer at a time. These broadcasted data are sent out with the use of the advertising features of BLE.

1.5.2. Connecting

For bi-directional data transmission in BLE, a connection needs to be present. A BLE connection is nothing more than an established, periodical exchange of data at specific points in time (connection events) between the two involved BLE peers. Typically, data is exchanged only between the two BLE connection peers, and no other device is involved. Connections define two separate roles:

  • Central (master): Repeatedly scans the pre-set BLE frequencies for connectable advertising packets and, when suitable, initiates a connection. Once the connection is established, the central manages the timing and initiates periodical data exchange.

  • Peripheral (slave): A device that sends connectable advertising packets periodically and accepts incoming connections. Once in an active connection, the peripheral follows the central’s timing and regularly exchanges data with the central device.

For a connection to be initiated, the central device picks up the connectable advertising packets from a peripheral and then sends a request to the peripheral device to establish an exclusive connection between the two devices. Once the connection is established, the peripheral stops advertising and the two devices can begin exchanging data in both directions. Although the central is the device that manages the connection establishment, data can be sent independently by either device during each connection event, and the roles do not impose restrictions in data throughput or priority. It is therefore possible for a device to act as a central and a peripheral at the same time, for a central device to be connected to multiple peripherals as well as for a peripheral device to be connected to multiple centrals.

Connections provide the ability to organize data with much finer-grained control over each field or property through the use of additional protocol layers and, more specifically, the Generic Attribute Profile (GATT). Data is organized around units called services and characteristics. Moreover, connections allow for higher throughput and have the ability to establish a secure encrypted link, as well as negotiation of connection parameters to fit the data model.

A BLE device can have multiple services and characteristics, organized in a meaningful structure. Services can contain multiple characteristics, each with their own access rights and descriptive metadata.

1.6. Profiles

The Bluetooth specification clearly separates the concept of Protocol and Profile. This distinction is made due to the different purposes each concept serves. The overall specifications are divided into:

  • Protocols: are the building blocks used by all devices that conform to the Bluetooth specification. Protocols essentially form the layers that implement the different packet formats, routing, multiplexing, encoding, and decoding that allow data to be sent effectively between peers.

  • Profiles: are vertical slices of functionality that define either basic modes of operation required by all devices (such as the Generic Access Profile and the Generic Attribute Profile) or specific use cases (Proximity Profile, Glucose Profile); profiles essentially specify how protocols should be used to achieve a particular objective, whether generic or specific.

1.6.1. Generic Profiles

Generic profiles are defined by the Bluetooth specification. Two profiles are fundamental, as they ensure the interoperability between BLE devices from different vendors:

  • Generic Access Profile (GAP): Specifies the usage model of the lower-level radio protocols to define roles, procedures, and modes that allow devices to broadcast data, discover devices, establish connections, manage connections, and negotiate security levels; GAP is essentially, the uppermost control layer of BLE. This profile is mandatory for all BLE devices, and all must comply with GAP.

  • Generic Attribute Profile (GATT): Addresses data exchange in BLE and specifies the basic data model and procedures to allow devices to discover, read, write, and push data elements between them. It is basically, the top most data layer of BLE.

GAP and GATT are so fundamental to BLE that they are often used as the base for the provision of application programming interfaces (APIs) that act as the entry point for the application to interact with the protocol stack.

1.6.2. Use-Case-Specific Profiles

Use-case-specific profiles are usually limited to GATT-based profiles. Largely all of these profiles use the procedures and operating models of the GATT profile as a base building block for all further extensions. However, version 4.1 of the specification introduces Logical Link Control and Adaptation Protocol (L2CAP) connection-oriented channels, which indicates that GATT-less profiles are also possible.

1.6.2.1. SIG-Defined GATT-Based Profiles

The Bluetooth SIG provides a solid reference framework for the control and data layers of devices involved in a BLE network. It also provides a predefined set of use-case profiles based on GATT, that completely cover all procedures and data formats required to implement a wide range of specific use cases, like:

  • Find Me Profile: allows devices to physically locate other devices. For example, with the use of a smartphone to find a BLE enabled keyring, or vice versa.

  • Proximity Profile: detects the presence or absence of nearby devices. Beep if an item is forgotten when left in an area like a room.

  • HID over GATT Profile: transfers Human Interface Device (HID) data over BLE. For example, for keyboards, mice, remote controls.

  • Glucose Profile: securely transfers glucose levels over BLE.

  • Health Thermometer Profile: transfers body temperature readings over BLE.

The Bluetooth SIG Specification in its Adopted Documents page provides a full list of SIG-approved profiles (more information at https://www.bluetooth.com/specifications/adopted-specifications). A developer can also browse directly the list of all currently adopted services for the Bluetooth services and characteristics at the Bluetooth Developer Portal.

1.6.2.2. Vendor-Specific Profiles

The Bluetooth specification allows vendors to define their profiles for use cases that are not covered by the SIG-defined profiles. Those profiles can be kept private to the two peers involved in a particular use case (for example, a new sensor accessory and a smartphone application), or they can also be published by the vendor so that other parties can provide implementations of the profile based on the vendor-supplied specification. An example of a published vendor-specific profile is Apple’s iBeacon.

1.6.3. Generic Access Profile Layer

The Generic Access Profile (GAP) layer is responsible for the overall connection functionality. GAP handles the device’s access modes and procedures including device discovery, that directly interface with the application and/or profiles, and handle device discovery and connection-related services for the device. In addition, GAP takes care of the initiation of security features.

Essentially, GAP can be considered as the BLE top-most control layer, given that GAP specifies how devices carry out control procedures such as device discovery and to establish a secure connection. This is done to ensure interoperability and thus allow data exchange between devices from different vendors.

GAP specifies four roles that a device can adopt in a BLE network:

  • Broadcaster: The device is advertising with specific data, to let any device that initiates know, for example, that it is a device to which a connection can be made. This advertisement contains the device address and optionally additional data, such as the device name.

  • Observer: The scanning device, after an advertisement is received, sends a ‘scan request’ to the advertiser. The advertiser responds with a ‘scan response’. This is the process of device discovery, after which the scanning device is aware of the presence of the advertising device, and knows that a connection with the advertising device is possible.

  • Central: When a connection is initiated, the central device must specify a peer device address to connect to. If an Advertisement is received that matches the peer device’s address, the central device will then send out a request to establish a connection (link) with the advertising device. It will consider the particular connection parameters during connection establishment process.

  • Peripheral: Once a connection is established, the device will function as a slave if it was the advertiser and function as the master if it was the initiator.

Fundamentally, GAP establishes different sets of rules and concepts that regulate and standardize the low-level operation of devices. In particular:

  • The roles and interaction between them.

  • The operational modes and transitions across those devices.

  • The operational procedures to achieve consistent and interoperable communication.

  • All security aspects, including security modes and procedures.

  • Additional data formats for non-protocol data.

1.6.4. Generic Attribute Profile Layer

The Generic Attribute Profile (GATT) layer is a service framework that defines all sub-procedures to use the Attribute Protocol (ATT). GATT describes in full detail how profile and user data is to be exchanged over a BLE connection. In contrast to GAP, which defines the low-level interactions with devices, GATT deals only with actual data transfer procedures and formats.

GATT also provides the reference framework for all of the GATT-based profiles as defined by SIG. Effectively by covering the precise use cases for the profiles, GATT ensures interoperability between devices from different vendors. All the standard BLE profiles are therefore based on GATT and must comply with GATT to operate correctly. This makes GATT a key section of the BLE specification, since every data collection that is relevant to applications and users must be formatted, packed, and transmitted according to its rules.

GATT defines two roles for the interacting BLE devices:

  • Client: sends requests to a server, receives responses and potential server-initiated updates. The GATT client does not know anything in advance about the server’s attributes, so it must first inquire the presence and nature of those attributes by means of a service discovery. After the service discovery is completed, it starts to read and write attributes found on the server, as well as receive server-initiated updates. It corresponds to the ATT client.

  • Server: receives requests from a client and issues responses. It also sends server-initiated updates when configured to do so, and is the role responsible to store the user data and make the user data available to the client, organized in attributes. Every BLE device sold must include at least a basic GATT server that can respond to client requests, even if only to return an error response. It corresponds to the ATT server.

Know that GATT and GAP roles are completely independent, but concurrently compatible to each other. For instance, it is possible for both a GAP central and a GAP peripheral to act as a GATT client or server, or even both at the same time.

GATT uses ATT as a transport protocol for data exchange between devices. This data is organized hierarchically in sections called services, which groups conceptually related pieces of user data called characteristics.

1.7. Protocol Stack

Similar to all Bluetooth devices from an architectural point of view, a single-mode BLE device is divided into three blocks: controller, host, and application. Each of these basic building blocks consist of several layers, which make the device operational and tightly integrated in the so-called Protocol Stack. See Figure 2.

../_images/image2.png

Figure 2 BLE Protocol Stack Layers

The following sections provide a description of the aforementioned building blocks along with the layers that exist for each building block.

1.8. Controller

The Controller includes all the lower level functionality necessary for a BLE device to communicate. The Controller consists of a Physical Layer (PHY), a Link Layer (LL) and the controller side of the Host Controller Interface (HCI).

1.8.1. Physical Layer (PHY)

In the Physical Layer (PHY) a key block, among others, is the 1 Mbps adaptive frequency-hopping Gaussian Frequency-Shift Keying (GFSK) radio that operates in the unlicensed 2.4 GHz Industrial, Scientific, and Medical (ISM) band.

1.8.3. Host Controller Interface – Controller Side

The Host Controller Interface (HCI) at the Controller side, provides a means of communication to the host via a standardized interface. The Bluetooth specification defines HCI as a set of commands and events for the host and the controller to interact with each other, along with a data packet format and a set of rules for flow control and other procedures. Additionally, the spec defines several transports, each of which augments the HCI protocol for a specific physical transport (UART, USB, SDIO, etc.).

1.9. Host

The Host block consists of a set of layers, each with specific role and functionality, the cooperation of which makes the overall block operational. As shown in Figure 2 these layers are the Logical Link Control and Adaptation Protocol (L2CAP), the Attribute Protocol (ATT), the Security Manager (SM) and the Generic Attribute Profile (GATT) and Generic Access Profile (GAP).

1.9.1. Host Controller Interface – Host Side

The HCI interface at the Host side provides a means of communication to the controller via a standardized interface. Similar to the Controller Side HCI, implementation of this layer is established either through a software API, or over a hardware interface such as UART or SPI.

1.9.3. Attribute Protocol

The ATT layer enables a BLE device to provide certain pieces of data, known as attributes, to another BLE device. In the context of ATT, the device exposing attributes is referred to as the server, and the peer device interested and working with these attributes is referred to as the client. The Link Layer state (master or slave) of the device is independent from the ATT role of the device. For example, a master device may either be an ATT server or an ATT client, while a slave device may also be either an ATT server or an ATT client. It is also possible for a device to be both an ATT server and an ATT client simultaneously.

Essentially ATT is a simple client/server stateless protocol based on the attributes presented by a device. A client requests data from a server, and a server sends data to clients. The protocol is strict meaning that in case of a pending request (i.e. no response yet received for an already issued request) no further requests can be submitted until the response is received and processed. This applies to both directions independently in the situation where two peers are acting both as a client and server.

Each ATT server contains data organized in the form of attributes, each of which is assigned a 16-bit attribute handle called Universally Unique Identifier (UUID), a set of permissions, and finally a value. Effectively, the attribute handle is a mere identifier used to access an attribute value. The UUID specifies the type and nature of the data contained in the value. When a client wants to read or write attribute values from or to a server, it issues a read or write request to the server using the attribute handle. The server will respond with the attribute value or an acknowledgement. In the case of a read operation, it is up to the client to parse the value and understand the data type based on the UUID of the attribute. On the other hand, during a write operation, the client is expected to provide data that is consistent with the attribute type and the server is free to reject the operation if that is not the case.

1.9.4. Security Manager

The Security Manager (SM) layer defines the means for pairing and key distribution, and provides functions for the other layers of the protocol stack to securely connect and exchange data with another BLE device. The Security Manager includes both a protocol and a series of security algorithms that are designed to give the BLE protocol stack the ability to generate and exchange security keys to allow the peers, to communicate securely over an encrypted link, to trust the identity of the remote device, and if required, to hide the public Bluetooth Address. SM defines two roles:

  • Initiator: Always is the Central

  • Responder: Always is the Peripheral

In addition, SM provides support for the following three procedures:

  • Pairing: The procedure by which a security encryption key is generated and manipulated in order for the device to be able to switch to a secure and encrypted link. This key is temporary and not stored or available for subsequent connections.

  • Bonding: A sequence of pairing followed by the generation and exchange of permanent security keys, typically stored in non-volatile memory. Therefore, allows the creation of a permanent bond between two devices, which allows to quickly set up a secure link in subsequent connections without the need to do a bonding procedure again.

  • Encryption Reestablishment: After a bonding procedure is complete, keys might have been stored on both sides of the connection. If encryption keys have been stored, this procedure defines how to use those keys in subsequent connections to re-establish a secure, encrypted connection without having to go through the pairing (or bonding) procedure again.

Pairing can therefore create a secure link that will only last for the lifetime of the connection. On the other hand, bonding actually creates a permanent association (also called bond) in the form of shared security keys that will be used in later connections until either side decides to delete them. Certain documentation and APIs sometimes use the term pairing with bonding instead of simply bonding, since a bonding procedure always includes a pairing phase before.

Although it is always up to the initiator to trigger the beginning for a specific security procedure, the responder can asynchronously request the start of any of the procedures as listed above. However, there are no guarantees for the responder that the initiator will actually adhere to the request, rendering this to more of an optional rather than a binding request. This security request can logically be issued only by the slave or the peripheral end of the connection.

1.9.5. Application

The application, like in all other types of systems, is at the highest layer and the one responsible for containing the logic, user interface, and data handling of everything related to the actual use-case that the application implements. The architecture of an application is highly dependent on each particular implementation and in BLE it typically uses the capabilities provided by the BLE profiles.

1.10. DA1458x System on Chip Platform

1.10.1. Overview

The DA1458x platform includes a number of blocks as shown in Figure 4 and Figure 5:

../_images/image4.png

Figure 4 DA14585 System on Chip Platform Main Blocks

../_images/image6.png

Figure 5 DA14586 System on Chip Platform Main Blocks

In the following sections a brief overview of the platform’s main building blocks is given. For detailed information please see the specific device datasheet.

1.10.2. DA1458x Key Features

  • Complies with Bluetooth V5.0, ETSI EN 300 328 and EN 300 440 Class 2 (Europe), FCC CFR47 Part 15 (US) and ARIB STD-T66 (Japan)

  • Supports up to 8 Bluetooth LE connections

  • Fast cold boot in less than 50 ms

  • Processing power

    • 16 MHz 32 bit Arm® Cortex® M0 with SWD interface

    • Dedicated Link Layer Processor

    • AES-128 bit encryption Processor

  • Memories

    • 64 kB One-Time-Programmable (OTP) memory

    • 96 kB Data/Retention SRAM

    • 128 kB ROM

  • Power management

    • Integrated Buck/Boost DCDC converter

    • P0, P1 and P2 ports with 3.3 V tolerance

    • Easy decoupling of only 4 supply pins

    • Supports coin (typ. 3.0 V) and alkaline (typ. 1.5 V) battery cells

    • 1.8 V cold boot support

    • 10-bit ADC for battery voltage measurement

  • Digital controlled oscillators

    • 16 MHz crystal (±20 ppm max) and RC oscillator

    • 32 kHz crystal (±50 ppm, ±500 ppm max) and RCX oscillator

  • Flexible Reset Circuitry

    • System & Power On Reset in a single pin

  • General purpose, Capture and Sleep timers

  • Digital interfaces

    • Gen. purpose I/Os: 14 (WLCSP34), 25 (QFN40), 32 (QFN48)

    • 2 x UARTs with hardware flow control up to 1 Mbps

    • SPI+™ interface

    • I2C bus at 100 kHz, 400 kHz

    • 3-axes capable Quadrature Decoder

  • Analog interfaces

    • 4-channel 10-bit ADC

  • Radio transceiver

    • Fully integrated 2.4 GHz CMOS transceiver

    • Single wire antenna: no RF matching or RX/TX switching required

    • Supply current at VBAT3V:

    • TX: 3.4 mA, RX: 3.7 mA (with ideal DCDC)

    • 0 dBm transmit output power

    • -20 dBm output power in “Near Field Mode”

    • -93 dBm receiver sensitivity

  • Packages:

    • WLCSP 34 pins, 2.40 mm x 2.66 mm

    • QFN 40 pins, 5 mm x 5 mm

    • QFN 48 pins, 6 mm x 6 mm

Note

  • SPI™ is a trademark of Motorola, Inc.

1.11. DA1453x System on Chip Platform

1.11.1. Overview

The DA1453x platform includes a number of blocks as shown in Figure 6, Figure 7 and Figure 8:

../_images/image5.png

Figure 6 DA14531 System on Chip Platform Main Blocks

../_images/image7.png

Figure 7 DA14530 System on Chip Platform Main Blocks

../_images/da14535-block.png

Figure 8 DA14535 System on Chip Platform Main Blocks

In the following section a brief overview of the platform’s main building blocks is given. For detailed information please see the specific device datasheet.

1.11.2. DA14531 Key Features

  • Compatible with Bluetooth V5.1, ETSI EN 300 328 and EN 300 440 Class 2 (Europe), FCC CFR47 Part 15 (US) and ARIB STD-T66 (Japan)

  • Supports up to 3 BLE connections

  • Typical cold boot to radio active 35 ms

  • Processing power

    • 16 MHz 32-bit Arm® Cortex® M0+ with SWD interface

    • Dedicated Link Layer Processor

    • AES-128 Encryption Processor

    • Software-based certified True Random Number Generator (TRNG)

  • Memories

    • 32 kB One-Time-Programmable (OTP)

    • 48 kB Retainable System RAM

    • 144 kB ROM

  • Power management (See Note below)

    • Integrated Buck/Boost DCDC converter

    • Buck: 1.8 V ≤ VBAT_HIGH ≤ 3.3 V if OTP read needed

    • Buck: 1.1 V ≤ VBAT_HIGH ≤ 3.3 V if RAM retained

    • Boost: 1.1 V ≤ VBAT_LOW ≤ 1.65 V

    • Clock-less hibernation mode: Buck 270 nA, Boost 240 nA

    • 10-bit ADC for battery voltage monitoring

    • Built-in temperature sensor for die temperature monitoring

  • Digital controlled oscillators

    • 32 MHz crystal and 32 MHz RC oscillator

    • 32 kHz crystal and 32/512 kHz RC oscillator

  • 15 kHz RCX as 32 kHz crystal replacement

  • Programmable Reset Circuitry

  • 2× General purpose Timers with capture and PWM capabilities

  • Digital interfaces

    • GPIOs: 6 (WLCSP17), 12 (FCGQFN24)

    • 2× UARTs (one with flow control)

    • SPI Master/Slave up to 32 MHz (Master)

    • I2C bus at 100 kHz and 400 kHz

    • 3-axis capable Quadrature Decoder

    • Keyboard controller

  • Analog interfaces

    • 4-channel 10-bit ADC

  • Radio transceiver

    • Fully integrated 2.4 GHz CMOS transceiver

    • Single wire antenna

    • TX: 3.5 mA, RX: 2.2 mA (system currents with DC-DC, VBAT_HIGH =3 V and 0 dBm)

  • Programmable transmit output power from -19.5 dBm to +2.5 dBm

  • -94 dBm receiver sensitivity

  • Packages:

    • WLCSP 17 balls, 1.7 × 2.05, 0.5 mm pitch

    • FCGQFN 24 pins, 2.2 × 3, 0.4 mm pitch

Note

  • The DA14530 is pin-for-pin compatible with the DA14531 and provides cost savings by operating from an internal LDO, eliminating the cost of a DC/DC inductor.

  • SPI™ is a trademark of Motorola, Inc.

1.11.3. DA14535 Key Features

  • Compatible with Bluetooth V5.3, ETSI EN 300 328 and EN 300 440 Class 2 (Europe), FCC CFR47 Part 15 (US) and ARIB STD-T66 (Japan)

  • Supports up to 3 BLE connections

  • Typical cold boot to radio active 35 ms

  • Processing power

    • 16 MHz 32-bit Arm® Cortex® M0+ with SWD interface

    • Dedicated Link Layer Processor

    • AES-128 Encryption Processor

    • Software-based certified True Random Number Generator (TRNG)

  • Memories

    • 12 kB One-Time-Programmable (OTP)

    • 64 kB Retainable System RAM

    • 160 kB ROM

  • Power management

    • Integrated Buck/Boost DCDC converter

    • Buck: 1.8 V ≤ VBAT_HIGH ≤ 3.6 V

    • Boost: 1.2 V ≤ VBAT_LOW ≤ 1.65 V

    • Clock-less hibernation mode: Buck < 550 nA, Boost < 550 nA

    • Built-in temperature sensor for die temperature monitoring

  • Programmable Reset Circuitry

  • Clocks

    • 32 MHz crystal and 32 MHz RC oscillator

    • 32 kHz crystal and 32/512 kHz RC oscillator

  • 15 kHz RCX as crystal replacement

  • 2× General purpose Timers with capture and PWM capabilities

  • Digital interfaces

    • 12 x GPIOs

    • 2× UARTs (one with flow control)

    • SPI Master/Slave up to 32 MHz (Master)

    • I2C bus at 100 kHz and 400 kHz

    • 3-axis capable Quadrature Decoder

    • Keyboard controller

  • Analog interfaces

    • 4-channel 10-bit ADC

  • Radio transceiver

    • Fully integrated 2.4 GHz CMOS transceiver

    • Single wire antenna

    • TX: 3.6 mA, RX: 2.6 mA (system currents with DC-DC, VBAT_HIGH =3 V and 0 dBm)

  • Programmable transmit output power from -18 dBm to +4 dBm

  • -94 dBm receiver sensitivity

  • Packages:

    • FCGQFN 24 pins, 2.2 × 3, 0.4 mm pitch

Note

  • SPI™ is a trademark of Motorola, Inc.