25. Radio IP

25.1 Overview

This section describes the Radio IP embedded in the STM32WB05xZ product. The Radio controller MR_BLE manages the Bluetooth® LE protocol with hardware addon to support some new Bluetooth specification features, and controls the RF analog module.

25.1.1 Architecture overview of the MR_BLE IP

As shown in Figure 197. RRM overview , the MR_BLE IP contains:

• • A Bluetooth® LE subsystem dedicated to Bluetooth protocol (IP_BLE block) and containing:
  • – a Bluetooth® LE link layer. This sub block is an AHB master
  • – a demodulator
  • – a modulator
• • An RRM (radio resource manager) block contains:
  • – a UDRA (unified direct register access) executing link list command in RAM to read/write radio register. This sub-block is an AHB master
  • – Direct radio register access allowing read/write access to radio registers through APB
• • A wakeup/always-on block contains:
  • – a wakeup block for IP_BLE including a time interpolator and sleep request / wakeup request management and a few enhanced features
• • A radio FSM controlling the RF2G4 analog radio.
• • A radio registers block (to program the analog radio parameters).
• • Some small blocks used for calibrations, PLL control, Rx data path interface (AGC, FIFO ADC).

The MR_BLE IP supports two system clock frequencies: 16 MHz and 32 MHz.

Figure 196. MR_BLE architecture overview

25.1.2 Global scenario for Bluetooth® LE protocol usage

The Bluetooth® LE link layer always needs a trigger event to start a sequence. This trigger event has three possible timer sources (wakeup timer, Timer1, or Timer2).

Basically, a Bluetooth sequence follows the steps described below:

1. 1. The CPU needs to prepare in RAM (through different tables) all information needed for the coming transfer:
   • – for radio programming (channel number, reception, or transmission, calibration feature, etc.)
   • – for a packet to transmit or receive (contents, ADV, or data, encryption, etc.)
   • – for interrupt mask selection
   • – to prepare the trigger event that schedules the sequence after this one
2. 2. Then the CPU has to program the chosen timer (except if already done through a table for timer2 inside the previous sequence).
3. 3. Once the Bluetooth® LE link layer receives the trigger event from the programmed timer, it gets all the information in the RAM table and launches the requested transfer.
4. 4. At the end of the sequence (and not before), the Bluetooth® LE link layer writes back in RAM tables some information, updates the status/error flags and generates an interrupt towards the CPU according to the interrupt mask programming.
5. 5. The CPU has to treat the RAM table updated information (including packet payload after a reception) to decide what is the next wanted sequence. Then a cycle restarts from step 1.

Note:

• • The RAM tables are located in a retention area. So, the data is kept even during low-power modes that switch off the digital 1.2 V power domain. This allows the Bluetooth® LE link layer to start a transmission/reception while the CPU is not yet available as rebooting from a wakeup reset.

25.1.3 Miscellaneous features: RF activity monitoring

25.1.3.1 On-going Tx sequence information (to control an external power amplifier (PA))

The MR_BLE is able to control an external power amplifier (located on the board to increase the Tx power) through a signal provided to the SoC to be connected directly on an external GPIO or to be managed with an additional logical mechanism. The external PA can be useful to extend the Tx power.

The external power amplifier components have quite a long latency to establish and consume a lot of current (several mA) which could lead to unlocking the MR_BLE PLL. For this reason, the control signal is anticipated as soon as the system knows it starts a Tx sequence and stops as soon as possible (at the same time as the internal PA).

The MR_BLE outputs a signal to the SoC, which is high as soon as a Tx sequence is requested to the radio FSM up to the return to ACTIVE2 or less state. To be more precise, the information is provided as soon as the radio FSM is starting to treat a Tx request (leaving ACTIVE2 state for EN_LDO state) and goes down as soon as the system switches off the internal PA (for example, leaving Tx state at the end of the transmission or during EN_PA in case of PLL lock fail).

The information is available in two different ways in the STM32WB05xZ:

• • directly output on a GPIO (RADIO_TX_SEQUENCE)
• • flags and associated interrupt available in the system controller (SYSCFG block)

25.1.3.2 On-going Rx sequence information (to control an external low noise amplifier (LNA))

The MR_BLE is able to control an external low noise amplifier (located on the board) through a signal provided to the SoC to be connected directly on an external GPIO or to be managed with additional logical mechanism.

The MR_BLE outputs a signal to the SoC, which is high as soon as an Rx sequence is requested to the radio FSM up to the return to ACTIVE2 or less state.

The information is available in two different ways in the STM32WB05xZ:

• • directly output on a GPIO (RADIO_RX_SEQUENCE)
• • flags and associated interrupt available in the system controller (SYSCFG block).

25.1.3.3 RF activity information

An additional signal is available on the device pin to inform either an Rx or a Tx sequence is active. This pin called RADIO_RF_ACTIVITY is a logical OR between the RADIO_TX_SEQUENCE and RADIO_RX_SEQUENCE mentioned in the two previous sections.

25.1.4 Bluetooth® LE standard 5.1 additional support

The STM32WB05xZ Radio IP supports the angle of arrival (AoA) and angle of departure (AoD) feature by managing:

• • the constant tone extension (CTE) inside the packet
• • the antenna switching mechanism for both AoA and AoD

In transmission, the MR_BLE is able:

• • to append the constant tone extension at the end of the packet
• • and, if AoD mode is selected, to manage the antenna switching according to CTEInfo parameters (duration and switching slots definition) and following a pattern provided by the SW
• • The SW has to provide to the IP_BLE the CTE information (CTE time, CTE type, slot width) and the antenna pattern if antenna switching in AoD has to be managed

In reception, the MR_BLE is able:

• • to detect and decode CTEInfo bit field from the received frame
• • to store the IQ samples in RAM according to sampling time slots
• • and, if AoA mode is selected, manage the antenna switching according to CTEInfo parameters (duration and switching slots definition)

The SW has only to provide the slot width information if the configuration is an AoA configuration as this is the only information not available in the received frame and the antenna pattern.

The CTE/antenna switching mechanism of the MR_BLE provides to the external world a 7-bit antenna identifier (ANT_ID[6:0]) indicating the antenna number to be used.

The CTE/antenna switching feature implies:

• • adding few bit fields in the RAM tables
  • – CTE information when hardware cannot extract them by itself
  • – A pointer on a RAM buffer where to store the IQ sampling for CTE reception
  • – Antenna pattern length and a pointer on the RAM buffer containing the antenna pattern
• • adding a status register in the IP_BLE APB registers (STATUS2REG) providing information on the IQ sampling and antenna switching sequence that just occurred
• • adding some radio registers to tune timing delays on antenna switching control and IQ sampling

Those new features support can be disabled by SW through the StatMach.CTEDisable bit.

25.2 Interfacing with the MR_BLE IP

The MR_BLE IP interfaces with several blocks in the system:

• • CPU through interrupts
• • RAM through an AHB interface either initiated by the RRM or by the Bluetooth® LE link layer
• • Power controller block and clock and reset controller block
• • Specific signals to propagate to the pads of the device to manage inside the Soc.

25.2.1 Interruption lines to the CPU

The MR_BLE IP provides several interruption lines to the CPU, issued by different sub-blocks:

• • 2 interrupt lines from the Bluetooth® LE link layer
• • 2 interrupt lines from the wakeup block
• • 1 interrupt line from the RRM
• • 2 interrupt lines from the radio controller.

Table 115. Interruption summary

25.2.1.1 IP_BLE interrupt lines

irq_BLE_int1 (aka BLE_TXRX):

• • This interrupt line is triggered when a Bluetooth sequence has been executed. It informs the CPU that status/error flags and RAM tables may have been updated
• • Mapped on CPU interrupt line 18.

irq_BLE_int2 (aka BLE_AES):

• • This interrupt line is dedicated to an embedded AES block and combines both AES LE privacy and AES manual encryption information
• • Mapped on CPU interrupt line 19.

See Section 25.8.3: IP_BLE interrupts for details on interrupt sources.

25.2.1.2 wakeup block interrupt lines

irq_wakeup_ble (aka BLE_WKUP):

• • This interrupt line indicates to the CPU that the IP_BLE receives a wakeup request from the MR_BLE IP wakeup block. The wakeup request source is the wakeup timer.

• • Mapped on CPU line 24

irq_wakeup_cpu:

• • This interrupt line indicates that the wakeup timer reaches the programmed value to trigger an interrupt towards the CPU (dedicated slice in the wakeup block design in parallel with the IP_BLE slice).
• • Mapped on CPU line 23.

See Section 25.9: Wakeup block for more details.

25.2.1.3 RRM interrupt line

This interrupt line is dedicated to the RRM block. It is triggered on semaphore and UDRA sub-block activities.

See Section 25.4: Radio resource manager (RRM) for more details.

25.2.1.4 Radio controller interrupt lines

irq_rf_fsm:

• • This interrupt line indicates events and errors detected by the radio state machine.

irq_mr_syst:

• • This interrupt line is dedicated to the counter measuring the slow clock period and frequency. It indicates when the calculated values are available.

See Section 25.7: Radio controller for more details.

25.2.2 Interface with the RAM embedded in the SoC

The MR_BLE IP is an AHB master on the bus matrix as the CPU or a DMA.

Two of its internal blocks access the RAM of the system:

• • the Bluetooth® LE link layer to read the sequence information and Tx/Rx configuration parameters, to read the data to transmit or to write the received data in the RAM tables, to store the IQ samples during a CTE reception
• • the RRM UDRA block to get commands structure in RAM, used to program the radio registers while the CPU is not available (potentially rebooting after a low-power mode).

Both internal blocks may need to access the RAM in parallel. An arbiter is located inside the IP.

25.2.3 Interface with the power clock and reset controllers

The MR_BLE receives several clocks from the SoC:

• • the system clock that can be 16 or 32 MHz
• • an always 16 MHz clock
• • an always 32 MHz clock
• • a slow clock (called 32 kHz clock in this document) that needs to be in the always-on power domain as it corresponds to the clock used to wake up the radio link layers from sleep state.

The fast clocks (system, 16 MHz, and 32 MHz) must be accurate when the radio is used (for the transmission/reception).

The MR_BLE IP communicates with the power controller of the system to indicate when the MR_BLE IP is ok to go to low-power modes and when it requests a wakeup.

