Baseband Controller Interface

Baseband Controller Clock

The BB controller master clock is a scaled-down version of the system clock, configured through the CLK_DIV_CFG0_BBCLK_PRESCALE field of the CLK_DIV_CFG0 register, and must fulfill these requirements:

  • The ratio between the system clock and the BB controller master clock frequencies must be an integer.
  • The BB controller master clock frequency must be an integer multiple of 1 MHz, from 6 MHz up to 16 MHz.

The internal baseband controller clock divider must be set according to the BB controller master clock frequency, to generate a 1 MHz reference clock. It can be configured in the BBIF_CTRL_CLK_SEL field of the BBIF_CTRL register with an integer value from 6 up to 24.

The CLK_ENABLE bit controls the external gating of the different baseband controller clocks. If the baseband controller is not used, we recommend that you disable the clocks and power down the baseband controller via the SYSCTRL_RF_POWER_CFG register. We also recommend that you power up the baseband controller using the following sequence:

/* Enable BB power switches */

SYSCTRL->RF_POWER_CFG |= BB_POWER_STARTUP;

SYSCTRL->RF_POWER_CFG |= BB_POWER_ENABLE;

/* Remove BB isolation */

SYSCTRL->RF_ACCESS_CFG |= BB_ACCESS_ENABLE;

/* Enable BB clocks */

BBIF->CTRL = BB_CLK_ENABLE;

NOTE: By default, the Bluetooth Low Energy initialization function (BLE_Initialize) assumes that the application has enabled the BB controller master clocks and provides a master clock of 8 MHz. Although configuring 16 MHz works, full functionality is not guaranteed, and this setting is not recommended.

WLAN Coexistence

RSL15 can be collocated with another 2.4 GHz radio technology such as another Bluetooth device or WiFi chip; this is referred to as WLAN coexistence. For example, they might share the same antenna, but the electromagnetic interference might impact the performance and/or functionality of both systems. The coexistence functionality can be used when, for example, an external amplifier is required, where it needs to be activated before a TX activity. For this purpose the BB controller can provide some signals to an external device indicating its radio (Bluetooth Low Energy) activity, and it can accept the other device’s indication as an input signal that is called a WLAN signal. The BB controller includes the following provisions for Coexistence with WLAN devices:

  • Ability to report real time Bluetooth Low Energy TX and RX activity to a collocated WLAN device
  • Ability to abort Bluetooth Low Energy TX and/or RX activity when real time WLAN RX activity is reported
  • Ability to abort Bluetooth Low Energy TX and/or RX activity when real time WLAN TX activity is reported
  • A Bluetooth Low Energy real time synchronization signal

As output signals, the following signals can be routed through any configured GPIO to report Bluetooth Low Energy activities through configuring the GPIO_CFG* registers:

  • WLAN coex sync signal that is generated synchronously with internal 625 μs timing reference
  • WLAN coex in-process signal that is raised when any TX or RX is ongoing
  • WLAN coex TX signal that is generated when a TX activity is happening
  • WLAN coex RX signal that is generated during any RX activity
  • WLAN coex PTI signal (4 bits) that indicates the priority value of the ongoing activity

The Bluetooth Low Energy activity signals (ble_rx and ble_tx) can be generated before the actual time when are scheduled for, by a maximum of 16 μs in advance. This is done through the BB_COEXIFCNTL2_RX_ANT_DELAY and BB_COEXIFCNTL2_TX_ANT_DELAY fields of the BB_COEXIFCNTL2 register. By default, this time is set to zero.

A Bluetooth Low Energy activity (RF activity) can be aborted if the relevant external WLAN signal is set (providing it is routed through a GPIO), or when the software sets the BBIF_COEX_CTRL_TX or BBIF_COEX_CTRL_RX field of the BBIF_COEX_CTRL register. The abort mechanism can be enabled or disabled through the BB_COEXIFCNTL0_WLANTXMSK and BB_COEXIFCNTL0_WLANRXMSK fields of the BB_COEXIFCNTL0 register.

