23. Radio IP

23.1 Introduction

The STM32WB07xC and STM32WB06xC Bluetooth LE controller is a programmable automate, which can act as a master or a slave node compliant up to the Bluetooth® LE standard.

The Bluetooth® LE controller is a coprocessor intended to perform transmission and reception operations without the direct control of the CPU following the instructions included inside some predefined linked lists in RAM. Then, the task of a dedicated link layer firmware is to fill these lists in advance. This allows the controller to start a transaction directly at low power mode exit while the CPU is still booting.

Typically, a processor interrupt service routine runs at the end of every transmitted or received packet in order to prepare/modify the linked lists in RAM or inform the host about changes. When the ISR execution time is a key point, the controller offers the possibility to check if there is enough time to complete the planned transmission/reception and to check the coherency of the RAM lists preventing the reading of not updated data. Furthermore, the controller reads its configuration in three different consecutive phases giving to the CPU the maximum computation time.

The internal sequence of autonomous actions about the transmission or reception is triggered by a timer event that can either wake up the device from deep sleep or not.

A free running counter driven by the internal or external slow clock is always active during sleep mode and provides the absolute time used as reference to schedule the controller activity. It is located in a programmable wakeup block that is also in charge to execute the request from the radio to go into sleep. The CPU is able to program the wakeup block accessing specific registers through the APB interface of the controller.

The Bluetooth® LE controller embeds the following main components:

• • A sequencer, which synchronizes the overall link controller. The sequencer controls all the steps from the beginning (one timer trigger) to the last step (interrupt sent to the CPU).
• • An AHB arbiter block which allows the communication with an SOC.
• • A channel incrementer block which implements in hardware the two-channel incrementing algorithm described in Bluetooth core specification 5.2.
• • An AES hardware engine which is able to manage simultaneously three processes:
  • – An “On the fly” data packet payload encryption or decryption.
  • – An AES 128-bit manual encryption.
  • – An LE privacy resolution engine which complies with Bluetooth core specification 5.2.
• • A transmit block which takes care of the framing of the advertise or data packet. It supports all coded PHY frame format (with S=2 and S=8) and uncoded PHY frame format (1 Mbps and 2 Mbps). It supports data packet length and advertise packet length up to 255 bytes. The transmit block generates ‘on the fly’ the CRC and the data whitening.
• • A receive block which takes care of the data payload de-whitening and the CRC checking for an advertise or data packet. It supports indirectly all coded PHY frame format (with S=2 and S=8) and uncoded PHY frame format (1 Mbps and 2 Mbps). The receive block supports data packet length and advertise packet length up to 255 bytes. It extracts all the header information to ease the sequencer processing.
• • An APB main block that manages all the read/write requests coming from the SOC.
• • An SN/NESN automatic mechanism, which is automatically disabled when a sequence skip is requested or when no receive buffer is available in RAM.

23.2 Functional description

Three possible timers (wakeup timer, timer1 and timer2) trigger the start of the controller internal sequence. Wakeup timer and timer1 are based on the absolute machine time. Timer2 is only relative to the end of the previous transmitted or received packet. The wakeup timer is the only timer that is always on during the sleep mode, so it is the only one able to wake up the system when the digital power supply is switched off.

Each time a trigger event is sent to the Bluetooth LE controller, the sequencer fetches specific tables in RAM to get the required information to know what to configure about the radio and which sequence to start (RX or TX). There are several types of tables:

• • The GlobalStatMach: this table is unique. As the name suggests, it contains valid information for each active link on the device.

• • The StatMach: one table for each active link (up to 128 supported by the hardware), called in this context state machine. It contains information such as: the channel, the transmit power and the link to the current action to be performed by the radio, defined by a TxRxPack.
• • The TxRxPack: one table for a packet in RX or in TX. There is no predefined number of these tables. They are organized in link lists where each packet points to the next one.
• • The DataPack table corresponding to the data buffers pointed by the DataPtr in the TxRxPack. It contains the PDU section of the Bluetooth packet.

