SWCU194 March 2023 CC1314R10 , CC1354P10 , CC1354R10 , CC2674P10 , CC2674R10
At the start of an advertiser operation of any kind, the radio CPU waits for the start trigger, then programs the frequency based on the channel parameter of the command structure. The channel parameter is not allowed to be in the range of 0–36, because these are data channels. The radio CPU sets up the advertising channel access address and uses the CRC initialization value of 0x555555. The whitener is set up as defined in the whitening parameter. The radio CPU then configures the transmitter. Except for an advertiser that is not connectable, the operation goes on with reception after transmission, and if a SCAN_REQ is received, another transmission of a SCAN_RSP may occur.
In Bluetooth® Low Energy mode, advertising is usually done over all three advertising channels. To set this up, three command structures can be chained using the pNextOp parameter. Typically, the parameter and output structures can be the same for all channels.
The first packet transmitted is always an ADV*_IND packet. This packet consists of a header, an advertiser address, and advertising data (except for the ADV_DIRECT_IND packet that is used in directed advertising). The radio CPU constructs these packets as follows (the ADV_DIRECT_IND packet is described in Section 26.8.8.2).
Command | Type of Advertising Packet | Value of PDU Type Bits in Header |
---|---|---|
CMD_BLE_ADV | ADV_IND | 0000b |
CMD_BLE_ADV_DIR | ADV_DIRECT_IND | 0001b |
CMD_BLE_ADV_NC | ADV_NONCONN_IND | 0010b |
CMD_BLE_ADV_SCAN | ADV_SCAN_IND | 0110b |
Except for the non-connectable advertiser, the receiver shall be started after the ADV*_IND packet is transmitted. Depending on the type of advertiser operation, the receiver shall listen for a SCAN_REQ and (or) a CONNECT_IND (known as CONNECT_REQ in Bluetooth® 4.0, 4.1, and 4.2 Specifications listed in Related Documentation). If the demodulator obtains sync, the header shall be checked when it is received, and if it is not a SCAN_REQ or CONNECT_IND message, the demodulator shall be stopped immediately.
A SCAN_REQ or CONNECT_IND message is received into the RX queue given by pParams->pRxQ, as described in Section 26.10.4.1. The bCrcErr and bIgnore bits are set according to the CRC result and the received message. The AdvA field in the message and the TxAdd bit of the received header are compared to the pParams->pDeviceAddress array and pParams->advConfig.deviceAddrType, respectively, to see if the message was addressed to this advertiser. Then, depending on the advertising filter policy that is given by pParams->advConfig.advFilterPolicy, the received ScanA or InitA field, along with the RxAdd bit of the received header, is checked against the whitelist (see Section 26.8.14), except for a directed advertiser, where the received header is compared against the peer address (see Section 26.8.8.2). If the resolvable private address (RPA) mode (given by pParams->advConfig.rpaMode) is nonzero, an extra check is done to see if the peer address is a resolvable private address. If the received TxAdd is 1 and the two most significant bits of the received ScanA or InitA field are 01b, the address is a RPA. If so, a whitelist check is performed regardless of the filter policy. Depending on the received packet, the actions taken shall be as given in Table 26-131, where the definition of each action (including the value that will be used on bCrcErr and bIgnore) is given in Table 26-132. If pParams->advConfig.bStrictLenFilter is 1, only length fields that are compliant with the Bluetooth® Low Energy specification shall be considered valid. For a SCAN_REQ, that means a length field of 12, and for a CONNECT_IND it means a length field of 34. If pParams->advConfig.bStrictLenFilter is 0, all received packets with a length field less than or equal to the maximum length of an advertiser packet shall be considered valid. If the length is not valid, the receiver shall be stopped.
PDU Type | CRC Result | Adv. Type | Valid Length | AdvA Matches Own Address | Filter Policy | RPA Mode | Resolvable Private Address | ScanA or InitA Present in Whitelist | Action No. |
---|---|---|---|---|---|---|---|---|---|
SCAN_REQ | OK | C, S | Yes | No | X | X | X | X | 1 |
SCAN_REQ | OK | C, S | Yes | Yes | 1 or 3 | X | X | No | 1 |
SCAN_REQ | OK | C, S | Yes | Yes | 1 or 3 | X | X | Yes | 2 |
SCAN_REQ | OK | C, S | Yes | Yes | 0 or 2 | 0 | X | X | 2 |
SCAN_REQ | OK | C, S | Yes | Yes | 0 or 2 | 1 | No | X | 2 |
SCAN_REQ | OK | C, S | Yes | Yes | 0 or 2 | 1 | Yes | No | 1 |
SCAN_REQ | OK | C, S | Yes | Yes | 0 or 2 | 1 | Yes | Yes | 2 |
SCAN_REQ | NOK | C, S | Yes | X | X | X | X | X | 3 |
SCAN_REQ | X | C, S | No | X | X | X | X | X | 5 |
SCAN_REQ | X | D | X | X | X | X | X | X | 5 |
CONNECT_IND | OK | C, D | Yes | No | X | X | X | X | 1 |
CONNECT_IND | OK | C, D | Yes | Yes | 2 or 3 | X | X | No | 1 |
CONNECT_IND | OK | C, D | Yes | Yes | 2 or 3 | X | X | Yes | 4 |
CONNECT_IND | OK | C, D | Yes | Yes | 0 or 1 | 0 | X | X | 4 |
CONNECT_IND | OK | C, D | Yes | Yes | 0 or 1 | 1 | No | X | 4 |
CONNECT_IND | OK | C, D | Yes | Yes | 0 or 1 | 1 | Yes | No | 1 |
CONNECT_IND | OK | C, D | Yes | Yes | 0 or 1 | 1 | Yes | Yes | 4 |
CONNECT_IND | NOK | C, D | Yes | X | X | X | X | X | 3 |
CONNECT_IND | X | C, D | No | X | X | X | X | X | 5 |
CONNECT_IND | X | S | X | X | X | X | X | X | 5 |
Other | X | X | X | N/A | X | X | N/A | N/A | 5 |
No packet received | N/A | X | N/A | N/A | X | X | N/A | N/A | 5 |
Action No. | bCrcErr | bIgnore | Description |
---|---|---|---|
1 | 0 | 1 | End operation with BLE_DONE_OK status |
2 | 0 | 0 | Transmit SCAN_RSP message |
3 | 1 | 0 | End operation with BLE_DONE_RXERR status |
4 | 0 | 0 | End operation with BLE_DONE_CONNECT or BLE_DONE_CONNECT_CHSEL0 status |
5 | — | — | Stop receiver immediately and end operation with BLE_DONE_NOSYNC status |
If a SCAN_REQ packet is received with a length of 12 (or less), it shall be viewed as an empty packet. This means that if pParams->rxConfig.bAutoflushEmpty is 1 and bCrcErr and bIgnore are both 0, the packet is removed from the RX buffer. If a packet is flagged by bIgnore or bCrcErr, it may also be removed based on the bits in pParams->rxConfig.
If the packet being received did not fit in the RX queue, the packet is received to the end, but the received bytes are not stored. If the packet would normally not have been discarded from the RX queue based on the bits in pParams->rxConfig, the command shall end.
If a CONNECT_IND packet is correctly received (see Action 4 in Table 26-132) and pParams->advConfig.chSel is 1, the ChSel bit of the received header is checked. If this bit is 0 (meaning that the peer does not support Channel Selection Algorithm 2), the status is set to BLE_DONE_CONNECT_CHSEL0 instead of to BLE_DONE_CONNECT.
If the next action (according to Table 26-131 and Table 26-132) is to transmit a SCAN_RSP packet, the radio CPU shall start the transmitter to transmit this packet. This packet consists of a header, an advertiser address, and advertising data.
The radio CPU shall construct these packets as follows:
A trigger to end the operation is set up by pParams->endTrigger. If the trigger that is defined by this parameter occurs, the radio operation shall continue to completion, but the status code after ending shall be BLE_DONE_ENDED and the result shall be FALSE. This trigger can be used to stop execution instead of proceeding with the next chained operation by use of the condition in the command structure. If the immediate command CMD_STOP is received by the radio CPU, it shall have the same meaning as when the end trigger occurs (except that the status code after ending shall be CMD_DONE_STOPPED).
The output structure pOutput contains fields that give information on the command being run. The radio CPU shall not initialize the fields, so this must be done by the system CPU when a reset of the counters is desired. The fields shall be updated by the radio CPU as described in the following list. The list also indicates when interrupts shall be raised in the system CPU.