As input, WLAN TX and WLAN RX external activities can be routed from any GPIO to baseband controller input signals wlan_tx and wlan_rx. Do this by configuring the desired GPIO as input and selecting accordingly via the GPIO_SRC_BB_COEX register. (See General Purpose Input/Outputfor more information.)

The "WLAN Coexistence Timing when WLC<TX/RX>PRIOMODE = “00”" figure and the "WLAN Coexistence Timing when WLC<TX/RX>PRIOMODE = “01”" figure show two WLAN coexistence interface timing diagrams, including TX/RX power-up delay for two modes, when the BB_COEXIFCNTL0_WLCRXPRIOMODE and BB_COEXIFCNTL0_WLCTXPRIOMODE fields in the BB_COEXIFCNTL0 register are set to 0 or 1 to include or exclude TX and RX power-up delays (see Section 1.0.1 “BB_COEXIFCNTL0” on page 1 for field descriptions):

Figure: WLAN Coexistence Timing when WLC<TX/RX>PRIOMODE = “00”

Figure: WLAN Coexistence Timing when WLC<TX/RX>PRIOMODE = “01”

The status of Bluetooth Low Energy activities can be read at any time through register BBIF_STATUS. The BBIF_STATUS_CLK_STATUS field in this register is low when it is in Active Clock Mode, and is high when it switches to the Low Power Clock Mode that is called Bluetooth Low Energy Deep Sleep Mode. The BBIF_STATUS_LINK_FORMAT field in this register indicates the type of activity that is ongoing The BBIF_STATUS_LINK_LABEL field shows the Bluetooth Low Energy activity index, which the application is informed of through GAP APIs when an activity is created. The BBIF_STATUS_LINK_FORMAT values are as listed below (in the binary format found in the field):

  • 00010: Master Connect
  • 00011: Slave Connect
  • 00100: Low Duty Cycle Advertiser
  • 00101: High Duty Cycle Advertiser
  • 00110: Extended Advertiser
  • 01000: Passive Scanner
  • 01001: Active Scanner
  • 01010: Extended Passive Scanner
  • 01011: Extended Active Scanner
  • 01110: Initiator
  • 01111: Extended Initiator
  • 11100: TX Test Mode
  • 11101: RX Test Mode
  • 11110: TX/RX Test Mode

The status of Bluetooth Low Energy coexistence signals can be read through register BBIF_COEX_STATUS.

In addition, BBIF allows coexistence signals to generate a desired interrupt when any TX or RX activity starts or finishes. The desired interrupt is enabled by setting the fields of register BBIF_COEX_INT_CFG.

Interrupts can be configured for either rising edge or falling edge, or any edge of the BBIF_COEX_STATUS_BLE_TX and BBIF_COEX_STATUS_BLE_RX signals. The signal bit BBIF_COEX_STATUS_BLE_IN_PROCESS in the BBIF_COEX_STATUS register is set when any of radio bits BBIF_COEX_STATUS_BLE_RX or BBIF_COEX_STATUS_BLE_TX are set. The signal bit goes back to low when the radio activities finish.

The BBIF_COEX_STATUS_EVENT_IN_PROCESS signal is raised when the baseband controller schedules an event, not when radio activity (including TX, RX, and IFS) is ongoing, and it is different with BBIF_COEX_STATUS_BLE_IN_PROCESS. The BBIF_COEX_STATUS_EVENT_IN_PROCESS signal is shown in the "WLAN Coexistence Timing when WLC<TX/RX>PRIOMODE = “00”" figure and the "WLAN Coexistence Timing when WLC<TX/RX>PRIOMODE = “01”" figure.

BB Controller Interrupts