After the Bluetooth LE controller is triggered by one of the three timers, the following six actions define the usual sequence related to a radio transaction.

1. 1. The Bluetooth LE controller reloads its configuration from retention RAM in order to restore its state (this state might have been modified by the CPU during its interrupt: see action 6 in this list). The link controller reloads its configuration in more separated phases giving more computation time to the CPU.
2. 2. The Bluetooth LE controller requests the radio access. This action occurs in parallel when action 1 is running.
3. 3. Data transmission or data reception.
4. 4. After the end of all previous actions, the Bluetooth LE controller writes back its configuration into several tables in RAM and issues an interrupt to the CPU. Depending on internal interrupt enable configuration, the link controller may increase its interrupt (which is connected to the CPU).
5. 5. On interrupt detection, the CPU starts an interrupt service routine (ISR) which checks the controller interrupt status register, reads the configuration saved by the controller in RAM and reads the data received PDU in RAM (in case of valid PDU packet reception). The change from one link state machine to another one is defined by a dedicated function of the ISR, which changes the “CurStMachNum” variable value in the GlobStatMach table.
6. 6. After all the previous activities have ended, the CPU may ask the wakeup block to send a sleep request to the power manager block (PM) to go into sleep mode.

23.3 Radio resource manager (RRM)

The radio resource manager (RRM) is the block that manages the requests performed by the Bluetooth LE controller 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 Bluetooth LE controller 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 Bluetooth LE controller
• • Port 1 for the CPU (it is a virtual port in this case)

By default, neither the Bluetooth LE controller nor the CPU has access to the radio. A contributor (Bluetooth LE or CPU) needs to request a token. The token is requested by software for the CPU. It is done by hardware for the Bluetooth LE controller 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.

23.3.1 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.

The main goal of this block is to allow the Bluetooth LE controller to reinitialize the radio registers after a low power mode sequence to start an RF communication while the CPU is still being booted.

23.3.1.1 UDRA RAM command link list

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

• • the RadioConfigPtr field of the GlobalStateMach contains the start address of the command start list
• • the command start list is a 32-bit element table containing the first command addresses of each command number of each port (more command lists are available for each port)

• each command of each port contains some read and/or write actions on radio registers.

The RadioConfigPtr value is loaded by the RRM-UDRA automatically when the radio controller 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=Bluetooth LE, port1= VP_CPU)
• port0 supports 3 command lists
• port1 supports 4 command lists.

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

Table 75. Command start list details

23.3.1.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 76. UDRA command format in RAM

Basic examples:

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 new value.

2) Read of the 4 AFCx_DIG_ENG register chained with a write of 0x54 value in RADIO_FSM_USER through port1.command1:

@port1.command1_addr = 0x84; Read 4 data

@port1.command1_addr+1 = 0xAFC0_DIG_ENG_ADDR

@port1.command1_addr+6 = 0x01; Write 1 data

@port1.command1_addr+7 = 0x RADIO_FSM_USER_ADDR;

@port1.command0_addr+8 = 0x54; 1st (and unique) data to write in RADIO_FSM_USER register

@port1.command0_addr+9 = 0x00; null command

Note: @port1.command1_addr+2 to @port1.command1_addr+5 contents are written by the RRM-UDRA block with the result of read.

At the end of the execution:

• • @port1.command1_addr+2 contains the AFC0_DIG_ENG register value
• • @port1.command1_addr+3 contains the AFC1_DIG_ENG register value
• • @port1.command1_addr+4 contains the AFC2_DIG_ENG register value
• • @port1.command1_addr+5 contains the AFC3_DIG_ENG register value
• • RADIO_FSM_USER register has been modified with 0x54

23.3.2 Direct register access

