Extended advertising packets on secondary channel (AUX_ADV_IND) are accepted if running CMD_BLE5_INITIATOR 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. Only connectable packets are accepted by an initiator. The parameter pParams->initConfig.bUseWhiteList determines if the initiator should try to connect to a specific device or against the whitelist. If this parameter is 0, the whitelist is not used, and pParams->pWhiteList shall point to a buffer containing only the device address of the device to connect to. The address type of the peer shall be given in pParams->advConfig.peerAddrType (see also Section 26.8.17). Otherwise, pParams->pWhiteList shall point to a whitelist, and 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. The complete check on AdvA is performed as listed in Table 26-144. 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->initConfig.deviceAddrType, respectively (see also Section 26.8.17), and match if they are equal. Nondirected messages always have TargetA match. Depending on the received packet, the actions taken shall be as given in Table 26-159, where the definition of each action, including the value that will be used on bCrcErr and bIgnore, is given in Table 26-160. The packet length of a received AUX_ADV_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->initConfig.bStrictLenFilter is 1, all defined fields are considered, while if pParams->initConfig.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.

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_CONNEXT_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_CONNECT_REQ shall be transmitted. If not, the operation shall end.

When transmitting an AUX_CONNECT_REQ, the radio CPU shall construct this packet. In the header, the PDU Type bits shall be 0101b. The TxAdd bit shall be as in pParams->initConfig.deviceAddrType (if the least significant bit of pParams->pDeviceAddress is 1, the TxAdd bit is inverted, 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 calculated from the length of the LLData, meaning that it shall be pParams->connectReqLen + 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. The rest of the payload shall be read from the pParams->pConnectData buffer. If pParams->initConfig.bDynamicWinOffset is 1, the radio CPU will replace the bytes in the WinSize and WifOffset position with a calculated value (see the Specification of the Bluetooth System, Version 5.0 listed in Related Documentation).

After an AUX_CONNECT_REQ message is transmitted, the radio CPU shall configure receiver and look for an AUX_CONNECT_RSP. The packet will be received using the rules from Table 26-161 and Table 26-162. The rules in Table 26-161 mean 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_CONNECT_RSP, the backoff parameters shall be updated by the radio CPU as described in Section 26.8.15, based on the result as given in the Response Packet Result column of Table 26-148 and the old values of the backoff parameters.