The MR_BLE IP says it is ready to sleep when:

• • no sequence is on-going (a sequence starts with a trigger event and the IP_BLE interrupt rising edge)
• • no timer1 or timer2 selected to generate the next trigger event on the Sequencer
• • no pending interrupt in the INTERRUPT1REG APB register.

The MR_BLE IP also proposes an embedded always-on timer that may generate a programmed wakeup for the CPU.

25.3 Warning for users

Note:

• • If some radio registers are modified in the RRM commands, they should not be also modified by the CPU through direct access. Indeed, there is no way to keep coherency and know which master last modified the concerned radio register.
• • Accurate system clock must be present during all scenarios where the IP_BLE Sequencer uses the Timer1 (from trigger event).
• • On the fly, CCM encryption does not work if TxRxPack.NS_EN bit is low.

25.4 Radio resource manager (RRM)

The Radio Resource Manager (RRM) is a hardware block managing the radio access to one unique controller at a time.

It is the block that manages the requests performed by the Bluetooth® LE link layer of the IP_BLE and the CPU to access the radio resources. The requests pass through a semaphore and only one of the two can take control of the radio at a time. The arbitration behaves as follows:

• • check the priority value to choose between the IP_BLE or the CPU
• • if the same, then the arbiter eliminates the requester that has been served more recently.

The two controllers can request access to the radio resources through a dedicated port:

• • Port 0 for the IP_BLE
• • Port 1 for the CPU (it is a virtual port in this case)

The Bluetooth® LE link layer does not have access to the radio resources until it requests a token to the RRM and the RRM grants it. For the CPU, only RRM commands require to get a token, the direct APB access to the Radio registers is always possible. The token is requested by software for the CPU while it is done by hardware for the Bluetooth® LE link layer each time a timer trig event starts a sequence. Nevertheless, the firmware can release the token granted by the Bluetooth® LE link layer writing inside the CMDREG APB register. Once the requester has the token, its port is granted, and it can access the radio resources.

Figure 197. RRM overview

25.4.1 Semaphore

The semaphore grants the access to the radio resources control to the radio controller or to the CPU depending on the demand.

An arbitration system is in place to manage conflicts when a token request is raised simultaneously by the IP_BLE controller and the CPU. In this case, the arbiter:

• • checks the priority programmed for the CPU virtual port to choose between the two requesters (IP_BLE has priority=0)
• • if the same, eliminates the requester that has been served more recently.

The CPU is a virtual port and must provide the token request through an APB registers bit field (see Section 25.4.4.1: RRM register list ). The Bluetooth® LE link layer controller uses hard wired signals to communicate with the RRM and the request is managed directly by the Bluetooth® LE link layer each time a timer trig event starts a Bluetooth® LE sequence.

As soon as the IP_BLE port is granted, the Radio FSM block is informed by the semaphore that the radio is about to be used. The goal is to switch off the analog as much as possible when not used and switch it on only when needed (for power consumption)

Some interruptions are linked to the semaphore block in the RRM:

• • on a port grant event
• • on a port release event

See Section 25.4.4: RRM registers .

25.4.2 UDRA

The "Unified Direct Register Access" block allows the software to prepare some commands in a command link list located in the retention RAM. Those commands execute read from and write into the radio registers.

Some interruptions are linked to the UDRA block in the RRM:

• • on a command start event
• • on a command end event.

See Section 25.4.4: RRM registers for more details.

The main goal of this block is to allow the Bluetooth® LE link layer to reinitialize the radio registers after a low power mode sequence to start an RF communication while the CPU is still being booted and not yet available to manage.

Note: The read command embeds some limitations. However, the radio registers can be read directly through the APB by the CPU so the read command of the UDRA is useless.

25.4.2.1 RAM command link list information

The mapping in RAM for the commands for each port is the following:

• • the RadioConfigPtr field of the GlobalStateMachGlobalStatMach contains the start address of the command start list (this address must be 32-bit aligned)
• • the command start list is a 32-bit element table containing the first command addresses of each command number of each port
• • each command of each port contains some read and/or write actions on radio registers.

An overview of this indirect mapping is represented in Figure 198. UDRA command list mapping in RAM (example)

Figure 198. UDRA command list mapping in RAM (example)

The RadioConfigPtr value is loaded by the RRM-UDRA automatically when the radio IP reset is released. If the software did not initialize this RAM address supposed to point on the command_start_list address before this first automatic load, a “reload pointer” command is available by writing 1 in the UDRA_CTRL0[0] APB register (this bit is auto-cleared immediately).

Note: The RadioConfigPtr pointer value loaded and used by the RRM-UDRA block can be read in the UDRA_RADIO_CFG_PTR APB register.

The port mapping has been defined as follows:

• • 2 ports (port0=IP_BLE, port1= VP_CPU)
• • port0 supports 3 commands (command 0/1/2)
• • port1 supports 4 commands (command 0/1/2/3)

This leads to a command start list table as presented below:

Table 116. Command start list details

25.4.2.2 UDRA command format in RAM

The write and read command format are described in the following table. Note that only one radio register address is entered for a write or a read. Then, if the number of data to write/read is more than one, the address is incremented automatically by 1.

Table 117. UDRA command format in RAM

Note: If any error information is put in the RAM command list (bad command number, lack of null command, etc.), the RRM-UDRA does not return to an IDLE state and cannot accept new commands until a reset is done on the full MR_BLE IP.

Basic examples:

1. 1) Write AAC0_DIG_ENG=0x12 and AAC1_DIG_ENG=0x34 (grouped registers) through port1.command0:
   @port1.command0_addr = 0x02; Write 2 data
   @port1.command0_addr+1 = 0x AAC0_DIG_ENG_ADDR;

@port1.command0_addr+2 = 0x12; 1st data to write in AAC0_DIG_ENG
@port1.command0_addr+3 = 0x34; 2nd data to write in AAC1_DIG_ENG
@port1.command0_addr+4 = 0x00; null command

At the end of command execution, the 2 radio registers have been modified with a new value.

25.4.3 Direct register access

The direct register access block allows the software to access the radio registers directly through an APB access. To do a direct read or write access to the radio registers, the software just has to read/write them through the APB at address mapping described in Section 25.5.1: Radio register list .

Note: The radio registers are 8-bit only so the APB register bit field [31:8] part is padded with 0. An 8-bit address mapping column is provided to be used in the RRM UDRA command list as the address of the radio register in this specific case.

An internal arbiter manages the case of concurrent accesses on radio registers by both UDRA (executing a command) and direct register access block (on a CPU read/write APB request). The arbitration is based on a round-robin priority mechanism.

Note: The software must not write any radio registers through direct APB access if they are also modified through commands in RAM (through UDRA block). In this case, there is a risk of multi drivers in parallel and loss of coherency (no way to know which requester wrote the last one).

25.4.4 RRM registers

25.4.4.1 RRM register list

The RRM registers are accessible through the APB interface.

All non-listed addresses must be considered as RESERVED.

The RRM_BLOCKBaseAddress keyword used for all the register base address information corresponds to the RRM registers base address in the SoC when integrating the IP.

RRM_BLOCKBaseAddress is 0x6000_1400 in the STM32WB05xZ product.

Table 118. RRM registers list

Table 119. UDRA_CTRL0 register description

Table 120. UDRA_IRQ_ENABLE register description

Table 121. UDRA_IRQ_STATUS register description

Table 122. UDRA_RADIO_CFG_PTR register description

Table 123. SEMA_IRQ_ENABLE register description

Table 124. SEMA_IRQ_STATUS register description

Table 125. BLE_IRQ_ENABLE register description

Table 126. BLE_IRQ_STATUS register description

Note: The Bluetooth® LE link layer receives the previous information directly by hardware wires and manages the sequence through them. The interrupt mechanism is there in case the CPU needs to monitor the activity between the Bluetooth® LE link layer and the RRM block.

Table 127. VP_CPU_CMD_BUS register description

Table 128. VP_CPU_SEMA_BUS register description

Table 129. VP_CPU_IRQ_ENABLE register description

Table 130. VP_CPU_IRQ_STATUS register description

25.5 Radio registers

The Radio registers are 8-bit registers mainly used to control the RF2G4 analog IP and the Radio FSM. They also allow taking control for validation/test purposes.

They can be accessed through two different mappings:

• • as 32-bit APB registers (address incremented by 4 between each register) through RRM Direct Access interface
  • – this mapping is used by the CPU
• • as 8-bit register (address incremented by 1 between each register) through RRM UDRA command list in RAM
  • – this mapping is used by the RRM

Caution: the radio registers are used to control the analog and few modulator/demodulator features. They are not supposed to be modified directly by the user. The potential modifications are provided by STMicroelectronics in the SDK boot code.

25.5.1 Radio register list

The RF_REG_BLOCKBaseAddress keyword used for all the register base address information corresponds to the Radio registers base address decided by the SoC when integrating the IP.

RF_REG_BLOCKBaseAddress is 0x6000_1500 in the STM32WB05xZ product.

25.5.2 Radio registers description

Table 132. AA0_DIG_USR register description

Table 133. AA1_DIG_USR register description

Table 134. AA2_DIG_USR register description

Table 135. AA3_DIG_USR register description

Table 136. DEM_MOD_DIG_USR register description

Table 137. RADIO_FSM_USR register description

Table 138. PHYCTRL_DIG_USR register description

Table 139. AFC1_DIG_ENG register description

Table 140. CR0_DIG_ENG register description

Table 155. SYNTHCAL3_DIG_OUT register description

Table 156. SYNTHCAL4_DIG_OUT register description

Table 157. . SYNTHCAL5_DIG_OUT register description

Table 158. FSM_STATUS_DIG_OUT register description

Table 159. RSSI0_DIG_OUT register description

Table 160. RSSI1_DIG_OUT register description

Table 161. AGC_DIG_OUT register description

Table 162. DEMOD_DIG_OUT register description

Table 163. AGC2_ANA_TST register description

Table 164. AGC0_DIG_ENG register description

Table 165. AGC1_DIG_ENG register description

Table 166. AGC10_DIG_ENG register description

Table 167. AGC11_DIG_ENG register description

Table 168. AGC12_DIG_ENG register description

Table 169. AGC13_DIG_ENG register description

Table 170. AGC14_DIG_ENG register description

Table 171. AGC15_DIG_ENG register description