The direct register access block allows the software to access the radio registers directly through an APB access. The radio registers are mainly used to control the analog part of the radio and the radio FSM. The software has to read/write the RF APB registers located inside the RRM APB register list that points directly to the radio registers. The RF APB registers start at RRM address + 0x100. The radio registers are 8-bit only so the APB register bit field [31:8] part is padded with 0. Then, they can be accessed as 32-bit APB registers (address incremented by 4 between each register) through RRM direct access interface. The radio registers can be also accessed exploiting RRM UDRA command list in RAM as 8-bit registers (address incremented by 1 between each register). 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 round-robin priority mechanism. 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).

23.3.2.1 CPU access to radio resources

Although the CPU can request the use of radio resources through the RRM, in most cases read and write accesses to the radio registers can be done directly through APB inside the RRM APB registers. In this case, reading is not intrusive, it is faster and there is no risk even if a radio transaction is on-going. Writing to radio registers is not supposed to be done during a radio transfer. Writing through RRM commands can be safer in order to avoid changes while a radio transaction is on-going. Nevertheless, if this is done very close to a trig event, it is not possible to know which command is executed first between radio and CPU so which setting is used for the coming transaction.

23.3.3 RRM registers

Table 77. RRM register list

Table 78. RRM_ID register description

Table 79. RRM_CTRL register description

Table 80. UDRA_CTRL0 register description

Table 81. UDRA_IRQ_ENABLE register description

Table 82. UDRA_IRQ_STATUS register description

Table 83. UDRA_RADIO_CFG_PTR register description

Table 84. SEMA_IRQ_ENABLE register description

Table 85. SEMA_IRQ_STATUS register description

Note: The Bluetooth LE controller 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 controller and the RRM block.

Table 88. VP_CPU_CMD_BUS register description

Table 89. VP_CPU_SEMA_BUS register description

Table 90. VP_CPU_IRQ_ENABLE register description

Table 91. VP_CPU_IRQ_STATUS register description

23.3.3.1 Radio registers (RRM address + 0x100)

They can be accessed through two different mappings:

• as 32-bit APB register (address incremented by 4 between each register) through RRM direct access interface as 8-bit register (address incremented by 1 between each register) through RRM UDRA command list in RAM.

Table 92. AA0_DIG_USR register description

Table 106. LR_PD_THR_DIG_ENG register description

Table 107. LR_RSSI_THR_DIG_ENG register description

Table 108. LR_AAC_THR_DIG_ENG register description

Table 109. DTB0_DIG_ENG register description

Table 110. DTB5_DIG_ENG register description

Table 111. MOD0_DIG_TST register description

Table 112. MOD1_DIG_TST register description

Table 113. MOD2_DIG_TST register description

Table 114. MOD3_DIG_TST register description

Table 115. RXADC_ANA_USR register description

Table 116. LDO_ANA_ENG register description

Table 117. CBIAS0_ANA_ENG register description

Table 118. CBIAS1_ANA_ENG register description

Table 123. SYNTHCAL3_DIG_OUT register description

Table 124. SYNTHCAL4_DIG_OUT register description

Table 125. . SYNTHCAL5_DIG_OUT register description

Table 126. FSM_STATUS_DIG_OUT register description

Table 127. IRQ_STATUS_DIG_OUT register description

Table 128. RSSI0_DIG_OUT register description

Table 129. RSSI1_DIG_OUT register description

Table 130. AGC_DIG_OUT register description

Table 131. DEMOD_DIG_OUT register description

Table 132. AGC0_ANA_TST register

Table 133. AGC1_ANA_TST register description

Table 134. AGC2_ANA_TST register description

Table 135. AGC0_DIG_ENG register description

Table 136. AGC1_DIG_ENG register description

Table 137. AGC2_DIG_ENG register description

Table 138. AGC3_DIG_ENG register description

Table 139. AGC4_DIG_ENG register description

Table 147. AGC12_DIG_ENG register description

Table 148. AGC13_DIG_ENG register description

Table 149. AGC14_DIG_ENG register description

Table 150. AGC15_DIG_ENG register description

Table 151. AGC16_DIG_ENG register description

Table 152. AGC17_DIG_ENG register description

Table 153. AGC18_DIG_ENG register description