The baseband controller interrupt generator creates the following interrupts:

  • BLE_ERROR_IRQ: Error interrupt, generated when undesired behavior or bad programming occurs in the Bluetooth Low Energy Core. Error status is reported in the BB_ERRORTYPESTAT register.
  • BLE_HSLOT_IRQ: 312.5 μs half slot interrupt, available in active mode. This interrupt can be partially masked using sub-rating patterns.
  • BLE_SLP_IRQ: End of Sleep Mode interrupt
  • BLE_CRYPT_IRQ: Encryption engine interrupt, generated when SW-driven AES-128 ciphering/deciphering process is finished
  • BLE_FINETGT_IRQ: Fine Target Timer interrupt generated when Fine Target timer expires. Timer resolution is 312.5 μs.
  • BLE_TIMESTAP_TGT1 and BLE_TIMESTAP_TGT2: Time Stamp Target interrupts generated when reaching a desired CLKN and fine counter value. Instant precision of 0.5 μs.
  • BLE_SW_IRQ: SW triggered interrupt generated on SW request through register access (the BB_BLECNTL_SWINT_REQ of the BB_BLECNTL register)
  • BLE_FIFO_IRQ: Activity FIFO interrupt, generated each time any of the following internal events is generated:
    • Start of events internal interrupt. Generated on any event starting instant.
    • End of events internal interrupt. Generated on normal termination, or on anticipated pre-fetch mechanism request.
    • Skipping of events internal interrupt. Generated when an event is not processed for priority management reasons.
    • End of transmitted and acknowledged packet, or when number of transmitted packets equals a threshold set by the Bluetooth Low Energy stack
    • End of received packets, or when number of received packets equals a threshold set by the Bluetooth Low Energy stack

Interrupts can be masked using the BB_INTCNTL* registers. Each interrupt status is provided in the BB_INTSTAT* registers. Interrupts are acknowledged by writing to the corresponding BB_INTACK* registers. Each interrupt has its own output to the Arm Cortex-M33 processor interrupt controller.

The BB_ACTFIFOSTAT register provides internal details about real-time Bluetooth Low Energy event operations. These details are stored in the FIFO IRQ, including separated fields for skipped events and the current event exchange table entry index.

The FIFO has an interrupt depth of 16, and generates an interrupt each time it is loaded by any internal interrupt while empty. FIFO interrupt status is kept high until all the entries are read by the Bluetooth Low Energy software. Accessing the next element of the FIFO is performed by acknowledging the FIFO interrupt. The basic procedure to read the FIFO IRQ is the following:

  1. Bluetooth Low Energy software waits for a BLE_FIFO_IRQ to be generated.
  2. BLE_FIFO_IRQ is generated, and Bluetooth Low Energy software enters its FIFO interrupt management routine.
  3. Bluetooth Low Energy software reads the value in the BB_ACTFIFOSTAT register, and processes the reported pending interrupt(s).
  4. Bluetooth Low Energy software acknowledges the FIFO interrupt, asking the FIFO interrupt to provide next elements (if any).
  5. Bluetooth Low Energy software reads the BB_INTSTAT1_FIFOINTSTAT field of the BB_INTSTAT1 register to determine whether FIFO is empty.
  6. If the FIFO is not empty, loop to step 3.
  7. If the FIFO is empty, loop to step 1.

When the Bluetooth Low Energy software stack is used, it handles all Bluetooth Low Energy interrupts, and interrupt software routines are not exposed to the application.

Baseband Counters and Timers

The BB controller can be put in two modes:

  • Active Mode
  • Low Power Mode (Bluetooth Low Energy Sleep Mode)

Active Mode

In Active Mode, which is the normal mode in which Bluetooth Low Energy events are processed, there are some counters and timers that are used by the Bluetooth Low Energy software stack. Counters are also available to the applications, though timers are not. If an application does not use the Bluetooth Low Energy stack, the application can use these counters as general purpose timers. There are three of these counters, as follows:

  • CLKN: A 28-bit counter with a 312.5 μs precision, which wraps after approximately 23.3 hours
  • FINECNT: A 10-bit fine counter with 0.5 us precision, which wraps every 625 increments to zero, meaning that it counts up to 624 μs
  • BB low power clock timer: A 32-bit wakeup counter that counts the number of low power clk clock cycles (used only in Low Power Mode)