Table 172. AGC16_DIG_ENG register description

Table 173. AGC17_DIG_ENG register description

Table 174. AGC18_DIG_ENG register description

Table 175. AGC19_DIG_ENG register description

Table 182. ANTSW3_DIG_USR register description

25.5.3 Trimming information

The MR_BLE loads automatically hardware trimming information located in the flash memory of the SoC.

The trimmed information is:

• • Rx ADC delay for I and for Q channels
• • IPTAT and BIAS current trimming for CBIAS block
• • AGC trimming

Those trimming values are automatically loaded by the hardware on reset and low-power mode exit.

The loaded values are readable in dedicated radio registers (xx_HW_TRIM_OUT).

The AGC user trimming can be impacted by the BOM on the user board and may need to be overloaded. The SW can overload / replace the hardware value.

The AGC trimming consists of 1 piece of information:

• • AGC_ANTENNAE_TRIM_I
  • – Hardware value readable in AGC_HW_TRIM_OUT[3:1] = HW_AGc_ANTENNAE_TRIM[2:0]
  • – SW value writable in AGC2_ANA_TST[3:1] = AGC_ANTENNAE_USR_TRIM[2:0]
  • – SW overload feature activation through AGC2_ANA_TST[0] = AGC2_ANA_TST_SEL

The hardware values are reloaded on any reset and low-power mode exit.

The SW values must be re-written after any reset or low-power mode.

25.6 Radio FSM

The Radio FSM manages the analog radio block startup and stop sequences depending on requesting RF transfer.

25.6.1 Radio FSM sequences

This section lists the main steps in the radio FSM sequence.

• • The radio FSM stays in IDLE as long as the IP_BLE does not request the RRM token to indicate that the radio is about to be used.
• • Once the token is requested, the radio FSM switches to ACTIVE1.
• • When the device switches on the accurate fast clock (external XO) AND if the RRM semaphore granted one port (whatever the port), the radio FSM goes to ACTIVE2 (through a few intermediate steps to start RF LDO and central bias current).
• • Once an Rx or Tx request is received, the radio FSM switches to the Rx or Tx through intermediate steps to set up properly the analog.

• • The radio FSM goes back:
  • – to ACTIVE2 as soon as Rx or Tx request is cleared and back to ACTIVE1 if the accurate clock is replaced by the dirty one
  • – to IDLE if no more ports request a token to the RRM semaphore.

Figure 199. Radio FSM overview provides an overview of the RF FSM states sequence.

Some transitions are triggered by hardware signals, but others are managed through timeout.

Section 25.6.2: Radio FSM states overview lists the different timeouts.

Figure 199. Radio FSM overview

stateDiagram-v2
    [*] --> IDLE : padresetn
    IDLE --> ACTIVE1 : Initialize = Bluetooth LE port token request
    ACTIVE1 --> ENA_RF_REG : port_selected_en (granted) & SoC clock accurate
    ACTIVE1 --> IDLE : ~initialize
    ENA_RF_REG --> ENA_CURR : RFREG_timeout (25us)
    ENA_CURR --> ACTIVE2 : ena_curr_timeout (20us)
    ENA_CURR --> ACTIVE1 : ~initialize | ~port_selected_en | ~SoC clock accurate
    ACTIVE2 --> ENA_TRANSFO_LDO : TX request active
    ENA_TRANSFO_LDO --> SYNTH_SETUP : transfo_ldo_timeout (0us)
    ENA_TRANSFO_LDO --> ACTIVE2 : RX request active
    SYNTH_SETUP --> CALIB11 : pll calib requested
    CALIB11 --> LOCKRXTX : end of pll calib
    CALIB11 --> ACTIVE2 : No pll calib requested
    LOCKRXTX --> EN_RX : RX req active & exit_lockrxtx
    LOCKRXTX --> EN_PA : TX req active & exit_lockrxtx
    EN_RX --> RX : en_rx_timeout (10us)
    EN_RX --> ACTIVE2 : ~RX req active
    RX --> ACTIVE2 : ~RX req active
    EN_PA --> TX : PA ready
    TX --> PA_DWN_ANA : ~TX req active
    TX --> ACTIVE2 : pll unlock
    PA_DWN_ANA --> ACTIVE2
    ACTIVE2 --> ENA_TRANSFO_LDO : (~TX req active & ~RX req active) | (~pll lock after LOCKRXTX)
  

25.6.2 Radio FSM states overview

The table below lists, for each state, the exit condition and the duration in the state when there is a deterministic one.

1. The radio FSM may abort the sequence and return to ACTIVE2 from those two states depending on RF PLL lock information:

• • LOCKRXTX: the decision occurs at the very end of the state to decide if the sequence should continue (PLL locked) or abort (PLL lock failed)
• • EN_PA: the decision to abort can occur at any time inside this state as soon as the RF PLL is no longer locked (PLL unlocked)

If the PLL unlock event occurs outside those two states, the radio FSM does not interfere. The SW is informed through an interrupt and is in charge of managing the situation.

The current state information is available in the FSM_STATUS_DIG_OUT radio register accessible by direct APB access (see Section 25.5.1: Radio register list ).

The radio FSM uses timeout to exit states linked to analog block settlement to guarantee a deterministic duration between ACTIVE2 and Tx or Rx state at any occurrence. This is mandatory to be able to fit with Bluetooth protocol timings requirements in a peer-to-peer communication flow.

Those deterministic durations are presented in the table below.

25.6.3 Radio FSM interrupts

The Radio FSM provides a dedicated interrupt output signal to the system.

The Radio FSM generates 6 (2 are reserved) individually maskable interrupts grouped in an RfFsm_event[5:0] list:

• • RfFsm_event[0] = PLL Lock timeout
  • – set when the counter to exit LOCKRXTX expires
  • – whatever the lock status (PLL locked or not locked at timer expiration)
• • RfFsm_event[3] = PLL unlock detection
  • – set when the PLL lock signal falls after the lock detection step.
• • RfFsm_event[4] = PLL lock failed
  • – set if the PLL lock is not high when the Radio FSM exits the LOCKRXTX state
  • – or set if the PLL is no more locked during EN_PA state or on exit of EN_PA state
• • RfFsm_event[5] = PLL calibration error
  • – set if a PLL calibration error occurs during PLL calibration step.
  • – Problems can concern the amplitude calibration and/or the frequency calibration and/or the KVCO calibration.
  • – In this case, the detail can be read in SYNTH3_DIG_OUT[3:0] if SYNTHCAL0_DIG_ENG[3:0] = 0xC:
    • ◦ SYNTHCAL3_DIG_OUT[3] = CAL_ERROR
    • ◦ SYNTHCAL3_DIG_OUT[2] = CALAMP_ERROR
    • ◦ SYNTHCAL3_DIG_OUT[1] = CALFREQ_ERROR
    • ◦ SYNTHCAL3_DIG_OUT[0] = CALKVCO_ERROR

All the sources are combined into a single signal to be connected outside the IP_BLE to the interrupt controller of the SoC (see Table 115. Interruption summary for mapping in STM32WB05xZ).

The interrupts can be enabled/disabled individually through the radio controller APB registers:

• • Enable/disable through RADIO_CONTROL_IRQ_ENABLE register
• • Reading the RADIO_CONTROL_IRQ_STATUS register returns the interrupts status
• • Writing a '1' to the RADIO_CONTROL_IRQ_STATUS[x] clears the associated interrupt flag.

See Section 25.7.3: Radio controller registers for more details.

25.7 Radio controller

The radio controller is a small block in charge of two features:

• • Slow clock period measurement
• • Radio FSM interrupt management

25.7.1 Slow clock measurement

The radio controller contains a block dedicated to the slow clock measurement.

This measurement:

• • is launched automatically by the hardware when the system clock switches on accurate clock (external XO).
• • can be launched by the software when needed (by writing zero in CLK32K_PERIOD register)

The result provided by this block is both a period and a frequency information (in two separate results registers). The software can program the window of measurement (in slow clock cycle number) and the period result is provided in 16 MHz half-period unit.

25.7.2 Radio FSM interrupt management

During the sequences, the Radio FSM generates some interruptions to monitor some unexpected behavior at analog level. As the Radio FSM block does not have any APB interface, the interrupt control and status flags are managed inside the radio controller block through APB registers:

• • RADIO_CONTROL_IRQ_ENABLE register to enable the wanted interrupt sources.
• • RADIO_CONTROL_IRQ_STATUS register to get the status (on read) and to clear the interrupt (by writing '1' on the associated bit).

See Section 25.6.3: Radio FSM interrupts for more details on interrupt root causes.

25.7.3 Radio controller registers

25.7.3.1 Radio controller register list

The RADIO_CONTROL_BLOCKBaseAddress keyword used for all the register base address information corresponds to the Radio Controller registers base address decided by the SoC when integrating the IP.

Note: RADIO_CONTROL_BLOCKBaseAddress is 0x6000_1000 in the STM32WB05xZ product.

Table 185. Radio Controller registers list

25.7.3.2 Radio controller registers

Table 186. RADIO_CONTROL_ID register description

Table 187. CLK32COUNT_REG register description

25.8 IP_BLE

The Bluetooth LE link layer of the IP_BLE is a programmable automate which can act as a central or a peripheral.

The Bluetooth LE link layer embeds a Sequencer which automatically reads data and job request from link tables and link lists prepared in advance by the CPU in retention RAM. This allows the Bluetooth LE link layer to start a Bluetooth LE reception or transmission directly at low-power mode exit while the CPU is still booting and not yet able to manage any firmware action.

25.8.1 Overview

The IP_BLE embeds:

• • a Bluetooth Link layer
• • a modulator
• • a demodulator

The Bluetooth LE link layer manages:

• • the reception and transmission sequences including channel hopping,
• • on-the-fly encryption thanks to an embedded AES (which can also be used by the SW to compute LE privacy and manual encryption),
• • the antenna switching feature

The Bluetooth LE link layer embeds a Sequencer which uses information located in RAM tables to manage the RF transfer and part of the Bluetooth LE protocol. Those RAM tables need to be prepared by the SW.

In general, the process to generate a Bluetooth LE transfer is the following:

• • the CPU prepares some tables in RAM containing information about the next Bluetooth LE transfer(s)
• • the CPU programs one of the 3 possible timers that triggers/starts a sequence
• • When the selected timer matches the programmed value, the Sequencer starts to execute a Bluetooth LE sequence. This implies:
  • – to read the RAM table to know what to do,
  • – to (re-)program the radio register if needed,
  • – to launch the Radio FSM with an Rx or Tx request depending on requested transfer.
  • – once the analog RF is ready to transmit (respectively receive), to read the data payload from RAM (respectively to write the data payload in RAM)
• • Once the sequence is done (successfully or with errors), the Sequencer writes back in RAM updated information (flags, pointers, etc.)

Once RAM write-back is over, the Sequencer sends an interrupt to the CPU, related to interrupt mask programmed by the CPU (through the RAM table).

25.8.2 Bluetooth LE link layer Sequencer

The Sequencer needs a trigger event to start any action.

Then the Sequencer manages a transmission or reception (or no) sequence depending on the RAM table content it reads.

25.8.2.1 Possible trigger timers for the Sequencer

Three different timers can trigger a Bluetooth LE link layer sequence:

1. Wakeup timer event

• • this timer is inside the wakeup block and is the only one able to wake up the IP_BLE (and the SoC) from a low-power state
• • this timer is based on absolute time (slow clock granularity)
• • this timer is enabled by setting the BLUE_SLEEP_REQUEST_MODE[30] = BLE_WAKEUP_EN bit and the trigger event time is programmed in the BLUE_WAKEUP_TIME[31:0]
• • if an RRM command is enabled (through the StatMach table, RadioComListEna field), the sequencer requests the Command0 to the RRM-UDRA block during the sequence.

2. Timer1 timer

• • this timer is managed by the IP_BLE Sequencer itself but using the interpolated time
• • the granularity of this counter is 16 x slow clock period
• • this timer is enabled by setting timeout
• • the Timer1 trigs an event when the current interpolated time matches (or has gone past) the scheduled time programmed in the TIMEOUTREG APB register
• • this timer cannot be used in low-power mode
• • if an RRM command is enabled (through the StatMach table, RadioComListEna field), the Sequencer requests the Command1 to the RRM-UDRA block during the sequence.

3. Timer2 timer

• • this timer is based on a relative time and starts counting at the end of the previous transmission/reception
• • the granularity of this counter is 1 µs
• • this timer is a counter located inside the Sequencer of the Bluetooth LE link layer and cannot be used in low power mode
• • the Timer2 trigs an event when the counter matches the value programmed in the Timer2[19:0] bit field of the TxRxPack RAM table
• • this timer is enabled by setting the Timer2En bit in the TxRxPack RAM table of a sequence, allowing a trigger event for the next sequence (Tx/Rx sequence)
• • this timer is supposed to be used for short time delay between two Bluetooth transfers
• • if an RRM command is enabled (through the StatMach table, RadioComListEna field), the Sequencer requests the Command2 to the RRM-UDRA block during the sequence.

Ways to manage those 3 timers:

The 3 timers are managed (enabled/disabled) in a different way. The goal of the section below is to explain how to manage according to the use-case.

Each timer is one-shot. This means once it expires, it stops and the software has to reprogram/re-enable it for a new sequence.

Furthermore, as there is no mechanism to prevent more than one timer to be active at the same time, the software must ensure it does not start a timer while another one is already on-going for the next sequence.

Here is a summary of the enable/disable method for each timer:

• • the wakeup timer is enabled and programmed through the wakeup BLUE_WAKEUP_TIME APB register and has no interference with the two others so may be enabled in addition to Timer1 or Timer2.
• • the Timer1:
  • – duration is programmed only through the IP_BLE TimeoutDestReg APB register
  • – enable is done only through the IP_BLE TimeoutDestReg APB register
  • – disable can be done through the IP_BLE TimeoutDestReg APB register
  • – a hardware disable is automatically done by the Sequencer when it treats the Timer2 enable information in the TxRxPack RAM table under execution (whatever the TxRxPack.Timer2En bit value).

• • the Timer2:
  • – can be programmed either through the IP_BLE TimeoutDestReg APB register or through the TxRxPack table
  • – can be enabled/disabled either through the IP_BLE TimeoutDestReg APB register or through the TxRxPack table.

Note:

• • Programming respectively Timer1 or Timer2 through the IP_BLE TIMEOUTDESTREG APB register automatically disables respectively the Timer2 or Timer1.
• • If the Bluetooth LE sequence ends on a receive timeout (STATUSREG.RCVTIMEOUT = 1), Timer2 is not started even if the TxRxPack.Timer2En associated to this reception was 1.
• • Even if Timer2 can be enabled through the IP_BLE controller TIMEOUTDESTREG APB register, it is recommended not to do it in application flow and to use the RAM table.
• • TIMEOUTDESTREG[1:0] and TIMEOUTREG[31:0] need to be programmed at least 15 microseconds before the required start trigger.

25.8.2.2 Bluetooth LE sequence description

The Bluetooth LE sequence starts on the trigger event (from the wakeup timer or the Timer1 or the Timer2). The sequence is managed in three mains phases:

• • Initialization (split into 3 sub-steps)
• • reception or transmission
• • Context saving (to write back some updated field in RAM tables)

At the end of those phases, an interrupt (if at least one active source enabled) is generated to the CPU.

Note: the status flags and potential associated interrupt are set only at the end of the sequence and not in real time when the event that generates them occurs.

Note: the STATUSRREG.SEQDONE flag (and INTERRUPT1REG.SEQDONE if enabled in the GlobalStatMach table) is always raised when the Sequencer exits a sequence started by a trig event, whatever the process it followed (exit on error at any steps or run up to the end without problems). For this reason, this specific flag is not mentioned/repeated each time in this section.

The first RAM access done by the Sequencer on any trigger event is to get the GlobalStatMach word 0x01 to check the active bit to know if the parameters the Sequencer is about to read in the RAM table for the 1st INIT phase can be considered as ready and up to date.

If the active bit is low, the sequence stops, and the only actions done are:

• • setting NOACTIVEERROR flag in the STATUSREG IP_BLE APB register
• • and if IntNoActiveError is set in the GlobalStatMach, setting the NOACTIVEERROR in the INTERRUPT1REG IP_BLE APB register and generating an associated interrupt.

If the GlobalStatMach.Active bit is set, then the Sequencer starts the initialization phase.

Note: an automatic Active bit auto clear during context saving phase of the sequence can be enabled through the ChkFlagAutoClearEna bit in the GlobalStatMach. This avoids unexpected Tx/Rx due to Sequencer trigger event while the SW did not update the RAM tables (kind of SW acknowledge to allow the next transfer).

The figure below provides an overview of the Sequencer steps and control versus other blocks.

Figure 200. Sequencer steps overview

25.8.2.2.1 First initialization phase

During the first initialization phase, the Sequencer only reads the minimum information it needs in the RAM table to be able to start the Radio FSM for a reception or a transmission at the end of this phase.

The Sequencer launches up to 3 parallel tasks:

1. 1. Set (or maintain if KeepSemaReq bit was set in the TxRxPack RAM table of the previous sequence) the take_req signal toward the RRM semaphore block to request/keep the token to access the radio resources.
2. 2. If the RadioComListEna bit is set in the current StatMach table, send a command to the RRM UDRA:
   • – Command 0 if trig event is the Wakeup timer
   • – Command 1 if trig event is the Timer1
   • – Command 2 if the trig event is the Timer2.
3. 3. Get the minimum information needed to be able to start the Radio FSM (transmission or reception, channel number, PLL calibration requested or not, etc.).

At the end, this task also computes the channel number through the channel incrementer hardware block if requested and writes few radio registers (MOD_DEM_DIG_USR, RADIO_FSM_USR and PHYCTRL_DIG_USR) according to information from the RAM tables.

This first initialization step ends on a timeout defined by a bit field in the GlobalStatMach:

• • WakeupInitDelay (time unit is 16 x slow clock so typically 512 kHz) when trig event source is the wakeup timer

Note: despite the wakeup trigger event to start the sequence being based on a slow clock granularity, typ. 32 kHz (as the trigger occurs at BLUE_WAKEUP_TIME[31:4]), the Sequencer waits until the interpolate time is BLUE_WAKEUP_TIME[31:0] + WakeUpInitDelay to exit the 1 ^st INIT step which means the 512 kHz granularity is respected.

• • Timer12InitDelayCal (time unit is 1 µs) when the trig event is the Timer1 or when the trig event is the Timer2 and CalReq bit in TxRxPack table is set (PLL calibration requested)
• • Timer2InitDelayNoCal (time unit is 1 µs) when the trig event is the Timer2 and CalReq bit in the TxRxPack table is low (no PLL calibration requested).

InitDelay is used as a generic name for this duration to simplify the documentation as it can be 3 different bit fields that define it depending on the configuration.

Note: the main constraint on this delay depends on the previous setup:

• • If KeepSemaReq bit was set in the TxRxPack of the previous transfer, then the Radio FSM stays in ACTIVE2 and the main constraint to define the delay is the AHB accesses to read the RAM tables.
• • If KeepSemaReq bit was low in the TxRxPack of the previous transfer, then the RRM semaphore releases the token and Radio FSM goes back to IDLE. Then the main constraint for the delay is the duration for the Radio FSM to reach ACTIVE2 state from IDLE (25 µs for ENA_RF_REG step and 20 µs for ENA_CURR step).
• • In parallel, if accurate clock was turned off, there is also the delay to have accurate clock available to consider.

Caution: Whatever the trig event source, this InitDelay management in the Sequencer uses the system clock and the user must ensure the system runs an accurate clock to have a precise delay.

When the InitDelay timeout expires, the Sequencer checks several conditions to decide if it switches to the second initialization step or exits with error. The checked conditions are:

• • Radio FSM reached ACTIVE2 state meaning it is ready to receive a Tx or Rx request (and system clock is the accurate clock)
• • All RAM accesses and radio register writings to be done by the Sequencer during the first initialization step are over
• • No configuration error occurred (see Section 25.8.2.3.4: Configuration error for more details)

If all the conditions are true, then the Sequencer:

• • sends a Tx or Rx request to the Radio FSM depending on transfer direction indicated by TxMode bit in the current StatMach table
• • and switches to the second initialization step.

If at least one of the conditions is false then:

• • the sequence rises the flag(s) associated to the error(s). It can be:
  • – STATUSREG.CONFIGERROR bit if a configuration error has been detected,
  • – STATUSREG.ACTIVE2ERROR bit if the Radio FSM is not in ACTIVE2 at the end of the InitDelay ,
  • – STATUSREG.SEMATIMEOUTERROR bit if the RRM semaphore did not grant the IP_BLE on time,
• • No RAM write back action is done.
• • The error bits set in the STATUSREG register also appear in INTERRUPT1REG if their associated interrupt enable bit is set in the GlobalStatMach table.

25.8.2.2.2 Second initialization step

The 2 ^nd INIT step is used by the Sequencer to get all the information from the RAM tables linked to the RF transfer to proceed (except DataPtr and TxDataReady bit fields).

This means the software must have filled all the RAM table information (except DataPtr and TxDataReady bit fields) when the InitDelay timeout expires.

The 2 ^nd INIT step starts when the Tx or Rx request is sent to the Radio FSM. The first action of the Sequencer is to read few delays in the GlobalStatMach. Those delays are needed during the 2 ^nd INIT and DATA INIT steps.

This 2 ^nd INIT step ends on a timeout based on 2 pieces of information read in the GlobalStatMach:

1. 1. init_radio_delay (in µs), used as a generic name for this duration to simplify the documentation: it is one possibility out of 4 different bit fields depending on the transfer configuration:
   • – TransmitNoCalDelayChk when the transfer is a Tx and no PLL calibration is requested (CalReq bit is low),
   • – TransmitCalDelayChk when the transfer is a Tx and a PLL calibration is requested (CalReq bit is set),
   • – ReceiveNoCalDelayChk when the transfer is an Rx and no PLL calibration is requested (CalReq bit is low),
   • – ReceiveCalDelayChk when the transfer is an Rx and a PLL calibration is requested (CalReq bit is set).
2. 2. TxdataReadyCheck: duration given to the Sequencer to get the two last pieces of information, which are DataPtr and TxDataReady information in the RAM table. This last reading is done in the third initialization step called DATA_INIT.

The 2 ^nd INIT ends after “init_radio_delay – TxdataReadyCheck” µs.

From the 2 ^nd INIT step, the Radio FSM is running in parallel to the Sequencer getting information in the RAM tables. The user must ensure the init_radio_delay duration does not exceed the RF analog setup time up to powering on the antenna for a transmission (or ready to receive on the antenna). This means the 2 ^nd INIT step must not exceed:

• • the duration of the Radio FSM to go from ACTIVE2 to Tx state for a transmission with few µs of margin
• • the duration of the Radio FSM to go from ACTIVE2 to Rx state for a reception.

1. Note:
2. • • For transmission, the init_radio_delay timeout must expire before the Radio FSM is in Tx mode to avoid missing the start of the preamble sending on the antenna (otherwise garbage is sent while the preamble is supposed to be output).
   • • For a reception, the init_radio_delay must expire close to the switch in Rx state of the Radio FSM, knowing the RcvTimeout counter starts when the init_radio_delay expires.

At the very beginning of the 2 ^nd INIT step:

• • the Sequencer starts an internal relative timer
• • In parallel, the Sequencer reads the init_radio_delay, ConfigEndDuration and TxdataReadyCheck information in the GlobalStatMach.

The 2 ^nd INIT step really starts to fetch information related to the transfer in the RAM tables when the relative timer reaches “init_radio_delay – ConfigEndDuration”.

The GlobalStatMach.ConfigEndDuration bit field allows delaying the reading of the transfer information contained in the RAM tables by the Sequencer. The goal of this delay is to provide more margin to the SW to fill the RAM table information that is read during 2 ^nd INIT. This is possible as the RAM table read session is shorter than the analog radio setup duration. The figure below provides a summary of the timing information contributors for the initialization steps.

Figure 201. Sequencer Initialization steps timings overview

25.8.2.2.3 Data initialization step

This data INIT step starts when the 2 ^nd INIT step ends.

During this step, the Sequencer only gets 2 values from the table:

• • TxDataReady bit in the TxRxPack indicating enough bytes are present in the Tx payload data buffer (in case of transmission only).
• • DataPtr bit field in the TxRxPack.

The GlobalStatMach.TxdataReadyCheck is used to delay the start of this DATA INIT step to allow more time to the software to provide the data pointer (and first values to transmit if transfer is a transmission).

The DATA INIT step ends when the relative timer (started at the beginning of the 2nd INIT step) reaches init_radio_delay:

• • if all conditions are OK (AllTableReady read at 1, TxDataReady read at 1 for a transmission, Radio FSM still in a state between ACTIVE2 and Rx or Tx, command_end received from the RRM if a UDRA command was launched in parallel, a start pulse is sent to the receive/transmit block for a reception/transmission).
• • or else no start pulse is sent to the receive/transmit block and status/interrupt flags are updated in the Bluetooth® LE APB registers (no RAM write-back is done).

For transmission, a synchronization mechanism is in place between the transmit block and the Radio FSM: the transmit block waits for the Tx state information from the Radio FSM to know when data can be sent to the modulator. As the transmit block is supposed to receive the start pulse from the Sequencer a bit before the Radio FSM reaches the Tx state, a wait window needs to be defined to avoid waiting forever: this time window is defined in the GlobalStatMach.TxReadyTimeout bit field.

Caution: It is the responsibility of the software to ensure that the init_radio_delay, the ConfigEndDuration and the TxdataReadyCheck values are coherent to guarantee both data ready on time in the table and start pulse sent on time to the receive/transmit block.

25.8.2.2.4 Transmission/reception step

The transmission/reception step starts when the start pulse is sent by the Sequencer to the transmit or to the receive block.

This step ends when the transmit/receive block indicates that the transfer is done:

• • all data transmitted for a transmission (followed by a waiting time defined by GlobalStatMach.TxdelayEnd)
• • a frame has been received or the programmed timeout to wait for a reception expired without any reception.

Important:

• • When a transmission is completed, the timer2, if it is programmed, starts counting only when GlobalStatMach.TxdelayEnd has elapsed
• • When a reception is completed, if the exit reason is a timeout, the timer2 does not start.

25.8.2.2.5 Context saving step

The context saving steps consist of RAM write-back operation in some RAM table words to update with the result of the RF transfer that just ended.

This step starts when the Sequencer obtains the transfer done information from the transmit or receive block.

The RAM write-back impacts the following RAM table elements:

• • GlobalStatMach Word1 if the GlobalStatMach.ChkFlagAutoClearEna bit is set:
  • – clear the Active bit
  • – write back the rest of the bit field of this Word1 with the value previously read by the Sequencer in the RAM table.
• • StatMach Word0: update SN, NESN, remapped channel, and next transfer direction (TxMode)
• • StatMach Word1: update the TxPoint[31:0] with TxPointNext[31:0] or keep the same.
• • StatMach Word2: update the RcvPoint[31:0] with RcvPointNext[31:0] or keep the same.
• • StatMach Word3: update the TxPointPrev[31:0] with TxPoint[31:0] or keep the same.
• • StatMach Word4: update the RcvPointPrev[31:0] with RcvPoint[31:0] or keep the same.
• • StatMach Word5: update the TxPointNext[31:0] or keep the same.
• • StatMach Word6: update the PCntTx[31:0] or keep the same.
• • StatMach Word7: update the PCntTx[39:32] and PCntRcv[23:16] or keep the same.
• • StatMach Word8:
  • – update the PCntRcv[39:24] or keep the same
  • – the rest of the Word8 is written back with value previously read by the Sequencer in the RAM table.

Note: See Section 25.8.5.1: Pointers management and packet counter for pointer management details .

25.8.2.2.6 Bluetooth® LE sequence summary

The sequences of operations characterizing a transmission and a reception are summarized in the following timing diagrams.

Figure 202. Tx sequence

Figure 203. Rx sequence

25.8.2.3 Possible root causes of aborted sequence

It may happen that the sequence is not started or interrupted before the end for different reasons.

In any case, the SeqDone flag (and interrupt if enabled) occurs at the end of a sequence whatever the status (successful or failed).

Then, some status/error flags (with associated maskable interrupt) are available to obtain the reason of the abortion or to have complementary information on the sequence that just occurred.

25.8.2.3.1 Active bit is low

The sequence is stopped just after the trigger event because the Active bit in the GlobalStatMach RAM table is read equal to 0.

If active bit is low, then:

• • no sequence is started (Radio FSM and transmit/receive blocks not informed),
• • no timer management is done (no update / reprogramming of the different timers is done),
• • no RAM write-back occurs, RAM tables are left unchanged,
• • the NOACTIVEERROR bit is set in the STATUSREG IP_BLE APB register,
• • if the NOACTIVEERROR bit in the GlobalStatMach word 0x05 is set, the NOACTIVEERROR bit is set in the INTERRUPT1REG IP_BLE APB registers and a Bluetooth® LE interrupt is generated to the CPU
  • – The enable mask is readable in INTERRUPT1ENABLEREG.NOACTIVEERROR bit.

25.8.2.3.2 RRM semaphore does not grant the IP_BLE on time

On a trigger event and if active bit is high, the Sequencer requests the token to the RRM semaphore to have control of the radio resources.

If, at the end of the initialization delay (WakeupInitDelay or Timer12InitDelayCal or Timer2InitDelayNoCal), the RRM still does not confirm the IP_BLE has been granted, then:

• • no sequence is started (Radio FSM and transmit/receive blocks not informed)
• • no timer management is done (no update/reprogramming of the different timers is done)
• • no RAM write-back occurs, RAM tables are left unchanged,
• • the SEMATIMEOUTERROR bit is set in the STATUSREG IP_BLE APB register
• • if the IntSemaTimeoutError bit in the GlobalStatMach word 0x05 is set, the SEMATIMEOUTERROR bit is set in the INTERRUPT1REG IP_BLE APB registers and an interrupt is generated to the CPU
  • – The enable mask is readable in INTERRUPT1ENABLEREG.SEMATIMEOUTERROR bit.

25.8.2.3.3 Radio FSM not in ACTIVE2 state on time

This error happens if the Radio FSM is not in ACTIVE2 state at the end of the 1 ^st INIT step (on InitDelay timeout expiration).

If, at the end of the initialization delay (WakeupInitDelay or Timer12InitDelayCal or Timer2InitDelayNoCal), the Radio FSM has still not confirmed it is ready to start a Tx or Rx sequence (no accurate clock present for instance):