Table 154. AGC19_DIG_ENG register description

Table 155. AGC20_DIG_ENG register description

Table 156. RXADC_HW_TRIM_OUT register description

Table 157. CBIAS0_HW_TRIM_OUT register description

Table 158. CBIAS1_HW_TRIM_OUT register description

Table 159. AGC_HW_TRIM_OUT register description

23.4 Radio FSM

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

23.4.1 Radio FSM sequences

This paragraph lists the main steps in radio FSM sequence.

• • The radio FSM stays in IDLE as long as the IP_BLE does not request the RRM token to indicate 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 bandgap 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 setup 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 or if no more ports request a token to the RRM semaphore.

The current state information is available in the FSM_STATUS_DIG_OUT radio register accessible by direct APB access through RRM register map (see RRM registers list).

23.4.2 Radio FSM interrupts

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

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 23.5.3: Radio controller registers for more details.

23.5 Radio controller

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

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

23.5.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 + RC64MPLL mode locked).
• • 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 period result is provided in 16 MHz half-period unit.

23.5.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).

23.5.3 Radio controller registers

Table 160. Radio Controller registers list

Table 161. RADIO_CONTROL_ID register description

Table 162. CLK32COUNT_REG register description

Table 163. CLK32PERIOD_REG register description

Table 164. CLK32FREQUENCY_REG register description

Table 165. RADIO_CONTROL_IRQ_STATUS register description

Table 166. RADIO_CONTROL_IRQ_ENABLE register description

23.6 Bluetooth LE controller sequence

The Bluetooth LE controller 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.

23.6.1 Timers

Three different timers can trig the Bluetooth LE controller sequence:

1. Wakeup timer event

• the event comes from the wakeup timer
• this timer is based on absolute time
• If enabled through the StatMach table (RadioComListEna field), the Bluetooth LE controller requests the Command0 to the RRM-UDRA block during the sequence
• This timer is located in the wakeup block and is the only one able to wake up the Bluetooth LE IP (and the SoC) from a low power state.

2. Timer1 timer

• the event comes from the Timer1
• this timer uses the interpolated time provided by the wakeup block

• • If enabled through the StatMach table (RadioComListEna field), the Bluetooth LE controller requests the Command1 to the RRM-UDRA block during the sequence
• • the Timer1 is in fact a comparator between the interpolated time provided by the wakeup block and a match value located in the sequencer of the Bluetooth LE link layer. It cannot be used in low power mode.

3. Timer2 timer

• • the event comes from the Timer2
• • this timer is based on a relative time and starts counting at the end of the previous transmission/reception for the duration programmed in Timer2[19:0] field. In particular, if enabled through the TxRxPack RAM table, then it starts counting at the end of the transfer to trig the next RF transaction or if enabled through the TimeoutDestReg APB register, it really starts counting on the next end of Rx/TX that occurs in the radio.
• • the Timer2 is a counter located inside the sequencer of the Bluetooth LE link layer. It cannot be used in low power mode and is supposed to be used for a short time between two Bluetooth transfers.

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. The three timers are managed in different ways. Therefore, the software has to ensure it does not start a timer while another one is already on-going for the next sequence.

Here is how the three timers are enabled/disabled:

• • the wakeup timer is programmed through the wakeup BLUE_WAKEUP_TIME APB register and enabled/disabled through BLUE_SLEEP_REQUEST_MODE APB register bit 30 (BLE_WAKEUP_EN). This bit is used to unmask the check BLUE-WAKEUP_TIME[31:4] versus ABSOLUTE_TIME[31:4] to generate a wakeup event when the absolute time counter matches with BLUE_WAKEUP_TIME value. It is cleared by HW when the timeout event triggers or it can be cleared through APB to disable the timer before it expires. It has no interference with the two others.
• • the Timer1:
  • – duration is programmed only through the Bluetooth LE controller TimeoutDestReg APB register
  • – enable is done only through the Bluetooth LE controller TimeoutDestReg APB register
  • – disable can be done through the Bluetooth LE controller TimeoutDestReg APB register.