The CLKN and FINECNT counters are clocked synchronously.

The values of the BB_SLOTCLK and FINETIMECNT counters can be read at any time by the software or the Bluetooth Low Energy stack, using the following mechanism:

  • Set the field BB_SLOTCLK_SAMP field of the BB_SLOTCLK register to get the current samples of counters.
  • Wait until this field is reset, then read the saved sample of the counters from the BB_CLKN_SCLK field of the BB_CLKN register (28 bits) and the BB_FINETIMECNT_FINECNT field of the BB_FINETIMECNT register (10 bits).

We recommend that you disable interrupts before reading the values of counters, and enable the interrupts again once the counters have been read. These counters can be used in combination by software at any time, as a general real-time timer.

In the Bluetooth Low Energy stack, these counters are used by hardware to capture the times at which any activity or event has occurred in shared memory, so that later the Bluetooth Low Energy stack can read them and find out the real-time value associated with any event or packet.

There are three timers that can generate interrupts when they are configured to be used by software for a desired period of time. When the Bluetooth Low Energy stack is used, these timers are not available to applications, as the Bluetooth Low Energy stack uses them for its own internal protocol timers and kernel timer. They are:

  • Fine Timer Target: A 28-bit timer with 312.5 μs precision
  • Timestatmp Target 1: with 0.5 μs precision
  • Timestamp Target 2: with 0.5 μs precision

These timers can be configured by setting the desired target values and enabling the appropriate interrupt bit in the BB_INTCNTL0 register.

Refer to Baseband Controller Registers for descriptions of these registers/fields:

  • The BB_FINETIMTGT_BB_FINETARGET field of the BB_FINETIMTGT register
  • The BB_HMICROSECTGT1_HMICROSECTGT1 field of the BB_HMICROSECTGT1 register
  • The BB_CLKNTGT1_CLKNTGT1 field of the BB_CLKNTGT1 register
  • The BB_HMICROSECTGT2_HMICROSECTGT2 field of the BB_HMICROSECTGT2 register
  • The BB_CLKNTGT2_CLKNTGT2 field of the BB_CLKNTGT2 register

These timers use the counters and target value registers to generate interrupts when the counters reach the configured target values.

The Bluetooth Low Energy software stack configures Timestamp Target2 with resolution 1 ms for kernel timer purposes when required, which means that the kernel timer has a resolution of 1 ms.

Low Power Mode

In RSL15, when the Bluetooth Low Energy controller is put in Low Power Mode (Deep Sleep Mode), the low power timer counts the number of low power clock cycles when all clocks are disabled and/or the BB controller is powered off. This wakes up the BB controller at the right time, so that it can continue processing the scheduled activities programmed by the Bluetooth Low Energy software stack. The low power timer is sourced from an RTC clock that can be any one of the following options:

  • Crystal 32768 Hz (XTAL 32K)
  • RC 32 kHz oscillator
  • One of GPIOs 0 to 3

By default, the timings for sleep duration are calculated assuming a 32768 low power clock frequency. However, any desired frequency (for example, between 10 and 100 kHz) can be provided externally through GPIOs. Therefore, the Bluetooth Low Energy stack needs to be informed of the frequency for its own calculations. This takes place through the API LPCLK_PeriodValue_Set(average_period) where an application has to call it, at least in PARAM_ID_LPCLK_NO_XTAL32K in the function uint8_t Device_BLE_Param_Get(uint8_t param_id, uint8_t *lengthPtr, uint8_t *buf). The value of the average_period argument needs to be provided in the application. For example, the code below shows how a 40 kHz clock can be used as the source of the low power clock:

...

#define LPCLK_PERIOD_VALUE (float)(1000000.0 / 40000)

case PARAM_ID_LPCLK_NO_XTAL32K:

buf[0] = true;

LPCLK_PeriodValue_Set(LPCLK_PERIOD_VALUE);