• • no sequence is started (Radio FSM and transmit/receive blocks not informed)
• • no timer management is done (no update/reprogramming of the different timers is done)
• • no RAM write-back occurs, RAM tables are left unchanged
• • the ACTIVE2ERROR bit is set in the STATUSREG IP_BLE APB register

• • if the IntActive2Error bit in the GlobalStatMach word 0x05 is set, the Active2Error bit is set in the INTERRUPT1REG Bluetooth® LE APB registers and a IP_BLE interrupt is generated to the CPU
  • – The enable mask is readable in INTERRUPT1ENABLEREG.ACTIVE2ERROR bit.

25.8.2.3.4 Configuration error

A configuration error occurs if the value contained by the Rcvpoint or Txpoint field or IQSamplingPtr of the current StatMach RAM table is not modulo 4 (does not correspond to a 32-bit aligned address).

Note: the StatMach.IQSamplingPtr value is checked only for some values in other RAM table bit fields. Refer to Section 25.8.6.4.4: IQSamplesPtr[31:0] or AntennaPatternPtr[31:0] not 32-bit aligned for details .

In this case:

• • the Sequencer stops the sequence at the end of the 1 ^st initialization phase (so neither the Radio FSM nor the transmit/receive blocks received any request),
• • no timer management is done (no update/reprogramming of the different timers)
• • no RAM write-back occurs
• • the STATUSREG.CONFIGERROR bit is set
• • if the IntConfigError bit in the GlobalStatMach RAM table is set, the INTERRUPT1REG.CONFIGERROR is set and an IP_BLE interrupt is generated
  • – The enable mask is readable in INTERRUPT1ENABLEREG.CONFIGERROR bit.

25.8.2.3.5 Address pointer error

An address pointer error occurs if the TxRxPack.NextPtr[31:24], the TxRxPack.DataPtr[31:24] or the StatMach.IQSamplestPtr[31:24] (if TxRxPack.CTEAndSamplingEnable=1) is not equal to the SoC RAM base address.

In this case:

• • no transmission or reception is started
• • the Tx or Rx request towards Radio FSM is canceled
• • no RAM write-back is done
• • the STATUSREG.ADDPOINTERROR bit is high at the end of the sequence
• • if the IntAddPointError bit in the GlobalStatMach is high, the INTERRUPT1REG.ADDPOINTERROR bit is set and an IP_BLE interrupt is generated.
  • – The enable mask is readable in INTERRUPT1ENABLEREG.ADDPOINTERROR bit.

25.8.2.3.6 PLL lock fail (only if GlobalStatMach.AutoTxRxSkipEn = 1)

If the AutoTxRxSkipEn bit in the GlobalStatMach RAM table is set, the Sequencer skips the sequence if the PLL lock fail information is raised.

This PLL lock fail corresponds to the fact that the PLL did not lock on time and is provided by the Radio FSM. It is checked by the Sequencer at the end of the initialization step, before entering the Tx-Rx step.

In this case:

• • no transmission or reception is started
• • the Tx or Rx request towards Radio FSM is canceled
• • no RAM write-back is done
• • the STATUSREG.TXRXSKIP bit is high at the end of the sequence
• • if the IntTxRxSkip bit in the GlobalStatMach is high, the INTERRUPT1REG.TXRXSKIP bit is set and a Bluetooth® LE interrupt is generated
  • – The enable mask is readable in INTERRUPT1ENABLEREG.TXRXSKIP bit.

25.8.2.3.7 TxRxSkip APB command

An APB command is available to skip an on-going Tx or Rx transfer. The software needs to write '1' in the TXRXSKIP bit of the CMDREG IP_BLE APB register.

Note: This bit is auto-cleared immediately by the hardware.

The software must be aware that the TxRxSkip APB command is considered only during a sequence. Otherwise the skip request is ignored (not recorded and no TxRxSkip interrupt/status flag is raised on the next sequence).

The behavior differs depending on the TxRxSkip command that occurs inside the sequence.

Table 192. Summary of flags and RAM table pointers behavior versus Tx Skip command

Table 193. Summary of flags and RAM table pointers behavior versus Rx Skip command

In all scenarios, the IntTxRxSkip bit in the GlobalStatMach must be high to have an interrupt generated when the STATUSREG.TXRXSKIP bit is high. In this case, the INTERRUPT1REG.TXRXSKIP bit is also high. The enable mask is readable in INTERRUPT1ENABLEREG.TXRXSKIP bit.

25.8.2.3.8 AllTableReady bit not set on time

This error is linked to:

• • Interrupt mask in GlobalStatMach.IntAllTableReady.
  • – This mask is readable in INTERRUPT1ENABLEREG.ALLTABLEREADYERROR bit.
• • Status flag in ALLTABLEREADYERROR bit.
• • Interrupt flag in INTERRUPT1REG.ALLTABLEREADYERROR bit.

During the 2 ^nd INIT step, the TxRxPack.AllTableReady bit is read by the Sequencer just after the ConfigEndDuration waiting loop (but checks its value only when exiting DATA INIT step at the end of init_radio_delay).

The role of this bit is to guarantee the information related to the transmission/reception packet (especially data pointers) in the TxRxPack (except the payload bytes when transmission) are valid/up-to-date.

If the recorded TxRxPack.AllTableReady is not high:

• • no transmission or reception is started
• • Tx or Rx request towards Radio FSM is canceled
• • no RAM write-back is done
• • the STATUSREG.ALLTABLEREADYERROR bit is high at the end of the sequence
• • if the IntAllTableReadyError bit in the GlobalStatMach is high, the INTERRUPT1REG.ALLTABLEREADYERROR bit is set and an IP_BLE interrupt is generated
  • – The enable mask is readable in INTERRUPT1ENABLEREG.ALLTABLEREADYERROR bit.

25.8.2.3.9 TxdataReady bits not set on time

This bit is used only when the on-going transfer is a transmission (not checked on a reception).

It adds flexibility to the software to be able to go on filling the data payload to transmit while the transmission has already started on the antenna.

The recommendation is to set this bit only after at least 16 bytes of Tx data payload are available in the data buffer.

The Sequencer reads the TxRxPack.TxDataReady bit at the beginning of the DATA INIT step but checks its value only at the end of the init_radio_delay.

If the recorded TxRxPack.TxDataReady is not high:

• • no transmission is started
• • Tx request towards Radio FSM is canceled
• • no RAM write-back is done
• • the STATUSREG.TXDATAREADYERROR bit is high at the end of the sequence
• • if the IntTxDataReadyError bit in the GlobalStatMach is high, the INTERRUPT1REG.TXDATAREADYERROR bit is set and an IP_BLE interrupt is generated
  • – The enable mask is readable in INTERRUPT1ENABLEREG.TXDATAREADYERROR bit.

25.8.2.3.10 Receive length error

This aborting issue can occur only on reception.

A receive length error is detected if the received length value decoded in the received frame header is greater than the StatMach.MaxReceivedLength[7:0] bit field. This feature can be used when free RAM area is limited and does not allow receiving large packets.

If the receive block detects a packet length in the received header that is greater than the StatMach.MaxReceiveLength value:

• • the receiver treats only MaxReceiveLength bytes of data and stops its sequence
  • – any extra bytes sent by the demodulator are ignored
• • the data payload written back in RAM is limited to MaxReceiveLength + 2 bytes (corresponding to header + length) + potential CTEINFO byte in case of data PDU channel with CTE present
• • the Sequencer manages the reception step as usual as the receive block provides a done pulse, it receives a receive done pulse from the receive block
  • – this leads to stopping the Radio FSM receive mode while data are potentially still arriving on the antenna
• • a RAM write-back occurs
• • the STATUSREG.RCVLENGTHERROR bit is high at the end of the sequence
• • if the IntRcvLengthError bit in the GlobalStatMach is high, the INTERRUPT1REG.RCVLENGTHERROR bit is set and an IP_BLE interrupt is generated
  • – The enable mask is readable in INTERRUPT1ENABLEREG.RCVLENGTHERROR bit.

Note: As the receiver truncates the received frame to a reduced length, a CRC error occurs in parallel and potential other side effect error flags. So, the RCVLENGTHERROR flag must be considered before the others regarding a reception.

25.8.3 IP_BLE interrupts

The Bluetooth® LE link layer provides 2 separate interrupt lines:

• • int1: Bluetooth® LE sequence interrupt (linked to sequence that just occurred)
• • int2: AES interrupt (manual or LE privacy end of calculation)

The IP_BLE interrupts:

• • the IP_BLE interrupts are enabled through the RAM tables (some in the GlobalStatMach, others in TxRxPack)
• • a copy of the applied enable mask is available in the INTERRUPT1ENABLEREG IP_BLE APB register
• • the IP_BLE interrupts status can be read when an interrupt triggers at CPU level and is available in the INTERRUPT1REG Bluetooth® LE APB register

• • the IP_BLE interrupts are cleared by writing '1' in the associated bit in the INTERRUPT1REG Bluetooth® LE APB register
• • a dedicated internal timer is started when the interrupt is raised: its value is accessible in the INTERRUPT1LATENCYREG register. The goal of this register is to inform the interrupt handler SW about how long the interrupt is pending. This latency window is limited to 255 µs. Over this delay, the read value stays at 255.

Note: only enabled interrupts can be read at '1' in this INTERRUPT1REG register. To have the equivalent without enable mask, the STATUSREG IP_BLE APB register must be read.

The AES interrupts:

• • the AES interrupts are enabled through IP_BLE APB registers (MANAESCMDREG for manual AES and AESLEPRIVCMDREG for LE privacy AES)
• • the AES interrupts status can be read in the INTERRUPT2REG IP_BLE APB register and represents/means "end of calculation" information
• • the AES interrupts are cleared by writing '1' in the associated bit in the INTERRUPT2REG IP_BLE APB register.

Note: the "end of calculation" information is only available through enabled interruption. The MANAESSTATREG and the AESLEPRIVSTATREG IP_BLE APB registers contain other flags, not equivalent to INTERRUPT2REG registers.

25.8.4 IP_BLE RAM tables

Each time a trigger event is sent to the Bluetooth® LE link layer, the Sequencer fetches the RAM tables in RAM to get the needed information to know what to configure for the radio and which sequence to start (Rx or Tx).