• • the Timer2:
  • – can be programmed either through the Bluetooth LE controller TimeoutDestReg APB register or through the TxRxPack table
  • – can be enabled/disabled either through the Bluetooth LE controller TimeoutDestReg APB register or through the TxRxPack table.

Note:

• • Programming respectively Timer1 or Timer2 through the Bluetooth LE controller TimeoutDestReg APB register automatically disables respectively the Timer2 or Timer1.
• • During sequence execution, Timer1 is disabled when the sequencer treats the enable/disable action on Timer2 through the TxRxPack RAM table whatever the Timer2En bit value.
• • 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 Bluetooth LE controller TimeoutDestReg APB register, it is recommended not to do it in application flow and to use RAM table.
• • TimeoutDestReg[1:0] and TimeoutReg[31:0] need to be programmed at least 15 microseconds before the required start trigger.

23.6.2 Bluetooth LE sequence description

The first RAM access done by the sequencer on any trigger event is to get the GlobalStatMach word 0x01 to check the active bit.

If the active bit is low, then nothing is done except:

• • setting NoActiveLError flag in the StatusReg Bluetooth LE APB register
• • and if IntNoActiveLError is set in the GlobalStatMach, setting the NoActiveLError in Interrupt1Reg Bluetooth LE APB register and generating an associated interrupt.

Otherwise, if active bit is high, the parameters that the controller reads during the first phase are considered as ready and updated. Then, the sequencer block starts a sequence divided in several steps. At the end of these steps, an interrupt (if at least one active source enabled) is generated to the CPU.

23.6.2.1 First initialization step

The 1 ^st INIT step starts on the trigger event (from the wakeup timer or the Timer1 or the Timer2).

During this initialization step, the sequencer only reads the minimum number of parameters to request the radio initialization for a transmission or a reception.

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
• • 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).

Note: The Bluetooth LE wakeup event is based on 32 kHz granularity (absolute_time[31:4]). Then Bluetooth LE wakeup event occurs at BLUE_WAKEUP_TIME[31:4], but the controller waits until BLUE_WAKEUP_TIME[31:0] + WakeupInitDelay. It means that in any case the sequencer during 1 ^st INIT step manages the 512 kHz granularity.

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

When the 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 reaches ACTIVE2 state meaning it is ready to receive a TX or RX request (and that 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 has occurred.

If all the conditions are true, then the sequencer:

• • sends a TX or RX request to the Radio FSM depending on the 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 semaphore did not grant the Bluetooth LE IP on time
  • – DebugStatusReg.SeqError[2] bit if the sequencer did not finish all AHB read/write accesses planned during the first initialization step when timeout occurs.
• • No RAM write back action is done.
• • The error bits set in StatusReg also appear in Interrupt1Reg if their associated interrupt enable bit is set in the GlobalStatMach table.

23.6.2.2 Second Initialization step

The 2 ^nd INIT step starts when the TX or RX request is sent to the radio FSM and once few delays have been read in the GlobalStatMach by the sequencer. Those delays are needed during the 2 ^nd INIT and DATA INIT steps.

TxRxPack.AllTableReady is the first flag that the sequencer checks during the second initialization step: if it reads TxRxPack.AllTableReady = 1 then everything is OK and it continues reading the remaining parameters required for the second initialization step. If the sequencer reads TxRxPack.AllTableReady = 0 then this means that the RAM table programming is not coherent and the sequencer stops its sequence by sending an interrupt to the CPU (if enabled) and sets StatusReg.AllTableReadyError = 1.

During the 2 ^nd INIT step, the sequencer gets all the information from the RAM tables linked to the transfer to proceed (except DatPtr and TxDataReady bit fields).

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

This 2 ^nd INIT step ends on a timeout based on 2-bit fields in the GlobalStatMach:

• init_radio_delay is used as a generic name for this duration to simplify the documentation as it can come from 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),
• TxdataReadyCheck