break;

...

The accuracy of the low power clock must be better than 500 ppm to be able to keep the Bluetooth Low Energy connection stable, to send periodic advertisements, or to synchronize with a peer device’s periodic advertisements. However, a mechanism has been implemented that allows acceptance of any desired clock accuracy through PARAM_ID_LPCLK_DRIFT in the Device_BLE_Param_Get() function. When low power clock accuracy varies (for example, because of fast temperature changes for the 32 kHz crystal oscillator), this mechanism allows the application to provide greater than 500 ppm accuracy, while still maintaining the Bluetooth Low Energy link with a central device. Accepting clock accuracies higher than 500 ppm is allowed only for devices in the peripheral role, according to the Bluetooth Low Energy Core Specification.

Refer to the ble_peripheral_server_sleep sample application to see how an application can configure the clock accuracy.

To keep the baseband low power timer active when the device is in Sleep Power Mode (with VDDC retention regulator disabled), the following procedure needs to be applied:

  1. Enable the ACS_VDDRET_CTRL_VDDTRET_EN bit in the ACS_VDDRET_CTRL register to keep the baseband low power timer powered.
  2. Configure the baseband controller register BB_DEEPSLWKUP to determine the time to be spent (in low power clock cycles) before waking up the device.
  3. In the baseband controller register BB_ENBPRESET, configure these fields:
    1. BB_ENBPRESET_TWOSC, defining the time (in low power clock cycles) allowed for stabilization of the high frequency oscillator. The BB_ENBPRESET_TWOSC field controls the signal osc_en, which is internally used to wake up the ACS and bring back the system from Sleep Mode to Run Mode.
    2. BB_ENBPRESET_TWRM, defining the time (in low power clock cycles) allowed for the radio module to leave Low Power Mode. The BB_ENBPRESET_TWRM field controls the signal radio_en, which is internally used to manage the isolation of the baseband low power timer when the device is powered down. Only the baseband low power timer input signals are isolated (except the external wakeup request available through the BBIF_CTRL_WAKEUP_REQ field of the BBIF_CTRL register). The output signals remain available.
  4. Make sure that the following conditions are fulfilled:
    1. The sleep time defined in the register BB_DEEPSLWKUP is larger than the value of the BB_ENBPRESET_TWOSC field in the BB_ENBPRESET register.
    2. The BB_ENBPRESET_TWOSC value is large enough that the system has time to go back to Run Mode and be ready to catch the baseband wakeup interrupt BLE_SLP_IRQ.
    3. The BB_ENBPRESET_TWOSC value is larger than the value of the BB_ENBPRESET_TWRM field in the same register (at least two low power clock cycles), so that the system has time to go back to Run Mode before the baseband low power timer isolation is removed.
  5. Request the baseband low power timer to go into Deep Sleep Mode by setting these three bits in the BB_DEEPSLCNTL register:
    • BB_DEEPSLCNTL_DEEP_SLEEP_ON
    • BB_DEEPSLCNTL_RADIO_SLEEP_EN
    • BB_DEEPSLCNTL_OSC_SLEEP_EN
  6. Wait until the status bits BBIF_STATUS_OSC_EN and BBIF_STATUS_RADIO_EN of the BBIF_STATUS register are reset, indicating that the baseband low power timer is in Deep Sleep Mode and properly isolated.
  7. Set the system to Sleep Power Mode.

When coming back from Sleep Mode to Run Mode, we recommend that you use the following procedure:

  1. The OSC_EN signal is set by the baseband low power timer, and automatically wakes up the ACS, which brings back the system from Sleep Mode to Run Mode.
  2. The RADIO_EN signal is set by the baseband low power timer and the isolation is automatically removed.
  3. Power up the baseband controller by setting consecutively the SYSCTRL_RF_POWER_BB_STARTUP bit and, at least 2 μs later, the SYSCTRL_RF_POWER_BB_ENABLE bit, both from the SYSCTRL_RF_POWER register.
  4. Remove the baseband controller isolation by setting the SYSCTRL_RF_ACCESS_BB_ACCESS bit of the SYSCTRL_RF_ACCESS register.
  5. Enable the baseband controller clocks by setting the BBIF_CTRL_CLK_ENABLE bit of the BBIF_CTRL register.
  6. Wait for the baseband wakeup interrupt BLE_SLP_IRQ, which is generated once the baseband low power timer sleep timer has expired.