There are several types of table:

• • The GlobalStatMach: this table is unique.
• • The StatMach: one table by active connection (up to 128 supported by the hardware).
• • The TxRxPack: one table packet in Rx or in Tx. So, there is no predefined number of those tables. They are used as a link list from one packet to another during a full connection.
• • The DataPack table corresponding to the data buffers pointed by the DataPtr in the TxRxPack. It contains the PDU section of the Bluetooth packet.

Figure 204. RAM table dependency overview gives an overview of RAM tables dependencies. In the provided example, the GlobalStatMach is currently managing the connection number X (StatMachx on-use) and the data buffer points to itself from the third transfer of each type.

Figure 204. RAM table dependency overview

25.8.4.1 GlobalStatMach RAM table

The GlobalStatMach location is frozen by hardware at address 0x2000_00C0 in the STM32WB05xZ.

25.8.4.1.1 GlobalStatMach RAM table overview

The GlobalStatMach is unique and mainly contains static information/options.

Table 194. GlobalStatMach RAM table

1. Note:
2. • • grey cells are unused cells
   • • pink cells are related to debug/qualification topic.

The following section describes the GlobalStatMach bit fields to help the user to program accurately the table.

1. Note: init_radio_delay is the generic name for the delay that can be TransmitCalDelayChk or TransmitNoCalDelayChk or ReceiveCalDelayChk or ReceiveNoCalDelayChk depending on transfer configuration (see Section 25.8.2.2.2: Second initialization step for more details).

25.8.4.1.2 GlobalStatMach RAM table registers list

Table 195. GlobalStatMach RAM table register list

Table 196. GlobalStatMach.WORD0 register description

Table 197. GlobalStatMach.WORD1 register description

Table 202. GlobalStatMach.WORD6 register description

25.8.4.2 StatMach RAM table

The StatMach table links to an active connection. There are as many StatMach tables as concurrent connections in a limit of 128 (maximum supported by the hardware).

The StatMach RAM table location is frozen by the hardware as chained just after the GlobalStatMach. The formula for a StatMach base address is:

Table 203. StatMach RAM table

Note:

• • grey cells are unused cells
• • pink cells are related to debug/qualification topic
• • green cells are related to features outside Bluetooth protocol (proprietary protocol)

The following section describes the StatMach bit fields to help the user to accurately program the table.

25.8.4.2.1 StatMach RAM table register list

Table 204. StatMach RAM table register list

Table 205. StatMach.WORD0 register description

Table 206. StatMach.WORD1 register description

Table 207. StatMach.WORD2 register description

Table 208. StatMach.WORD3 register description

Table 214. StatMach.WORD9 register description

Table 215. StatMach.WORDA register description

25.8.4.2.2 PaPower bit field description

The table below provides the PA power correspondence to program the StateMach.PaPower bit field. The SMPS of the SoC must provide a minimum voltage to reach the targeted PaPower:

• • SMPS output level = 1.4 V minimum up to 4 dBm
• • SMPS output level = 1.55 V minimum for 5 dBm
• • SMPS output level = 1.7 V minimum for 6 dBm

For 8 dBm, refer to the note after the table as this PaPower requests a specific configuration. Refer to Section 5.7: PWRC registers for SMPS programming details.

Table 228. StatMach.PaPower values

1. Several settings are needed to reach the +8 dBm in transmission:

• • Program the SMPS located in the SoC to provide 1.9 V
• • Program 0x1F in StatMach.PaPower[4:0] bit field
• • Configure the LDO_TRANSFO in bypass mode by setting radio register LDO_ANA_ENG[1] = RFD_LDO_TRANSFO_BYPASS = 1

Warning: the LDO_ANA_ENG[1] = RFD_LDO_TRANSFO_BYPASS bit must be reset in reception.

25.8.4.3 TxRxPack RAM table

Table 229. TxRxPack RAM table

Note:

• grey cells are unused cells
• pink cells are related to debug/qualification topic.

25.8.4.3.1 TxRxPack RAM table register list

Table 230. TxRxPack

Table 231. TxRxPack.WORD0 register description

Table 232. TxRxPack.WORD1 register description

25.8.4.4 DataPack RAM table

The DataPack tables are the data buffer for reception or transmission packet. They are pointed by the TxRxPack.DataPtr value.

Their content corresponds to the PDU (header bytes, payload and potentially MIC for encrypted packets).

25.8.5 Complementary information

25.8.5.1 Pointers management and packet counter

The Sequencer updates the pointers and packet counters at the end of a transmission or a reception, depending on some parameters.

Figure 205. Pointer management and packet counter increment algorithm shows the actions made on the pointers and packet counter.

Figure 205. Pointer management and packet counter increment algorithm

25.8.5.2 Channel number management

The Bluetooth LE link layer manages the channel frequency through different parameters located in the RAM table.