The init_radio_delay duration must not exceed the RF analog set-up time up to power on the antenna for a transmission (or ready to receive on the antenna). This means it 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.

Note: 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 (or else garbage is sent while 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 count starts when the init_radio_delay expires.

At 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 GlobalStatMach.ConfigEndDuration bit field allows delaying the reading of the transfer information contained in the RAM tables by the sequencer. Indeed, the init_radio_delay (2 ^nd INIT + DATA INIT steps duration) must fit in the analog radio set-up duration which is supposed to be longer than the RAM tables reading by the sequencer. The 2 ^nd INIT ends when the relative timer reaches “init_radio_delay – TxdataReadyCheck”.

23.6.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). The CPU has to set TxRxPack.TxdataReady = 1 when at least four 32-bit words are available in the transmission buffer. TxRxPack.TxdataReady is the last parameter that the sequencer reads before starting to prefetch the data payload: if it reads TxRxPack.TxdataReady = 1 then everything is OK and it continues prefetching the data payload to fill its internal FIFOs. If the sequencer reads TxRxPack.TxdataReady = 0 then this means that the minimum data buffer filling is not enough and the sequencer stops its sequence by sending an interrupt to the CPU (if enabled) and set StatusReg.TxDataReadyError = 1.
• DatPtr 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 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, 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).

The transmit block receives some information from the radio FSM, it is in TX state to synchronize the moment data can start to 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.

23.6.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 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 is elapsed
• • When a reception is completed, if the exit reason is a timeout the timer2 does not start.

23.6.2.5 Context saving step

Once the sequence receives the tx_done pulse from the transmit block or the rcv_done pulse from the receive block, it starts the RAM write back operation.

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 value previously read by the sequencer in the RAM table.
• • StatMach Word0
• • 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.

23.6.3 Bluetooth LE sequence summary

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

Figure 185. TX sequence

Figure 186. RX sequence

23.6.4 TX and RX sequence signals

The controller 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 additional logical mechanism. The external PA can be useful to extend the TX power.

This signal is raised as soon as a transmission is requested (2 ^nd INIT step starting point) and goes down as soon as the system switches off the internal PA.

On the other hand, the controller provides a signal to monitor a reception request.

See RADIO_TX_SEQUENCE and RADIO_RX_SEQUENCE GPIO alternate functions in Section 7.3.2: I/O pin alternate function multiplexer and mapping to find the pins that support this feature.

23.6.5 Bluetooth LE controller registers

Table 167. Bluetooth LE controller register list

Note:

• • This StatusReg is updated on each Bluetooth LE sequencer end of sequence.
• • This register is cleared each time the Bluetooth LE sequencer starts a new sequence (timer trig event) except for the bit tagged with (*):
  • – CONFIGERROR: updated when the sequencer reads the StatMach
  • – PREVTRANSMIT: updated when the sequencer reaches the TX/RX step again
• • After a reception, an SN_NESN error is identified if the StatusReg indicates the RX is done (DONE=1), not OK (RCVOK=0) but no specific error flag is set.
• • When a proper transmission occurred, the DONE flag (in StatusReg and potentially Interrupt1Reg) and the StatusReg.PrevTransmit bit are set.

Table 175. INTERRUPT1ENABLEREG register description

Table 176. INTERRUPT1LATENCYREG register description

Table 194. AESLEPRIVSTATREG register description

Table 195. DEBUGCMDREG register description

Table 196. DEBUGSTATUSREG register description

23.7 Bluetooth LE RAM tables

Each time a trigger event is sent to the Bluetooth LE controller, 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 tables:

• • 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 link list from one packet to another during a full connection.
• • The DataPack tables corresponding to the data buffers pointed by the DataPtr in the TxRxPack. It contains the PDU section of the Bluetooth packet.

The following figure gives an overview of RAM tables dependencies.

Figure 187. RAM table tree

