Texas Instruments CC2650DK ユーザーズマニュアル

ページ / 1570
IEEE 802.15.4
When the demodulator obtains sync on a frame, the PHY header is read first. The 7 least significant bits
of this byte give the frame length. The further treatment depends on the setting of frameFiltOpt. If
frameFiltOpt.frameFiltEn is 1, further frame filtering is done as explained below. If it is 0, no frame filtering
is done.
The number of bytes given by the received PHY header are received and stored in the receive queue
given by pRXQ. The format depends on RXConfig, and is as explained in
Receive
Buffers. The last two bytes of the PHY payload are the FCS, or CRC, for the packet. These bytes are
checked according to the FCS specification, and the further treatment depends on the CRC result.
If there is a CRC error and RXConfig.bAutoFlushCrc is 1, the packet is discarded from the RX buffer. If
there is no available RX buffer with enough available space to hold the received packet, the received data
is discarded. If frameFiltOpt.frameFiltStop is 1, the reception stops, otherwise the packet is received so
that the CRC can be checked.
23.5.4.1.1 Frame Filtering and Source Matching
If frameFiltOpt.frameFiltEn is 1, frame filtering and source matching are performed as described in this
section. The frame filtering may have several purposes:
Distinction between different packet types
Rejection of packets with a non-matching destination address
Rejection of packets with unknown version or illegal fields
Automatic identification of source address
Automatic acknowledgment transmission
Automatic insertion of pending data bit based on source address
23.5.4.1.1.1 Frame Filtering
When frame filtering is enabled, the MAC header of the packet is investigated by the radio CPU. The
frame control field (FCF) is checked first. The frame type subfield is the first subfield of the FCF to be
checked, and determines the further processing. The most significant bit of the frame type is processed
according to frameFiltOpt.modifyFtFilter before the check is made. The result of this modification will only
be used when checking, not when storing the FCF in the RX queue entry. For each of the eight possible
values of the frame type field (included 4 reserved ones), the frame can be set up to be accepted or
rejected. This is controlled by the bits of frameTypes. If the frame type is Acknowledgment (010b) and a
CMD_RX_ACK operation is running in the foreground, the packet is processed further, even if
frameTypes.bAcceptFt2Ack is 0. More details on the processing in that case are given in
Receive Acknowledgment Operation.
Filtering is performed on the Frame Version and Reserved subfields. If the frame version is greater than
frameFiltOpt.maxFrameVersion, the frame is rejected.
If the Reserved subfield AND-ed with frameFiltOpt.fcfReservedMask is nonzero, the frame is rejected. The
addressing fields are checked to see if the frame must be accepted or not. This filtering follows the rules
for third-level filtering. When checking against the local address, the localExtAddr or localShortAddr field is
used, and when checking against the local PAN ID, the localPanID field is used.
If frameFiltOpt.bStrictLenFilter is 1 and the frame type indicates that the frame is an acknowledgment
frame, the frame is rejected if the length of the PHY payload is not 5, which is the length of a correctly-
formulated ACK frame.
If frameFiltOpt.frameFiltStop is 1 and the frame filtering gives the conclusion that the frame is to be
rejected, reception stops and the radio returns to sync search. Otherwise, the frame is received to the end.
The radio CPU checks the header to see if an acknowledgment is to be transmitted. This gives a
preliminary result; the actual transmission of the ACK depends on the status at the end of the frame. The
condition for transmitting an acknowledgment frame is given in
ACK Transmission.
1504
Radio
SWCU117A – February 2015 – Revised March 2015
Copyright © 2015, Texas Instruments Incorporated