SWCU192 November 2021 CC1312R7 , CC1352P7 , CC2652P7 , CC2652R7
Extended advertising packets on primary channel (ADV_EXT_IND), are accepted if running CMD_BLE5_SCANNER on a primary advertising channel, prior to following an AuxPtr.
The bCrcErr and bIgnore bits are set according to the CRC result and the received message. If the extended header flags indicate that AdvA is present, 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-144; however, the rule on the bWlIgn bit set in the whitelist is only applied 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 AdvA is not present, the AdvA filter result is always Accept. 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. 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, the actions taken shall be as given in Table 26-149, where the definition of each action (including the value that will be used on bCrcErr and bIgnore) is given in Table 26-150. The packet length of a received ADV_EXT_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 | CRC Result | AdvA Filter Result | TargetA Match | ADI Result | AuxPtr Present | Action No. |
---|---|---|---|---|---|---|
ADV_EXT_IND | OK | Reject | X | X | X | 1 |
ADV_EXT_IND | OK | Accept | No | X | X | 1 |
ADV_EXT_IND | OK | Accept | Yes | Reject | X | 1 |
ADV_EXT_IND | OK | Accept | Yes | Accept | No | 2 |
ADV_EXT_IND | OK | Accept | Yes | Accept | Yes | 6 |
ADV_EXT_IND | NOK | X | X | X | X | 4 |
ADV_EXT_IND with invalid lengths | X | X | X | X | X | 5 |
Other (see also Section 26.8.10.1) | X | X | X | X | X | 5 |
Action No. | bCrcErr | bIgnore | Description |
---|---|---|---|
1 | 0 | 1 | Continue scanning |
2 | 0 | 0 | Continue scanning or end operation with BLE_DONE_OK status |
4 | 1 | 0 | Continue scanning |
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 2, the next action may either be to continue scanning or to end the operation. This is configured with pParams->scanConfig.bEndOnRpt; if 1, the operation shall end, otherwise scanning shall continue.
If pParams->extFilterConfig.bAutoWlIgnore is 1, an auto-ignore feature is enabled. In the cases where stated in the right-most column of Table 26-144 and no ADI field is present in the extended header, the radio CPU shall then automatically set the bWlIgn bit of the whitelist entry corresponding to the address from which an ADV_EXT_IND message was received. This shall be done either after action 2 is performed or when action 6 is about to be performed. This can be used to avoid reporting multiple advertising messages from the same device and to avoid scanning the same device repeatedly.
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 Section 26.8.10.3 or to end the operation with status BLE_DONE_AUX.