graph TD
    GlobalStatMach[GlobalStatMach
RadioConfigPtr
CurStatMachNum] --> CmdAddrList[CmdAddrList]
    GlobalStatMach --> UDRA[UDRA Command List]
    GlobalStatMach --> StatMach0[StatMach0]
    GlobalStatMach --> StatMach1[StatMach1]
    
    StatMach0 --> TxPack0_0[TxPack0
Next
DataPtr]
    StatMach0 --> TxPackN_0[TxPackN
Next
DataPtr]
    StatMach0 --> RxPack0_0[RxPack0
Next
DataPtr]
    StatMach0 --> RxPackN_0[RxPackN
Next
DataPtr]
    
    TxPack0_0 --> TXBuf0_0[TX buffer]
    TxPackN_0 --> TXBufN_0[TX buffer]
    RxPack0_0 --> RXBuf0_0[RX buffer]
    RxPackN_0 --> RXBufN_0[RX buffer]
    
    StatMach1 --> TxPack0_1[TxPack0
Next
DataPtr]
    StatMach1 --> TxPackN_1[TxPackN
Next
DataPtr]
    StatMach1 --> RxPack0_1[RxPack0
Next
DataPtr]
    StatMach1 --> RxPackN_1[RxPackN
Next
DataPtr]
    
    TxPack0_1 --> TXBuf0_1[TX buffer]
    TxPackN_1 --> TXBufN_1[TX buffer]
    RxPack0_1 --> RXBuf0_1[RX buffer]
    RxPackN_1 --> RXBufN_1[RX buffer]
  

23.7.1 GlobalStatMach RAM table

The GlobalStatMach location is frozen by the hardware. This address is 0x200000C0. The GlobalStatMach is unique and mainly contains static information/options.

Table 197. GlobalStatMach

Table 198. GlobalStatMach.WORD0 register description

Table 204. GlobalStatMach.WORD6 register description

23.7.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 locations are frozen by the hardware as they follow the GlobalStatMach. The formula for a StatMach base address is:

Table 205. StatMach

Table 215. StatMach.WORD9 register description

23.7.2.1 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.8 V minimum for 6 dBm

For 8 dBm, refer to the note after the table as this PaPower requests a specific configuration.

Table 226. 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.85 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.

23.7.3 TxRxPack RAM table

The firmware has to guarantee that the transmission/reception link list is never empty or at least it must point to itself.

Table 227. TxRxPack

Table 228. TxRxPack.WORD0 register description

Table 232. TxRxPack.WORD4 register description

A similar feature allows using the existing slow clock timer to generate a CPU wakeup source. This feature when activated has no impact on the Bluetooth LE transfers (no trigger event generated to the Bluetooth LE sequencer).

In this case, the CPU wakeup process occurs in two steps:

• • ABSOLUTE_TIME[31:4] = CM0_WAKEUP_TIME [31:4] - Wakeup.WAKEUP_OFFSET[7:0]
• • The wakeup block raises a SoC wakeup request towards the Power Controller of the SoC to request voltage/clock restoring
• • ABSOLUTE_TIME[31:4] = CM0_WAKEUP_TIME [31:4]
• • If WAKEUP_CM0_IRQ_ENABLE.WAKEUP_IT = 1 , the wakeup block sends an interrupt towards the CPU ( irq_wakeup_cpu line)

23.8 Wakeup block

The wakeup block is partially located in the always-on power domain to stay supplied even in the low power modes of the device. All features not mandatory during low power modes are located in the 1V2 switchable power domain to limit power consumption.

The wakeup block combines in fact two features:

• • wakeup / sleep requests management
• • absolute and interpolated time computation.

The wakeup block computes two kinds of time: the absolute time and the interpolated time.

23.8.1 Absolute time

This timer is located in the always-on power domain and is based on a rollover free running counter. The absolute time is computed by a 28-bit counter clocked on the slow clock (around 32 kHz).

This absolute time:

• • is used by the Bluetooth LE controller and by the CPU to trigger a wakeup. When the current absolute time reaches the wakeup time programmed, then a wakeup signal is generated either for the controller or for the CPU
• • is provided to the time interpolator block to build the 28-bit MSB non-interpolated part of the 32-bit interpolated time.

