SWCU192 November 2021 CC1312R7 , CC1352P7 , CC2652P7 , CC2652R7
The CMD_PROP_RX_ADV is used for receiving packets with the format from Figure 26-10. As a special case, the user can set up packets as in Figure 26-9. The parameters are as given in Table 26-175.
The modem configures the receiver and starts listening for sync. The sync word to listen for is given in the syncWord0 field, in the LSBs if less than 32 bits are used. The word is in the bit order programmed in the radio. If syncWord1 is nonzero, the receiver also listens for the sync word given in the syncWord1 field (formatted in the same way) if supported in the MCE. It is not possible to use two sync words when using CMD_PROP_RX_ADV_SNIFF with csConf.bEnaCorr set to 1.
If sync is found, the radio CPU starts receiving data. The packet may contain a header, which can consist of any number of bits up to 32, given by hdrConf.numHdrBits. If the number of bits in the header does not divide by 8, it is considered to consist of a sufficient number of bytes to contain all the stored bits, as shown in Section 26.5.3.1. This header may contain a length field or an address.
The received packet may have fixed or variable length. If hdrConf.numLenBits is 0 and maxPktLen is nonzero, the packet has a fixed length, consisting of maxPktLen bytes after the header and before the CRC. If hdrConf.numLenBits is greater than 0, a field of hdrConf.numLenBits, read from bit number hdrConf.lenPos from the LSB of the header, is taken as a length field. The signed number lenOffset is added to the received length to give the number of bytes after the header and before the CRC. If this number is less than or equal to maxPktLen, the packet is received. If maxPktLen is zero, the length is unlimited as described in the beginning of Section 26.10.5.4. The definition of packet length for CMD_PROP_RX_ADV differs from the one for CMD_PROP_TX_ADV , see Section 26.10.5.4.2 where the header is included in the packet length.
Two kinds of addresses are supported. With the first option, the address is part of the header. In this case, the address size can be from 1 to 31 bits. The other option is to have an address after the header. If so, this address consists of between 1 and 8 bytes. To use an address as part of the header, addrConf.addrType must be set to 1. The number of bits in the address is given by addrConf.addrSize. These bits are read from bit number addrConf.addrPos from the first bit of the header. To use an address after the header, addrConf.addrType must be set to 0. In this case, the number of bytes in the address is given by addrConf.addrSize.
The received address is compared to an address list pointed to by pAddr. The address to compare against this list is as received. In addition, one bit identifying the sync word is concatenated with the address as the MSBs, if one of the following conditions is fulfilled:
This extra bit is 0 if the received sync word was syncWord0, and 1 if the received sync word was syncWord1. The entries in the address list have a size of 8, 16, 32, or 64 bits; the smallest size that can fit the address size, including the sync word identification bit if applicable. The number of entries in the address list is given by addrConf.numAddr. The radio CPU scans through the addresses in the address list and compares it to the received address. If there is no match, the further treatment depends on pktConf.filterOp. If this is 0, reception is stopped and synch search is restarted. If it is 1, the packet is received as if the address had matched, but marked as ignored.
If addrConf.addrSize is zero, no address is used. In this case, pAddr is ignored and must be NULL.
If the packet is being received, the data is placed in the receive buffer, as in Section 26.5.3.1. This receive buffer is found from the receive queue pointed to by pQueue. If pQueue is NULL, the packet is never stored.
The header is received as one field in the bit ordering programmed in the radio. If the header has more than 8 bits and rxConf.bIncludeHdr is 1, the header is always written in little-endian byte order to the receive buffer. If the radio is configured to receive the MSB first, the last header byte stored in the receive buffer is received first. The payload is stored byte by byte, so after the header, no swapping of bytes occurs regardless of bit ordering over the air.
If pktConf.bUseCrc is 1, a CRC is received and checked at the end. The number of CRC bits, polynomial, and initialization are as configured in the radio. If pktConf.bCrcIncSw is 1, the received sync word (assuming it to be exactly equal to syncWord0 or syncWord1) is included in the data set over which the CRC is calculated. If pktConf.bCrcIncHdr is 1, the received header is included in the data set over which the CRC is calculated. The payload, including the optional address after the header, is always used for calculating the CRC. If pktConf.bUseCrc is 0, the treatment is as for CRC OK.
If whitening is enabled, the optional header is subject to dewhitening only if pktConf.bCrcIncHdr is 1. The payload including the optional address after the header, and the received CRC, are always subject to dewhitening when enabled. The dewhitening is done before the CRC is evaluated.
If a status byte is appended (rxConf.bAppendStatus is 1) to the packet, it is formatted as follows (see Receive Buffers
Table 26-180). If addrConf.addrSize is nonzero, the addressInd field is the first index into the address list that matched the received address if an address match existed. Otherwise, addressInd is 0. The syncWordId field is 0 if the received sync word was syncWord0, and 1 if syncWord1. The result field is written according to Table 26-185.