In addition to the baseband low power timer, it is possible to wake up the baseband controller by setting the BBIF_CTRL_WAKEUP_REQ bit of the BBIF_CTRL register. Since no external signal is routed to the baseband controller from a GPIO, it is the responsibility of the application (software) to control this bit, for example, when RSL15 is wakened up by an external wakeup source.

The "Active Mode to Low Power Mode Timing Diagram" figure, the "Deep Sleep Mode – Standard Termination by Baseband Low Power Timer" figure, and the "Deep Sleep Mode – Aborted by Wakeup Request" figure show the timing when the baseband controller is in Deep Sleep Mode (low power clock mode) and when it is awakened by the baseband low power timer or by an external wakeup request:

Figure: Active Mode to Low Power Mode Timing Diagram

Figure: Deep Sleep Mode – Standard Termination by Baseband Low Power Timer

Figure: Deep Sleep Mode – Aborted by Wakeup Request

An external wakeup request can be filtered when the BB_DEEPSLCNTL_EXTWKUPDSB field in the EXTWKUPDSB register is set. The wakeup request must be maintained high for at least two low power clock cycles to be taken into account correctly. Although the BB_ENBPRESET_TWOSC, BB_ENBPRESET_TWRM, and BB_ENBPRESET_TWEXT fields in the BB_ENBPRESET register can be set by the application, we suggest that the BB_ENBPRESET_TWOSC parameters only be adjusted when the Bluetooth Low Energy stack is used. After wakeup, the value of BB_ENBPRESET_TWOSC is the time that the system needs to power on the BB controller (if it is off), enable RFCLK (if it is disabled), and restore the BB controller registers and RFFE register contents (if BB and RFFE have been off during sleep). Before going to BB deep sleep, if the baseband and RFFE are powered off, the contents of their registers need to be saved in DRAM, and maintained by enabling VDDM for the appropriate DRAM instance(s). The application needs to make sure that after wakeup, the BB controller and the RFFE can resume their own activities—for example, to maintain a Bluetooth Low Energy connection.

At the end of each low power time, the time duration is written to the BB_DEEPSLSTAT_DEEPSLDUR field of the BB_DEEPSLSTAT register. Then the software must apply CLKN counter and Fine counter correction to restore the 312.5 μs CLKN reference alignment. This correction mechanism can be achieved using the BB_CLKNCNTCORR and BB_FINECNTCORR registers. This mechanism is mandatory, since the CLKN counter is running onto the master clock that is gated during Deep Sleep Mode, freezing both counters, and letting the system run onto the low power clock. The correction is achieved by updating both the 10-bit Fine counter values and the 28-bit CLKN counter value, i.e., correcting respectively the fractional part and the integer part of the phase error of the 312.5 μs reference timing event internal counter.

After termination of the Deep Sleep period, the 312.5 μs reference timing event generator has to be corrected based on the actual time spent in Low Power Mode mSleep (@T-osc) reported in the BB_DEEPSLSTAT_DEEPSLDUR field of the BB_DEEPSLSTAT register.

The integer part of the 312.5 μs reference timing, K, covers an entire CLKN Counter range (i.e. between 0 and 228-1), and has to be written in the CLKNCNTCORR register. K corresponds to the CLKN Counter correction value to apply after Deep Sleep duration, assuming that a 32 kHz clock has been used. So this formula hereafter applies.

The fractional part of the 312.5 μs reference counter, R, has to be written in the FINECNTCORR register. R covers an entire 312.5 μs Fine Counter range (i.e., between 0 and 624 with 0.5 μs precision). As the 10-bit Fine Counter is a downward counter, this R formula hereafter applies.