23.8.2 Interpolated time

The interpolated time is located in the 1.2 V switchable power domain and is clocked at 16 x slow clock frequency (generated from the system clock). This interpolated time is a 32-bit timer built with:

• • 28-bit MSB part corresponding to the non-interpolated time clocked at 32 kHz (absolute time)
• • 4-bit LSB corresponding to the fractional part (interpolation at 512 kHz).

The interpolated time is provided to the Bluetooth LE controller to get current time information and to manage the timer1.

The 512 kHz interpolation part (4-LSB) is generated using both the 32 kHz and the system clock using a 16 MHz base whatever the system clock frequency is.

23.8.3 Sleep request and wakeup management

The wakeup block offers the interface to issue the sleep request to the power controller from Bluetooth LE controller and it raises wakeup requests for the SoC and the Bluetooth LE controller.

The sleep request, coming from Bluetooth LE controller, can be performed through a wakeup block register.

If the wakeup is enabled, two separate IRQs are asserted in order to:

• • indicate to the CPU that the Bluetooth LE controller receives a wakeup request from the wakeup block. The wakeup request source is the wakeup timer.
• • indicate that the CPU wakeup timer reaches the programmed value to trigger an interrupt towards the CPU.

On wakeup, due to a sequencer activity, the wakeup block:

• • manages the SoC wakeup event generation (to restart the power and clock systems)
• • manages the Bluetooth LE wakeup event (supposed to be done once the power and clocks are ready).

In this case, no IRQ is asserted for signaling the SoC wakeup event.

The principle is to wake up the SoC before waking up the Bluetooth LE to allow time to power and clock to settle. This is possible by programming two pieces of information in the wakeup block:

• • Bluetooth LE wakeup event time:
• • Absolute time information to be filled in the Wakeup.BLUE_WAKEUP_TIME[31:0] APB register.
  • – This value is in 16 x slow clock periods time units (typically 512 kHz)
• • SoC wakeup event time:
  • – A wakeup offset information must be filled in the Wakeup.WAKEUP_OFFSET register.
  • – This value is in slow clock period time units (typically 32 kHz)

Both SoC and Bluetooth LE wakeup events generated by the wakeup block are only based on the 32 kHz. Then the wakeup block raises:

• • a wakeup request for the power controller for voltage/clock restoring when the absolute time reaches the programmed values minus the wakeup offset (anticipated wakeup to settle clock and power before Bluetooth LE starts). Then, when absolute_time[31:4] is equal to Wakeup.BLUE_WAKEUP_TIME[31:4] minus Wakeup.WAKEUP_OFFSET[7:0]
• • a wakeup request for the Bluetooth LE controller when the absolute_time[31:4] matches the 28 MSB of the programmed value.

A similar feature allows using the existing slow clock timer to generate a CPU wakeup source. This feature, when activated, has no impact on the Bluetooth LE transfers (no trigger event generated to the Bluetooth LE sequencer).

In this case, the CPU wakeup process occurs in two steps:

• • At ABSOLUTE_TIME[31:4] = CM0_WAKEUP_TIME [31:4] - Wakeup.WAKEUP_OFFSET[7:0]
  The wakeup block raises an SoC wakeup request towards the Power Controller of the SoC to request voltage/clock restoring.
• • At ABSOLUTE_TIME[31:4] = CM0_WAKEUP_TIME [31:4]
  If WAKEUP_CM0_IRQ_ENABLE.WAKEUP_IT = 1 , the wakeup block sends an interrupt towards the CPU ( irq_wakeup_cpu line).

23.8.4 Wakeup block registers

Table 244. WAKEUP_BLE_IRQ_ENABLE register description

Table 245. WAKEUP_BLE_IRQ_STATUS register description

Table 246. WAKEUP_CM0_IRQ_ENABLE register description

Table 247. WAKEUP_CM0_IRQ_STATUS register description