Overview

In general, RSL15 handles the Bluetooth Low Energy protocol through a Bluetooth Low Energy stack, which is in charge of the upper protocol layers and Bluetooth Low Energy hardware (HW). User applications are not responsible for Bluetooth Low Energy hardware. Therefore, this topic presents a high-level overview of the design and how it works.

NOTE: In this documentation, BB refers to Bluetooth Low Energy hardware. While there is a type of baseband processing in the RFFE, take care not to confuse it with the BB controller terminology used here. Throughout this documentation, you can assume that BB controller or baseband controller always means the Bluetooth Low Energy hardware, unless it is clearly stated that the RFFE baseband is being referenced.

Since the Bluetooth Low Energy HW (BB controller or BB) acts like an individual hardware accelerator, the RSL15 SoC contains an interface block, the baseband controller interface (BBIF). This block is designed to allow the Arm Cortex-M33 processor to configure the BB controller or to obtain the required information and status from the BB block.

In the "Bluetooth Low Energy Baseband Controller Block Diagram" figure, the Bluetooth Low Energy HW block diagram and its interface to the other blocks of RSL15 are illustrated.

Figure: Bluetooth Low Energy Baseband Controller Block Diagram

The implementation supports the Bluetooth Low Energy features as follows:

  • Bluetooth 5.2 Specifications compliant
  • All packet types (Broadcasting / Advertising / Data / Control / Long Range)
  • Advertising Extension
  • Encryption/Decryption (AES-CCM)
  • Bit stream processing (CRC, Whitening)
  • Frequency hopping calculation (scheme #1 and scheme #2)
  • FDMA/TDMA/events formatting and synchronization
  • All device modes support (Broadcaster, Central, Observer, Peripheral)

The software stack schedules, configures, and manages the Bluetooth Low Energy events, while the BB controller processes the actual events, controls the RFFE, and handles real time bit stream processing.

Bluetooth Low Energy HW is connected to the exchange memory via the SBus. The RSL15 processor (Arm Cortex-M33 core) has access to this memory as well. To receive or send data, the BB_DRAM shared memory is used to share and communicate data between the Arm Cortex-M33 processor and the BB controller. The baseband controller communicates with:

  1. The CPU through:

    1. The baseband controller interrupts
    2. An internal bus and the DMA that access the internal configuration registers
    3. The SBus and the DMA that access the exchange memory (BB_DRAM0 & BB_DRAM1) parallel to the baseband controller. This memory access is managed by an external arbiter.
  2. The SBus and the DMA that access the exchange memory (BB_DRAM0 & BB_DRAM1) parallel to the baseband controller. This memory access is managed by an external arbiter.
  3. The RFFE through the control and data signals listed in the "Interface Signals Between Baseband Controller and RFFE" table. The control signals are transmitted over an internal SPI. The baseband controller is configured as the master, and the RF front-end as the slave. The RFFE modem sends/receives digital data to/from through the RX/TX data bus, as shown in the "Bluetooth Low Energy Baseband Controller Block Diagram" figure. The clock and reset signals are provided by the BBIF.

Table: Interface Signals Between Baseband Controller and RFFE
Signal Baseband Controller RFFE Description
SPI_MISO IN OUT SPI data slave to master
SPI_MOSI OUT IN SPI data master to slave
SPI_CLK OUT IN SPI data clock
SPI_CSN OUT IN SPI slave device select
RX_DATA IN OUT Rx data
RX_CLK IN OUT Rx data clock
SYNC_P IN OUT Access address detection
TX_DATA OUT IN Tx data
TX_DATA_VALID OUT IN

Tx data_qualifier

CTE_MODE OUT IN Enable CTE mode
CTE_SAMPLE_P OUT IN CTE sample pulse
IQ_DATA_P IN OUT IQ data qualifier
IQ_DATA IN OUT IQ data

When the RF front-end is isolated or powered down, the SPI MISO as well as RX_DATA and RX_CLK signals are forced to zero. When the baseband controller is isolated or powered down, the signals going to the RF front-end are forced to zero (except SPI CSN, which is forced to one). Disabling the RF front-end or the baseband controller stops and potentially corrupts any ongoing SPI transaction. For testing purpose, all the above signals can be accessed through the GPIOs, as illustrated in the "Interface Between the Baseband Controller and the RF Front-End" figure

NOTE: The information in the "Interface Between the Baseband Controller and the RF Front-End" figure is for debugging purposes only.

Figure: Interface Between the Baseband Controller and the RF Front-End

By default, the system is configured such that the BB controller is connected to the RFFE, and the Bluetooth Low Energy stack software configures the RFFE in Test Mode (see RF Front-End) to be able to communicate with the BB controller. When the BLE_Initialize() function is called, the Bluetooth Low Energy stack resets the BB controller, configures the static registers of the RFFE, and prepares the BB controller registers. Finally, it releases the BB from reset and enables it.

From a network protocol layer point of view, the BB controller is in charge of the link layer that is being controlled, and is managed by the Bluetooth Low Energy software stack, which means that the link layer is implemented in the BB controller and the Bluetooth Low Energy stack together.

The BB controller is clocked from a scaled-down version of the system clock, known as the master clock. This baseband controller implements a software configurable internal clock divider for generating a 1 MHz reference clock from the master clock. Both are prescaled from the system clock. A description of how to configure the prescale settings is found in Baseband Controller Interface.