where the integer function provides the integer part of a number.

In any case of Deep Sleep termination, the Bluetooth Low Energy software must compensate both the CLKN counter and the FINECNT counter using (respectively) the CLKNCNTCORR and FINECNTCORR registers. Those values are calculated by the software, and applied by the BB controller as described here:

  • On Deep Sleep termination, the software reads the DEEPSLSTAT value.
  • The software determines the CLKNCNTCORR and FINECNTCORR values and stores them in the appropriate registers.
  • The software signals the correction to be applied, writing a 1 to the BB_DEEPSLCNTL_DEEP_SLEEP_CORR_EN field of the BB_DEEPSLCNTL register.

CLKN Counter and Fine Counter correction is applied when Fine Counter equals zero. CLKN Counter is corrected by applying the following formula:

Fine Counter correction is done by directly loading FINECNTCORR when Fine Counter equals zero. The "CLKN Counter Correction Mechanism" figure shows the CLKN counter correction mechanism:

Figure: CLKN Counter Correction Mechanism

The following sequence of events occur for counter correction:

  1. The software stack requires the system to go into Deep Sleep.
  2. The software stack goes into Deep Sleep Mode, and freezes CLKN Counter to T, and Fine Counter to 625-δ.
  3. When the number of low power clock cycles equals the value of BB_DEEPSLSTAT_DEEPSLDUR, or after a wakeup request, the Bluetooth Low Energy Core wakes up, and Fine Counter resumes.
  4. BLE_SLP_IRQ is generated once the master clock is enabled, and the Bluetooth Low Energy software reads the value of the BB_DEEPSLWKUP_DEEPSLTIME field in the BB_DEEPSLWKUP register and calculates the K and R values.
  5. The software stack programs CLKNCNTCORR = K and FINECNTCORR = R, and the requirements for compensation.
  6. Once Fine Counter equals zero, CLKN Counter and Fine Counter are updated.
  7. The 312.5 μs half slot timing reference is corrected and realigned.

Bluetooth Low Energy Stack Deep Sleep Mode

The functionality provided by the baseband controller is used by the Bluetooth Low Energy software stack to put itself into Sleep Mode, and allows the stack to resume its normal functionality after wakeup. This section describes how the Bluetooth Low Energy stack works for switching between Deep Sleep Mode and Active Mode, and how it interacts with a user application.

When sending the Bluetooth Low Energy stack into Sleep Mode, a user application needs to call the function (API) BLE_Baseband_Sleep(&ble_sleep_api_param). This API checks whether it is the right time for the Bluetooth Low Energy stack to go to sleep or not; if the return value is RWIP_DEEP_SLEEP, then the BB controller is already in Sleep Mode, and the BB timer has been started by the low power clock. Hence, the application does not need to configure the BB controller registers and baseband low power clock. However, the rest of system must be put into the desired power mode, such as Sleep Mode or Standby Mode.

The user application is responsible for configuring the ACS, VDDC and VDDM retention regulators, deciding whether to power off BB, RFFE, and RFCLK or not, any other step that is specified in Power Modes. From the BB controller’s point of view, it is in low power clock mode. Therefore, for cases when the BLE_Baseband_Sleep()function returns RWIP_DEEP_SLEEP, the BB_Sleep() function has been developed and provided in the RSL15 Bluetooth Low Energy sample applications for Low Power Modes as an example showing how put RSL15 into a Low Power Mode. In the BB_Sleep() function, the BB controller and RFFE registers are saved in DRAM to be restored later at wakeup time (if the BB controller and the RFFE are powered off).

The structure of ble_sleep_api_param returns the actual sleep duration that BLE_Baseband_Sleep() has programmed in register BB-DEEPSLWKUP, in the calculated_sleep_duration field of the low power clock unit (for example 1/32768 s).

