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.
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:
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.
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.2. Link Layer (LL)
The Link Layer (LL) directly interfaces with the PHY. LL is the hard real-time constrained layer of the protocol stack, because LL has to comply with all the timing requirements defined in the specification. Given that many of the calculations done by the LL are computationally expensive, automated functions are usually implemented in hardware to avoid overloading the Central Processing Unit (CPU) that runs all software layers in the stack. Therefore, the LL implementation comes through a combination of custom hardware and software. The functionality that LL provides, usually includes: Preamble, Access Address, and air protocol framing, CRC generation and verification, data whitening, random number generation and AES encryption. LL is usually kept isolated from the higher layers of the protocol stack with an interface that hides this complexity and its real-time requirements.
The LL principally controls the Radio Frequency (RF) state of the device and manages the link state of the radio, which is how the device connects to other devices. A BLE device can be a master, a slave, or both depending on the use case and the corresponding requirements. A master is able to connect to multiple slaves and a slave can connect to multiple masters. Typically, devices such as smartphones or tablets tend to act as a master, while smaller, simpler, and memory-constrained devices such as standalone sensors generally adopt the slave role. A device can only be in one of the following five states: standby, advertising, scanning, initiating, or connected. See Figure 3:
Advertisers transmit data without being connected, while scanners listen for advertisers. An initiator is a device that is responding to an advertiser with a connection request. If the advertiser accepts, both the advertiser and initiator will enter in a connected state. When a device is in a connection state, the device will be connected in one of two roles: master or slave. Typically, devices that initiate connections will be masters and devices that advertise their availability and accept connections will be slaves. Therefore, the Link Layer defines the following roles:
Advertiser: A device sending advertising packets.
Scanner: A device scanning for advertising packets.
Master: A device that initiates a connection (initiator) and manages the connection later.
Slave: A device that accepts a connection request and follows the master’s timing.
These roles can be logically grouped into two pairs: advertiser and scanner (when not in an active connection) and master and slave (when in a connection).
1.8.2.1. Bluetooth Device Address
The Bluetooth device address is the primary identifier of a Bluetooth device, similar to what an Ethernet Media Access Control (MAC) address is for network devices. It is a 48-bit (6-byte) number that uniquely identifies a device among peers. There are two types of device addresses, and a device can obtain one or both types:
Public device address:
This is the equivalent to a fixed, factory-programmed device address as used in BR/EDR devices as well. It has to be registered with the Institute of Electrical and Electronics Engineers (IEEE) Registration Authority and should never change throughout the lifetime of the device.
Random device address:
This address can either be preprogrammed or dynamically generated on the device at runtime. There are numerous use cases in which such addresses are useful in BLE.
1.8.2.2. Advertising and Scanning
The BLE specification allows only one packet format and two types of packets: advertising and data.
Advertising packets are used for two purposes:
To broadcast data for applications that do not need the overhead of a full connection establishment
To discover slaves and then connect with slaves
Data packets are used for user data transport between the master and the slave devices, in a bi-directional manner.
Finally, the Link Layer acts as a reliable data bearer since all received packets are checked against a 24-bit Cyclic Redundancy Check (CRC) and retransmissions are scheduled when the error checking mechanism detects a transmission failure. Since there is no pre-defined retransmission upper bound, the Link Layer will continuously resend the packet until it is finally acknowledged by the receiver.
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.2. Logical Link Control and Adaptation Protocol
The Logical Link Control and Adaptation Protocol (L2CAP) layer provides data encapsulation services to the upper layers. As a result, L2CAP allows logical end-to-end communication with the use of data transfer. Essentially, L2CAP serves as a protocol multiplexer that takes multiple protocols from the upper layers and encapsulates them into the standard BLE packet format and vice versa. L2CAP is also responsible for package fragmentation and reassembly. During this process large packets originating from the upper layers of the transmitting side are fitted into the 27-byte maximum payload size of the BLE packets. The reverse process takes place on the receiving end, where the fragmented large upper layer packets are reassembled by multiple small BLE packets and transmitted upstream towards the appropriate upper level entity.
The L2CAP layer is in charge of routing two main protocols: the Attribute Protocol (ATT) and the Security Manager Protocol (SMP). Moreover, L2CAP can create its own user-defined channels for high-throughput data transfer, a feature called LE Credit Based Flow Control Mode.
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:
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:
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.