SWCU192 November 2021 CC1312R7 , CC1352P7 , CC2652P7 , CC2652R7
Extended advertising packets on secondary channel (AUX_ADV_IND and AUX_CHAIN_IND), are accepted if running CMD_BLE5_SCANNER on a secondary advertising channel, or if following an AuxPtr.
The bCrcErr and bIgnore bits are set according to the CRC result and the received message. Depending on the scanning filter policy, given by pParams->scanConfig.scanFilterPolicy, the received AdvA field in the message, along with the TxAdd bit of the received header is checked against whitelist as described in Section 26.8.14. If the resolvable private address (RPA) mode, given by pParams->scanConfig.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 AdvA field are 01b, the address is an RPA. If so, a whitelist check is performed regardless of the filter policy. The complete check on AdvA is performed as listed in Table 26-154; however, entries with the bWlIgn bit set in the whitelist are only considered if no ADI field is present in the extended header and pParams->extFilterConfig.bApplyDuplicateFiltering is 1. The ADI result is found as described in Section 26.8.10.4. If the extended header flags indicate that TargetA is present (that is, the packet is directed), the received TargetA field and RxAdd bit are checked against pParams->pDeviceAddress and pParams->scanConfig.deviceAddrType, respectively (see also Section 26.8.17). If the RPA filter policy, given by pParams->scanConfig.rpaFilterPolicy, is 1, a packet is also accepted if TargetA and RxAdd indicate an RPA. The full filtering of directed messages is given in Table 26-145. Nondirected messages always have TargetA match. Depending on the received packet, and whether the scan is active or passive, signaled in pParams->scanConfig.bActiveScan, the actions taken shall be as given in Table 26-151, where the definition of each action, including the value that will be used on bCrcErr and bIgnore, is given in Table 26-152. The packet length of a received AUX_ADV_IND or AUX_CHAIN_IND packet is always valid by default, but it is possible to configure a maximum length by overriding the firmware defined parameter maxAdvExtLen. In addition, the extended header length and flags are checked. If the extended header length is too large for the extended header to fit in the packet, or if it is too small to hold the configured, the length is invalid. If pParams->scanConfig.bStrictLenFilter is 1, all defined fields are considered, while if pParams->scanConfig.bStrictLenFilter is 0, the fields that are not automatically checked by the CPE (SyncInfo and TxPower) are ignored when finding the minimum allowed extended header length.
| PDU Type | AdvMode | CRC Result | AdvA Filter Result | TargetA Match | ADI Result | AuxPtr Present | Active Scan | Action No. |
|---|---|---|---|---|---|---|---|---|
| AUX_ADV_IND | X | OK | Reject | X | X | X | X | 1 |
| AUX_ADV_IND | X | OK | Accept | No | X | X | X | 1 |
| AUX_ADV_IND | X | OK | Accept | Yes | Reject | X | X | 1 |
| AUX_ADV_IND | 00 | OK | Accept | Yes | Accept | No | X | 2 |
| AUX_ADV_IND | 00 | OK | Accept | Yes | Accept | Yes | X | 6 |
| AUX_ADV_IND | 01, 11 | OK | Accept | Yes | Accept | X | X | 2 |
| AUX_ADV_IND | 10 | OK | Accept | Yes | Accept | X | No | 2 |
| AUX_ADV_IND | 10 | OK | Accept | Yes | Accept | X | Yes | 3 |
| AUX_ADV_IND | X | NOK | X | X | X | X | X | 4 |
| AUX_ADV_IND with invalid length | X | X | X | X | X | X | X | 5 |
| Other | X | X | X | X | X | X | X | 5 |
| Action No. | bCrcErr | bIgnore | Description |
|---|---|---|---|
| 1 | 0 | 1 | End operation with BLE_DONE_RXERR status |
| 2 | 0 | 0 | End operation with BLE_DONE_OK status |
| 3 | 0 | 0 | Perform backoff procedure and send AUX_SCAN_REQ and receive AUX_SCAN_RSP if applicable. Then end operation |
| 4 | 1 | 0 | End operation with BLE_DONE_RXERR status |
| 5 | — | — | Stop receiving packet, then continue scanning |
| 6 | 0 | 0 | Follow Aux pointer and receive on the new channel, or end operation with BLE_DONE_AUX |
If the packet being received did not fit in the RX queue, the packet shall be received to the end, but the received bytes are not stored. If the packet would normally not have been discarded from the RX buffer, the operation shall end.
If the action from the received packet is 3, an AUX_SCAN_REQ is to be transmitted if allowed after a backoff procedure. This procedure starts with decrementing pParams->backoffCount. If this variable becomes 0 after the decrement, an AUX_SCAN_REQ shall be transmitted. If not, the operation shall end.
When transmitting an AUX_SCAN_REQ, the radio CPU shall construct this packet. In the header, the PDU Type bits shall be 0011b. The TxAdd bit shall be as in pParams->scanConfig.deviceAddrType (if the least significant bit of pParams->pDeviceAddress is 1, the TxAdd bit is inverted, see Section 26.8.17). The RxAdd bit shall be as in the TxAdd field of the header of the received AUX_ADV_IND message. The length shall be 12. The ChSel and RFU bits shall be 0. The payload shall start with the 6-byte device address, which shall be read from pParams->pDeviceAddress, followed by the 6-byte peer address read from the AdvA field of the received message.
After an AUX_SCAN_REQ message is transmitted, the radio CPU shall configure receiver and look for an AUX_SCAN_RSP. The packet will be received using the rules from Table 26-151, except that action 3 is not performed, and action 2 is performed instead, and action 5 in this case is end operation with BLE_DONE_NOSYNC status. This means that a packet may be accepted even if it has a different AdvA than the first AUX_ADV_IND packet. To correct this issue, a check could be made in the system CPU, or a patch could be considered.
After receiving or attempting to receive an AUX_SCAN_RSP, the backoff parameters shall be updated by the radio CPU, based on the result as given in the Response Packet Result column of Table 26-148 and the old values of the backoff parameters.
If the action from the received packet is 6, the radio CPU shall follow the procedure in Section 26.8.16. This will either cause the receiver to look for a secondary advertising packet as described in this section or to end the operation with status BLE_DONE_AUX.