# System Resources

## Exchange Memory

Memories BB_DRAM0 and BB_DRAM1 are allocated for use by the BB controller with the S-Bus, which allows it to share data with the Arm Cortex-M33 processor; this memory area is called the exchange memory. This section gives an overview of how the exchange memory works with the RSL15 Bluetooth Low Energy software and hardware.

The exchange memory is used for several purposes. The first 256-byte area of BB_DRAM0 is dedicated to event scheduling, to a maximum of 16 events, and is called the exchange table. The exchange table has 16 entries, which correspond to either successive advertising, scanning, or connection event anchor points. While the software prepares the future entries (i.e., anchor points), the hardware uses one entry to transmit/receive packets. Each exchange table entry points to a unique control structure that determines the event type to be performed. Each control structure points to a TX descriptor chained list, while a register determines the RX Descriptor location. Descriptors are chained lists in which the information/status of the current processed RX/TX packets are contained. Descriptors also contain the pointer to the next descriptor of the chained list. Each descriptor has an associated data pointer, giving the memory location of an associated data buffer. Each data buffer has a maximum length of 251 bytes.

Exchange table entries are fetched on a Bluetooth Low Energy Core software request, triggering a fetch of the control structure and descriptors at an optimized and defined period of time before the event starts.

The software prepares the control structures in advance, and the pointer in the exchange table is only set up when this operation is completed. The Bluetooth Low Energy software stack indicates to the baseband controller that a given entry has to be processed, using the BB_ACTSCHCNTL register. The BB controller accesses the relevant fields in the selected exchange table entry (i.e defined timestamp, priority levels, control structure pointer, etc.). The software can prepare the next entry and safely access the pointers. These mechanisms are handled by the Bluetooth Low Energy software stack. The "Exchange Table, Control Structure, Descriptors and Data Buffers" figure provides an overview:

Figure: Exchange Table, Control Structure, Descriptors and Data Buffers

Events (advertising/connection/scanning) are programmed by the means of the control structure. Depending on the settings of the control structure format, the events can be composed differently. The Bluetooth Low Energy software stack is responsible for programming the advertising events and connection events. The BB controller activity scheduler generates an interrupt on each end of an event, as well as when an event is not processed: each exchange table is read and taken into account only after the current event in process is closed. The "Connection Event Programming and Exchange Table Pre-Fetch / Master Device Example" figure and the "Connection Event Programming and Exchange Table Pre-Fetch / Slave Device Example" figure show the exchange table pre-fetch for a master and a slave device, and how the BB controller behaves during each connection event:

Figure: Connection Event Programming and Exchange Table Pre-Fetch / Master Device Example

Figure: Connection Event Programming and Exchange Table Pre-Fetch / Slave Device Example

The other data is kept in exchange memory, including:

- A frequency table for VCO programming of the RFFE for each Bluetooth Low Energy channel
- A Bluetooth Low Energy white list
- A Bluetooth Low Energy resolving address list
- A periodic advertisement list
- An antenna pattern ID for AoA/AoD

## Filtering Lists and Device Filtering

Device addresses and list organization are managed by the Bluetooth Low Energy software stack. A device for which IRKs have not been exchanged stands either in the white list, or in the periodic advertiser list: in this case, the device identity is used for device filtering (if used). As soon as IRKs are exchanged, a corresponding entry in the resolving address list is created. Each entry in the resolving address list indicates whether the device is in the white list or the periodic advertiser list. The "Device Filtering Lists Organization" figure shows an example of the device filtering lists organization within the BB controller:

Figure: Device Filtering Lists Organization

Device filtering is based on the peer device’s address. It is used to minimize the number of devices the system responds to during device discovery/connection. Filtering policies in between advertising state, scanning state, and initiating state are independent. Device filtering policy is determined by a parameter set by the Bluetooth Low Energy stack software in the control structure of the CS-FILTER_POLICY field, and applies differently according to the CS-FORMAT value. Additionally, the RPA resolution can be enabled when the device uses Enhanced Privacy Mode. If an RPA is not resolved, depending on device filtering policy, the device might not respond to the received packet.

## AES-128 On Software Request

The BB controller uses an AES-128 hardware accelerator for Bluetooth Low Energy encryption and decryption of data, and for resolving the address list engine. This HW block is available to application software. When the Bluetooth Low Energy stack is not used, this HW block can be used safely by software; but if the Bluetooth Low Energy stack is used, we recommend that application software uses GAP API (refer to the GAP documentation in the RSL15 Firmware Reference), to avoid causing any issue for the Bluetooth Low Energy data being encrypted or decrypted by the BB controller.

AES-128 can be used by the software that stores the block to cipher, in the exchange memory (in the BB_DRAM0 and BB_DRAM1 address range) at the address specified in the BB_AESPTR register. The block size to cipher is always considered equal to 16 bytes. The software defines the input key by setting its value in the BB_AESKEY*_* registers. Once the setting is done, the software begins to use AES-128 by setting the cipher mode in the BB_AESCNTL_AES_MODE bit of the BB_AESCNTL register, and writing a 1 to the BB_AESCNTL_AES_START bit of the same register. On normal termination, the software receives a BLE_CRYPT_IRQ. When finished, the software can find the ciphered data at the AESPTR+16 address, as shown in the "Memory Mapping for AES-128 Software Use" figure (considering byte address memory).

When an encrypted link layer event has to be processed, it is possible that the event controller and packet controller require AES-CCM to run while a software request is ongoing. In this case, the current ciphering process is stopped, as real time AES-CCM processing has higher priority. When the real time encryption process ends, the AES-128 FSM restarts the ciphering process until normal termination, and then the BB_AESCNTL_AES_START bit of the BB_AESCNTL register is reset. The BB_AESPTR_AESPTR address defined in the BB_AESPTR register needs to point to the exchange memory at a location not used by the baseband controller. The software can use the below code to make sure the address pointer is not used by HW:

BB_AESPTR = (EM_ENC_IN_OFFSET >> 2);

NOTE: AES deciphering is not supported.

Figure: Memory Mapping for AES-128 Software Use

## RF Test Modes

RF Test modes are dedicated to both Bluetooth RF qualification and regulatory body support. There are two main test modes supported by the BB controller:

- TX test mode, which is Bluetooth RF qualification oriented for TX modes.
- RX test mode, which is Bluetooth RF qualification oriented for RX modes.

The access address is fixed to 0x71764129 for RF test packets.

In the Bluetooth Low Energy specification, these tests are run in so-called Direct Test Mode (DTM). When an HCI or GAP DTM test mode command is received, the Bluetooth Low Energy software stack programs the BB controller, which then takes care of programming and sending DTM packets or configuring the RFFE for RX DTM Mode accordingly. Once the DTM end command is received, the Bluetooth Low Energy stack disables and removes the DTM event, and reads the number of correctly-received packets from BB controller register BB_RXPKTCNT, if the test mode is DTM. The number of transmitted packets can be read from register BB_TXPKTCNT if the text mode is DTM TX.

## Angle of Arrival (AoA) and Angle of Departure (AoD) Support

AoA/AoD can be performed through ACL connection or periodic advertising. It operates over LE 1M and LE 2M only. CTE information is located either in the packet header (ACL or Direct test Mode cases) or in the extended packet header (periodic advertising case). Both carry the same data, which is related to the type of operation (i.e., AoA/AoD) and CTE field duration. Depending on the use case, specific counting mechanisms are required for aligning baseband timings to radio/modem timings, for antenna switching instant and pattern control (TX or RX), and I&Q sampling instant (RX only).

To support AoA/AoD, the transmitter needs to add a constant tone extension (CTE) following the CRC part of a Bluetooth Low Energy packet. The CTE field is divided into three periods:

1. 4 μs guard period, during which:
   1. Reference antenna (i.e., the first antenna in the list) must be used.
   2. Switching is not allowed for either transmitter or receiver.
   3. Sampling is not allowed for either transmitter or receiver.
2. 8 μs reference period, during which:
   1. Reference antenna (i.e., the first antenna in the list) must be used.
   2. Switching is not allowed for either transmitter or receiver.
   3. Sampling is required for the receiver.
3. the rest of the CTE period
   1. Antenna pattern is applied according to the provided antenna list.
   2. Switching is allowed for either transmitter or receiver, depending on the use case (AoA/AoD).
   3. Sampling is required for the receiver.

For further information, refer to the Bluetooth Core Specification version 5.2.

Antenna switching happens during AoD transmission or AoA reception. During AoD operations, the antenna switching interval (i.e., 1 μs or 2 μs) is determined by the value of CTEType, which is a field in the Bluetooth Low Energy packet header specified in the Bluetooth core specification.

The registers responsibe for various antenna timing controls are show in the "AoD Transmission Antenna Switching Time Controls" table and the "AoA Reception Antenna Switching Time Controls" table.

Table: AoD Transmission Antenna Switching Time Controls
Duration | Control Register | Control Field from Register
--- | --- | ---
1 Mbps PHY, 1 μs slot duration | BB_DFCNTL0_1US | TXSWSTINST0_1US
1 Mbps PHY, 2 μs slot duration | BB_DFCNTL0_2US | TXSWSTINST0_2US
2 Mbps PHY, 1 μs slot duration | BB_DFCNTL1_1US | TXSWSTINST1_1US
2 Mbps PHY, 2 μs slot duration | BB_DFCNTL1_2US | TXSWSTINST1_2US

Table: AoA Reception Antenna Switching Time Controls
Duration | Control Register | Control Field from Register
--- | --- | ---
1 Mbps PHY, 1 μs slot duration | BB_DFCNTL0_1US | RXSWSTINST0_1US
1 Mbps PHY, 2 μs slot duration | BB_DFCNTL0_2US | RXSWSTINST0_2US
2 Mbps PHY, 1 μs slot duration | BB_DFCNTL1_1US | RXSWSTINST1_1US
2 Mbps PHY, 2 μs slot duration | BB_DFCNTL1_2US | RXSWSTINST1_2US

These register fields are in microsecond units. By increasing them, switching times are delayed, and vice versa.

RX I&Q sampling start instants are configured through the fields shown in the "RX I&Q Sampling Start Instant Configuration Controls" table.

Table: RX I&Q Sampling Start Instant Configuration Controls
Duration | Control Register | Control Field from Register
--- | --- | ---
1 Mbps PHY, 1 μs slot duration | BB_DFCNTL0_1US | RXSAMPSTINST0_1US
1 Mbps PHY, 2 μs slot duration | BB_DFCNTL0_2US | RXSAMPSTINST0_2US
2 Mbps PHY, 1 μs slot duration | BB_DFCNTL1_1US | RXSAMPSTINST1_1US
2 Mbps PHY, 2 μs slot duration | BB_DFCNTL1_2US | RXSAMPSTINST1_2US

The Bluetooth Low Energy stack configures sampling times and antenna switching times for an antenna switching HW, with typical 400 ns switching times from control signal to actual switching. if an external antenna switching HW has different timings, users might need to tune them accordingly. The "AoD CTE Transmission Timing Diagram" figure and the "AoA CTE Reception Timing Diagram" figure provide timing diagrams for actual HW signals during AoD TX and AoA RX:

Figure: AoD CTE Transmission Timing Diagram

Figure: AoA CTE Reception Timing Diagram