These other fields are input for this function:

  • app_sleep_request set to one means it goes to sleep; if the parameter equals zero, it returns without checking or going to sleep.
  • max_sleep_duration is the maximum sleep duration that the application would like to be in sleep for, in 312.5 μs.
  • min_sleep_duration is the minimum sleep duration that the application asks for from the stack, in μs.

The sleep duration is calculated based on the next immediate Bluetooth Low Energy event or the earliest kernel timer expiry time (whichever happens sooner), minus a processing delay of approximately 500 μs. The BB low power timer expires at the amount of time equal to the BB_ENBPRESET_TWOSC value sooner than the value that is programmed in the BB timer. The "BLE_Baseband_Sleep() Function Logical Flowchart for Checking and Going to Deep Sleep" figure shows how the Bluetooth Low Energy stack checks if it is the right time to go to sleep, and then calculates the sleep duration. At the end of function BLE_Baseband_Sleep(), a flag is reset to indicate that the BB controller is in deep sleep, to be used by the application; this can be checked by calling API BLE_Baseband_Is_Awake(). If the return value of this API is false, BLE_Kernel_Process() and BLE_Baseband_Sleep() do not need to be called again.

Figure: BLE_Baseband_Sleep() Function Logical Flowchart for Checking and Going to Deep Sleep

When the BB timer expires, generating a wakeup signal for the ACS block at a time equal to the value of BB_ENBPRESET_TWOSC sooner than the programmed sleep duration, BLE_SLP_IRQ is generated. In Bluetooth Low Energy SLP ISR, a mechanism called clock compensation is enabled and waits for a BLE_HSLOT_IRQ. At BLE_SLP_IRQ, the Bluetooth Low Energy stack corrects the value of the Bluetooth Low Energy clock according to the sleep duration, and waits for a BLE_HSLOT_IRQ when the clock correction is applied by the Bluetooth Low Energy HW. It sets back the BLE_Baseband_Is_Awake flag to enable the Bluetooth Low Energy application to continue its normal Bluetooth Low Energy functionality in active mode. All clock correction and compensations are handled by the Bluetooth Low Energy stack; user applications only need to make sure that at wakeup they prepare the required RSL15 HW blocks in terms of the RFCLK, the RFFE and BB power, and enabling the BB clock If the wakeup source is not the BB timer, then the application needs to wake up the BB controller by setting the BBIF_CTRL_WAKEUP_REQ bit in the BBIF_CTRL register.

If the Bluetooth Low Energy stack is not used, the clock correction must be handled by the user application.

Bluetooth Low Energy Stack Deep Sleep Mode Registers

For tables containing the details of these registers, see BBIF_CTRL.

Baseband Controller Registers and Non-CTE Antenna Definition

Certain register fields are used to define the antenna used during the non-CTE part of the a packet.

On each TX start instant, if the TXPRIMIDCNTLEN field in the BB_DFANTRCNTL register is set, then the antenna to be used is defined by the TXPRIMANTID field in the same register.

On each RX start instant, if the RXPRIMIDCNTLEN field in the BB_DFANTRCNTL register is set, then the antenna to be used is defined by the RXPRIMANTID field in the same register.

These fields and settings in the BB_DFANTRCNTL register are used as shown in the "BB_DFANTRCNTL Fields Defining Antenna in Non-CTE Cases" table.

Table: BB_DFANTRCNTL Fields Defining Antenna in Non-CTE Cases

Field Name

Description

TXPRIMANTID[6:0]

Primary antenna ID to be used on each TX start instant

TXPRIMIDCNTLEN

Transmit Primary antenna ID enable control

RXPRIMANTID[6:0]

Primary antenna ID to be used on each RX start instant

RXPRIMIDCNTLEN

Reception Primary antenna ID enable control

The current stack configuration it is set up with the following field values in the BB_DFANTRCNTL register:

  • TXPRIMIDCNTLEN: 1
  • TXPRIMANTID: 0
  • RXPRIMIDCNTLEN: 1
  • RXPRIMANTID: 0