A channel incrementer allows calculating a new channel if TxRxPack.IncChan bit is set. The algorithm (#1 or #2) is selected through the TxRxPack.ChanAlgo2Sel bit.

In addition, a remap is done to fit with the StatMach.UserChannelFlags if TxRxPack.IncChan bit is set.

Figure 206. Bluetooth LE link layer channel management overview presents an overview of the channel number management.

Figure 206. Bluetooth LE link layer channel management overview

When the channel incrementer hardware block is used (IncChan = 1), the selection of the algorithm must be managed by the SW following Table 235. Truth table to select the correct algorithm below.

Table 235. Truth table to select the correct algorithm

In addition, the following table lists the different bit field in RAM tables linked to the channel number management and indicates which ones are used at hardware level according to targeted algorithm (#1 or #2).

Table 236. RAM table bit fields usage versus algorithm number

25.8.5.3 Time capture

The IP_BLE can capture the absolute time on specific events.

The capture feature is enabled inside the RAM tables and the result is provided in an IP_BLE APB register called TIMECAPTUREREG[31:0].

The events that can be time stamped / captured are:

• • Sequencer reaches the end of 1 ^st INIT step ( InitDelay timeout)
• • Sequencer reaches the end of DATA INIT step ( init_radio_delay timeout)
• • “On the air” last bit transmitted/received bit (depending on Rx or Tx current mode)
• • Preamble + Access Address detection event on a reception

The time capture service is associated to an interrupt flag that is enabled through the TxRxPack.IntTimeCapture bit and status / interrupt flag at the end of the sequence is available in the IP_BLE APB STATUSREG.TIMECAPTURETRIG (and INTERRUPT1REG.TIMECAPTURETRIG if interrupt is enabled inside the TxRxPack table).

If several events are requested to be captured on a same sequence (e.g. Sequencer reaches end of 1 ^st INIT and “on the air” last bit), the latest occurrence is the available time inside the TIMECAPTUREREG register.

On a transmission sequence:

Table 237. Transmission sequence

Table 238. Reception sequence

25.8.5.4 Sequencer timings recommended values

The 2 ^nd INIT and DATA INIT steps of the Sequencer use several timing parameters in addition to the init_radio_delay. This generic name covers 4 different durations depending on the transfer configuration (Tx/Rx, PLL calibration/No calibration).

For reminder, the Radio FSM and the Sequencer run in parallel with almost no handshake from the start of the 2 ^nd INIT phase.

A set of timings is programmed in the GlobalStatMach to guarantee the Sequencer starts the transmission (respectively reception) phase with respect to the Radio FSM progress.

Figure 207. Timings of an Rx sequence and Figure 208. Timings of a Tx sequence show a summary of involved timings.

Figure 207. Timings of an Rx sequence

Figure 208. Timings of a Tx sequence

Reminder on main constraints for a transmission:

• the DATA_INIT step must end before the Radio FSM reaches the Tx state.
  • it is possible to take some margin as the TxReadyTimeout delay allows waiting for the confirmation that the Radio FSM is in Tx state before really starting the TxDelayStart timeout (see Figure 202. Tx sequence).
• if TxRxPack.IncChan = 0, the Sequencer reads the PaPower[4:0] information from the RAM table only after the ConfigEndDuration temporization.
  • the ConfigEndDuration value must be big enough to ensure the Sequencer treats this information before the Radio FSM reaches the EN_PA state.

Reminder on main constraints for a reception:

• the DATA_INIT step must end close to the moment the Radio FSM reaches the Rx state as it corresponds to the start of the Receive timeout window.
• the Sequencer transfers the StatMach.accaddr information in the AA0_DIG_USR to AA3_DIG_USR radio registers for the demodulator block. This transfer in the radio register is done only after the ConfigEndDuration temporization. This information is used by the demodulator and must be present before the Radio FSM reaches the Rx state.
  • the ConfigEndDuration value must be big enough to ensure the Sequencer starts the activity before the Radio FSM reaches the Rx state.

Table 239. Delays for Sequencer 2 ^nd INIT step proposal shows some recommendations/proposals on values for some timings programmed through RAM tables.

Table 239. Delays for Sequencer 2 ^nd INIT step proposal

25.8.6 Angle of arrival (AoA) and angle of departure (AoD)

The Bluetooth Core Specification v5.1 introduces new capabilities that support higher-accuracy direction finding. The Bluetooth direction finding exploits some of the fundamental properties of radio waves by taking several phases and amplitude measurements (across different antenna) that can be used in direction finding calculations at precise intervals in a process known as In-phase and Quadrature Sampling (IQ sampling).

Applications use this data in calculations that involve trigonometry and information about the design of the antenna array.

A single IQ sample consists of the wave's amplitude and phase angle represented as a set of Cartesian coordinates. Applications can transform this Cartesian representation into corresponding polar coordinates that yield the phase angle and the amplitude value.

The existing RAM tables have been upgraded to support the new hardware features (CTE, I/Q sampling and Antenna Switching) added to support the direction-finding topic.

25.8.6.1 RAM tables and registers impact

The existing RAM tables have been upgraded to support the new hardware features (CTE, I/Q sampling and Antenna Switching) added to support the direction-finding topic.

25.8.6.1.1 GlobalStatMatch RAM table

The GlobalStatMach table size has not been impacted: still 7 words = 28 bytes.

A new bit field has been added in the RFU existing Word6: DefaultAntennaId[6:0] bit field in Word6[6:0].

This bit field is mandatory for the configurations where more than one antenna is present on the board.

This bit field indicates which antenna identifier must be used to transmit or receive packets without CTE or packet body (Preamble, Access Address, PDU, and CRC) for CTE enabled packets. This value is transmitted through the corresponding pads of the device to the external component located on the board to switch on the requested antenna.

25.8.6.1.2 StatMach RAM table

The StatMach RAM table size has been increased by 3 words for a total of 23 words = 92 bytes.

The additional bit fields are the following:

• CTEDisable bit in Word0[27]. If set,
  • in transmission: no CTE appended at the end of the Frame whatever the TxRxPack.CTEAndSamplingEnable bit value
  • in reception: no CTE detection nor treatment done on the PDU, frame treated as a Bluetooth® LE core 5.0 or less format.

• • CTETIME[4:0] bit field in Word14[6:2]:
  • – used only when StatMach.CTEDisable=0, TxRxPack.CTEAndSamplingEnable=1 and StatMach.TxMode=1 ,
  • – same format as the CTEInfo CTETIME bit field (time unit = 8 µs),
  • – provides the duration of the Constant Tone Extension to append after CRC.
• • CTESlotWidth bit in Word14[1]:
  • – in transmission and AoD use-case: used to control the antenna switching timing,
  • – in reception and in AoA use-case: used to control the antenna switching and the I/Q sampling timings,
  • – not needed in other configurations,
  • – used only when StatMach.CTEDisable=0, TxRxPack.CTEAndSamplingEnable=1 .
• • MaximumIQSamplesNumber[6:0] bit field in Word14[14:8]:
  • – needed in reception only to indicate the maximum I/Q samples that can be stored in RAM,
  • – if more I/Q samples are received (CTE time longer than maximum samples allowed), the sequence goes on but the AHB master stops storing the additional receive samples.
  • – used only when StatMach.CTEDisable=0, TxRxPack.CTEAndSamplingEnable=1 and StatMach.TxMode=0 .
• • IQSamplesPtr[31:0] bit field in Word15[31:0]:
  • – needed in reception only to indicate the start address in RAM to store the I/Q samples received during the CTE,
  • – the address contained by this pointer must be 32-bit aligned and MSByte value must be equal to the MSByte of the RAM base address of the device,
  • – used and verified only when StatMach.CTEDisable=0, TxRxPack.CTEAndSamplingEnable=1, StatMach.TxMode=0 and StatMach.MaximumIQsamplesNumber >0 .
• • AntennaPatternLength[7:0] bit field in Word14[23:16]:
  • – needed when antenna switching must be managed on the current transfer (in transmission if AoD / in reception if AoA),
  • – defines the length of the Antenna ID pattern to be applied during the CTE. If the CTE duration requires more slots than the length defined here, the same pattern is repeated until the end of the CTE phase,
  • – used only when StatMach.CTEDisable=0 and TxRxPack.CTEAndSamplingEnable=1 .
• • AoD_nAoA bit in Word14[0]:
  • – used only when StatMach.CTEDisable=0, TxRxPack.CTEAndSamplingEnable=1 and StatMach.TxMode=1 ,
  • – indicates to the transmitter if it has to manage antenna switching (AoD) or not (AoA) during the transmission when CTE is enabled.
• • AntennaPatternPtr[31:0] bit field in Word16[31:0]:
  • – needed when antenna switching has to be managed to indicate the start address of the antenna pattern (the antenna pattern is a list of 8-bit values describing the antenna identifier),
  • – the RAM location addressed by the StatMach.AntennaPatternPtr shall contain at least StatMach.AntennaPatternLength bytes,
  • – used and verified only when StatMach.CTEDisable=0, TxRxPack.CTEAndSamplingEnable=1 and StatMach.AntennaPatternLength>0 .

25.8.6.1.3 TxRxPack RAM table

The TxRxPack RAM table size has been decreased by 1 word for a total of 4 words = 16 bytes.

A new CTEAndSamplingEnable bit has been added in Word1[3]. The role of this bit is to indicate to the MR_BLE IP:

• • In transmission:
  • – to append a Constant Tone Extension after the CRC
  • – to manage the antenna switching if AoD use-case

• • In reception:
  • – to detect if the received frame has a CTE and to extract details from the CTEInfo
  • – to manage the I/Q Sampling storage in RAM
  • – to manage the antenna switching if AoA use-case.

25.8.6.2 Manage the feature in transmission

If the SW wants to append a Constant Tone Extension at the end of the frame, it has to:

• • ensure the StatMach.CTEDisable bit is 0,
• • program the CTE duration in the StatMach.CTETIME[4:0] (same format as the CTETIME bit field of the CTEInfo defined by the standard),
• • set the TxRxPack.CTEAndSamplingEnable = 1 for this dedicated packet.

In case of encrypted frame, the AES encrypts or not the HEADER3 thanks to the TxRxPack.Advertise information.

Note:

The transmit block does not decode on the fly the bytes provided by the RAM Data Buffer (located at DataPtr address) to identify the CTE information. It relies on the information provided through the RAM table. It is the responsibility of the SW to guarantee the coherency between the CTE related bit field in RAM and the data in RAM that corresponds to the CTEInfo bit field inside the frame on the air.

In addition to the CTE append on the transmitted frame, if the device must manage the antenna switching (AoD configuration), the SW has to:

• • define the default Antenna ID for the packet body through the GlobalStatMach.DefaultAntennaId[6:0] bit field,
• • provide the start address of the antenna pattern through the StatMach.AntennaPatternPtr[31:0] bit field,
• • provide the antenna pattern / sequence length through the StatMach.AntennaPatternLength[7:0] bit field,
• • fill the RAM location pointed by the StatMach.AntennaPatternPtr[31:0] bit field with 8-bit antenna identifier (the SW must ensure this RAM area contains at least StatMach.AntennaPatternLength[7:0] antenna ID),
• • if needed, tune the TX_TIME_TO_SWITCH[6:0] timing in the ANTSW2_DIG_USR radio register to compensate potential delay between the modulator to antenna path versus antenna switching component control signals.

In parallel, the SW must ensure the SoC GPIOs have been programmed in the accurate configuration to output the Antenna Identifier and enable signals to the external component.

Note: To execute a transmission without CTE phase appended at the end of the frame, the SW just must set the StatMach.CTEDisable bit to 1.

25.8.6.3 Manage the feature in reception

25.8.6.3.1 CTE detection and decoding

If the SW wants the MR_BLE to execute a reception with the ability to detect if the received frame is a packet with or without CTE, it has to:

• • set the StatMach.CTEDisable bit to 0,
• • set the TxRxPack.CTEAndSamplingEnable bit to 1.

In case of encrypted frame, the AES decrypts or not the HEADER3 thanks to the TxRxPack.Advertise information.

Table 240. Behavior versus CTEDisable and CTEAndSampling bits value shows the behavior according to the combination between TxRxPack.CTEAndSamplingEnable and StatMach.CTEDisable .

Table 240. Behavior versus CTEDisable and CTEAndSampling bits value

During the reception, the receiver extracts from the frame the CTE info like duration, slot width and type. The only configuration for which the MR_BLE needs to get the information from the RAM table is the Angle of Arrival (AoA). In this specific case, the slot width is not indicated in the CTEType[1:0] bit field:

• 00: AoA
• 01: AoD with 1 µs slots
• 10: AoD with 2 µs slots
• 11: reserved for future use

In AoA, the receiver device is the owner of the antenna switching and of the time slot width choice. In this specific configuration, the SW must provide the information through the StatMach.CTESlotWidth bit.

25.8.6.3.2 I/Q sampling

The MR_BLE stores the I/Q samples in words built as follows:

• I[15:0] as 16 MSbit
• Q[15:0] as 16 LSbit

As the AHB master writes both I and Q in one 32-bit access in RAM, the IQSamplesPtr must contain a 32-bit aligned address.

To manage a reception in CTE with I/Q sampling, the SW has:

• to set the reception has CTE aware (refer to previous sub-section),
• to program the maximum number of I/Q samples that are allowed to be written in RAM (between 0 and 127 I+Q) through the StatMach.MaximumIQSamplesNumber[6:0] bit field,
• to define the start address to store the I/Q samples in the StatMach.IQSamplesPtr[31:0] .

At the end of the reception, some status bit fields are provided to give visibility on what has been received:

• IP_BLE APB register called STATUS2REG [0] = IQSamplesReady.
  • when set, indicates I/Q sampling has been received
  • when set, means that the received frame embedded a Constant Tone Extension at the end
• IP_BLE APB register called STATUS2REG [7:1] = IQSamplesNumber[6:0]
  • provides the number of I/Q samples stored in RAM.

25.8.6.3.3 Antenna switching

In addition to the CTE detection and the I/Q sampling storage, in AoA, the device has to manage the antenna switching. To achieve this, the SW has to:

• define the default Antenna ID for the packet body through the GlobalStatMach.DefaultAntennaId[6:0] bit field,

• • provide the start address of the antenna pattern through the StatMach.AntennaPtr[31:0] bit field,
• • provide the antenna pattern / sequence length through the StatMach.AntennaLength[7:0] bit field,
• • fill the RAM location pointed by the StatMach.AntennaPtr[31:0] bit field with 8-bit antenna identifier (the SW must ensure this RAM area contains at least StatMach.AntennaLength[7:0] antenna ID),
• • if needed, tune the RX_TIME_TO_SWITCH[5:0] timing in the ANTSW1_DIG_USR radio register to compensate potential delay between antenna path to demodulator versus antenna switching component control signals,
• • if needed, tune the RX_TIME_TO_SAMPLE[6:0] timing in the ANTSW0_DIG_USR radio register to center the I/Q sampling action inside the slot window.

In parallel, the SW must ensure the SoC GPIOs have been programmed in the accurate configuration to output the Antenna Identifier and enable signals to the external component.

Note: The hardware automatically restarts the antenna switching pattern from its first element if there are more CTE slots than the AntennaLength value provided in the StatMach.

25.8.6.4 Error management

Several error cases are treated at hardware level concerning CTE, I/Q sampling and antenna switching.

25.8.6.4.1 Invalid CTEType received

Expected values for the CTEType[1:0] bit field inside the CTEInfo are “00”, “01” or “10”. If the receiver decodes a CTEType[1:0] = “11” in a CTE packet, it behaves as if TxRxPack.CTEAndSamplingEnable = 0 (CTE time duration respected for reception phase but no I/Q sampling nor antenna switching management).