SWCU185G January 2018 – June 2024 CC1312PSIP , CC1312R , CC1352P , CC1352R , CC2642R , CC2642R-Q1 , CC2652P , CC2652PSIP , CC2652R , CC2652RB , CC2652RSIP , CC2662R-Q1
Before running any radio operation command described in this document (with exception to the CMD_BLE5_RADIO_SETUP command), the radio must be set up in Bluetooth low energy mode using the CMD_BLE5_RADIO_SETUP command or the CMD_RADIO_SETUP command. Otherwise, the operation will end with error. When running any of the Bluetooth low energy 5 commands, the CMD_BLE5_RADIO_SETUP command must be used.
The operations start with a radio operation command from the system CPU. The actual start of the operation is set up by the radio CPU according to startTrigger and startTime in the command structure. At this time, the radio CPU starts configuring the transmitter or receiver, depending on the type of operation. The system CPU must take the setup time of the transmitter or receiver into account when calculating the start time of the operation.
The radio CPU sets up the channel based on the channel parameter. If the channel is in the range 0–39, it indicates a data channel index or advertising channel index. In this case, only the values 0–36 are allowed in master and slave commands, and only the values 37–39 are allowed in advertiser, scanner, and initiator commands. If the channel is in the range 60–207, it indicates an RF frequency with an offset of 2300 MHz. If the channel is 255, the radio CPU does not program any frequency word, but keeps the frequency already programmed with CMD_FS. If the channel is 255 and the frequency synthesizer is not running, the operation ends with an error.
The whitening parameter indicates the initialization of the 7-bit LFSR used for data whitening in Bluetooth low energy. If whitening.bOverride is 0 and the channel is in the range 0–39, the LFSR initializes with (0x40 | channel). Otherwise, the LFSR initializes with whitening.init. If whitening.init is 0 in this case, no whitening is used.
All packets transmitted using the Bluetooth low energy radio operation commands shall have a Bluetooth-low-energy-compliant CRC appended. On all packets received using the Bluetooth low energy radio operation commands, a Bluetooth-low-energy-compliant CRC check shall be performed. The initialization of the CRC register is defined for each command.
The Bluetooth low energy 5 commands have some additional parameters. The phyMode parameter is used to select which of the PHYs to use for the command. For the coded PHY, phyMode.coding gives a rule for selecting the coding used for each packet (see Section 26.8.3 for details). The txPower parameter can be used to select a specific TX power for use in this command, which overrides the one set in the radio setup command and the one set with the CMD_SET_TX_POWER command. If txPower is set to 0x0000, the TX power from the setup command or last CMD_SET_TX_POWER command is used. The rangeDelay parameter gives an extra listening time used for a receiver after T_IFS. The number of RAT ticks given is added to the end of the listening window.
To fulfill the requirements for T_IFS, transmissions following receptions is timed and synchronized by the radio CPU. For reception immediately following transmissions, the radio CPU times the start of RX and timeout so that it always receives a packet transmitted at a time within the limits set by the Bluetooth low energy standard, but without excessive margins, to avoid false syncing on advertising channels. For the first receive operation in a slave command, the radio CPU sets up a timeout as defined in pParams->timeoutTrigger and pParams->timeoutTime. The time of this trigger depends on the sleep-clock uncertainty, both in the slave and the peer master.
When the receiver is running, the message is received into an RX entry, as described in Section 26.3.2.7.2. The radio CPU shall have flags bCrcErr and bIgnore, which are to be written to the corresponding fields of the status byte of the RX entry, if present. If there is a CRC error on the received packet, the bCrcErr flag shall be set. If the CRC is OK, the bIgnore flag may be set based on principles defined for each role. This flag means that the system CPU may ignore the packet. After receiving a packet, the radio CPU shall raise an interrupt to the system CPU.
If a packet is received with a length field that is greater than the maximum length defined in the following, the reception is stopped, and this is treated as if sync had not been obtained on the packet. When the radio is set up using the CMD_RADIO_SETUP command, the length field in data channel packets is configured to have 5 bits and the length field in advertising channel packets is configured to have 6 bits, which corresponds to the specification in Bluetooth 4.0 and Bluetooth 4.1. In Bluetooth 4.2, the data channel packets have an 8-bit length filed, which may be configured with an override, see Section 26.8.4. When the radio is set up using the CMD_BLE5_RADIO_SETUP command, all length fields are configured to have 8 bits, which corresponds to the specification in Bluetooth 5.0.
By default, the maximum allowed payload length of legacy advertising channel packets is 37, and the maximum allowed payload length of extended advertising channel packets is 255. For legacy master and slave commands, the default maximum allowed length of received data channel packets is 31 (which will never be violated with the default setting using the CMD_RADIO_SETUP command because the length field in this case is 5 bits). For Bluetooth low energy 5 master and slave commands, the maximum packet length of received packets is set in the command structure pParams->maxRxPktLen.
If either the bCrcErr or bIgnore flag is set or if the packet was empty (as defined under each operation), the packet may be removed from the RX entry prior to raising the interrupt, depending on the bAutoFlushIgnored, bAutoFlushCrc, and bAutoFlushEmpty bits of pParams->rxConfig.
The status field of the command issued shall be updated during the operation. When submitting the command, the system CPU shall write this field with a state of IDLE. During the operation, the radio CPU shall update the field to indicate the operation mode. When the operation is done, the radio CPU shall write a status indicating that the operation is finished. Table 26-125 lists the status codes to be used by a Bluetooth low energy radio operation.
Number | Name | Description |
---|---|---|
Operation Not Finished | ||
0x0000 | IDLE | Operation not started |
0x0001 | PENDING | Waiting for start trigger |
0x0002 | ACTIVE | Running operation |
Operation Finished Normally | ||
0x1400 | BLE_DONE_OK | Operation ended normally |
0x1401 | BLE_DONE_RXTIMEOUT | Timeout of first RX of slave operation or end of scan window |
0x1402 | BLE_DONE_NOSYNC | Timeout of subsequent RX |
0x1403 | BLE_DONE_RXERR | Operation ended because of receive error (CRC or other) |
0x1404 | BLE_DONE_CONNECT | CONNECT_IND or AUX_CONNECT_RSP received or transmitted |
0x1405 | BLE_DONE_MAXNACK | Maximum number of retransmissions exceeded |
0x1406 | BLE_DONE_ENDED | Operation stopped after end trigger |
0x1407 | BLE_DONE_ABORT | Operation aborted by abort command |
0x1408 | BLE_DONE_STOPPED | Operation stopped after stop command |
0x1409 | BLE_DONE_AUX | Operation ended after receiving AuxPtr pointing a long time ahead |
0x140A | BLE_DONE_CONNECT_CHSEL0 | CONNECT_IND received or transmitted; peer does not support channel selection algorithm number 2 |
Operation Finished With Error | ||
0x1800 | BLE_ERROR_PAR | Illegal parameter |
0x1801 | BLE_ERROR_RXBUF | No available RX buffer (Advertiser, Scanner, Initiator) |
0x1802 | BLE_ERROR_NO_SETUP | Radio was not set up in Bluetooth low energy mode |
0x1803 | BLE_ERROR_NO_FS | Synthesizer was not programmed when running RX or TX |
0x1804 | BLE_ERROR_SYNTH_PROG | Synthesizer programming failed |
0x1805 | BLE_ERROR_RXOVF | RX overflow observed during operation |
0x1806 | BLE_ERROR_TXUNF | TX underflow observed during operation |
0x1807 | BLE_ERROR_AUX | AUX pointer target is too far into the future |
The conditions for giving each status are listed for each operation. Some of the error causes listed in Table 26-125 are not repeated in these lists. In some cases, general error causes may occur. In all of these cases, the result of the operation is ABORT.