RADIO — 2.4 GHz Radio

The RADIO use EasyDMA for reading and writing of data packets from and to the RAM without CPU involvement.

As illustrated in Figure 1, the RADIO's EasyDMA utilizes the same PACKETPTR for receiving and transmitting packets. The CPU should reconfigure this pointer every time before the RADIO is started via the START task.

The structure of a radio packet is described in detail in Packet configuration. The data that is stored in Data RAM and transported by EasyDMA consists of S0, LENGTH, S1, the payload itself, and a static add-on sent immediately after the payload.

The size of each of the above elements in the frame is configurable (see Packet configuration), and the space occupied in RAM depends on these settings. A size of zero is possible for any of the fields, it is up to the user to make sure that the resulting frame complies with the RF protocol chosen.

For the field sizes defined in bits, the occupation in RAM will always be rounded up to the next full byte size (for instance 3 bit length will allocate 1 byte in RAM, 9 bit length will allocate 2 bytes, etc.).

In addition, the S0INCL field in PCNF0 determines if S0 is present in RAM at all if its length is zero. If present, one byte is allocated in RAM.

The size of S0 is configured through the S0LEN field in PCNF0. The size of LENGTH is configured through the LFLEN field in PCNF0. The size of S1 is configured through the S1LEN field in PCNF0. The size of the payload is configured through the value in RAM corresponding to the LENGTH field. The size of the static add-on to the payload is configured through the STATLEN field in PCNF1.

The MAXLEN field in the PCNF1 register configures the maximum packet payload plus add-on size in number of bytes that can be transmitted or received by the RADIO. This feature can be used to ensure that the RADIO does not overwrite, or read beyond, the RAM assigned to the packet payload. This means that if the packet payload length defined by PCNF1.STATLEN and the LENGTH field in the packet specifies a packet larger than MAXLEN, the payload will be truncated at MAXLEN.

Note that MAXLEN includes the payload and the add-on, but excludes the size occupied by the S0, LENGTH and S1 fields. This has to be taken into account when allocating RAM.

If the payload plus add-on length is specified larger than MAXLEN, the RADIO will still transmit or receive in the same way as before except the payload is now truncated to MAXLEN. The packet's LENGTH field will not be altered when the payload is truncated. The RADIO will calculate CRC as if the packet length is equal to MAXLEN.

If the PACKETPTR is not pointing to the Data RAM region, an EasyDMA transfer may result in a HardFault or RAM corruption. See Memory for more information about the different memory regions.

The DISABLED event indicates that the EasyDMA has finished accessing the RAM.

A Radio packet contains the following fields: PREAMBLE, ADDRESS, S0, LENGTH, S1, PAYLOAD and CRC.

See Figure 2. Not shown in the figure is the static payload add-on (the length of which is defined in STATLEN, and which is 0 bytes long in a standard BLE packet), and would be sent between PAYLOAD and CRC. The Radio sends the different fields in the packet in the order they are illustrated below, from left to right. The preamble will be sent least significant bit first on-air.

For all modes, except for 2 Mbit/s Bluetooth Low Energy mode, the preamble is one byte long. For 2 Mbit/s Bluetooth Low Energy mode the preamble is 2 bytes long. If the first bit of the ADDRESS is 0 the preamble will be set to 0xAA otherwise the PREAMBLE will be set to 0x55.

Radio packets are stored in memory inside instances of a radio packet data structure as illustrated in Figure 3. The PREAMBLE, ADDRESS and CRC fields are omitted in this data structure.

The byte ordering on air is always Least Significant Byte First for the ADDRESS and PAYLOAD fields and Most Significant Byte First for the CRC field. The ADDRESS fields are always transmitted and received least significant bit first on-air. The CRC field is always transmitted and received Most Significant Bit first. The bit-endian, i.e. which order the bits are sent and received in, of the S0, LENGTH, S1 and PAYLOAD fields can be configured via the ENDIAN in PCNF1.

The S0INCL field in PCNF0 determines if S0 is present in RAM at all if its length is zero. If present, one byte is allocated in RAM.

The sizes of the S0, LENGTH and S1 fields can be individually configured via S0LEN, LFLEN and S1LEN in PCNF0 respectively. If any of these fields are configured to be less than 8 bit long the, the least significant bits of the fields, as seen from the RAM representation, are used.

If S0, LENGTH or S1 are specified with zero length their fields will be omitted in memory, otherwise each field will be represented as a separate byte, regardless of the number of bits in their on-air counterpart.

Independent of the configuration of MAXLEN, the combined length of S0, LENGTH, S1 and PAYLOAD cannot exceed 258 bytes.

The on-air radio ADDRESS field is composed of two parts, the base address field and the address prefix field.

The size of the base address field is configurable via BALEN in PCNF1. The base address is truncated from LSByte if the BALEN is less than 4. See Table 1.

The on-air addresses are defined in the BASEn and PREFIXn registers, and it is only when writing these registers the user will have to relate to actual on-air addresses. For other radio address registers such as the TXADDRESS, RXADDRESSES and RXMATCH registers, logical radio addresses ranging from 0 to 7 are being used. The relationship between the on-air radio addresses and the logical addresses is described in Table 1.

The RADIO is able to do packet whitening and de-whitening.

See WHITEEN in PCNF1 register for how to enable whitening. When enabled, whitening and de-whitening will be handled by the RADIO automatically as packets are sent and received.

The whitening word is generated using polynomial g(D) = D⁷+ D⁴ + 1, which then is XORed with the data packet that is to be whitened, or de-whitened. See the figure below.

Whitening and de-whitening will be performed over the whole packet (except for the preamble and the address field).

The linear feedback shift register, illustrated in Figure 4 can be initialised via the DATAWHITEIV register.

The CRC generator in the RADIO calculates the CRC over the whole packet excluding the preamble. If desirable, the address field can be excluded from the CRC calculation as well

See CRCCNF register for more information.

The CRC polynomial is configurable as illustrated in Figure 5 where bit 0 in the CRCPOLY register corresponds to X⁰ and bit 1 corresponds to X¹ etc. See CRCPOLY for more information.

As illustrated in Figure 5, the CRC is calculated by feeding the packet serially through the CRC generator. Before the packet is clocked through the CRC generator, the CRC generator's latches b₀ through b_n will be initialized with a predefined value specified in the CRCINIT register. When the whole packet is clocked through the CRC generator, latches b₀ through b_n will hold the resulting CRC. This value will be used by the RADIO during both transmission and reception but it is not available to be read by the CPU at any time. A received CRC can however be read by the CPU via the RXCRC register independent of whether or not it has passed the CRC check.

The length (n) of the CRC is configurable, see CRCCNF for more information.

After the whole packet including the CRC has been received, the RADIO will generate a CRCOK event if no CRC errors were detected, or alternatively generate a CRCERROR event if CRC errors were detected.

The status of the CRC check can be read from the CRCSTATUS register after a packet has been received.

The RADIO can enter a number of states.

The RADIO can enter the states described the table below. An overview state diagram for the RADIO is illustrated in Figure 6. This figure shows how the tasks and events relate to the RADIO's operation. The RADIO does not prevent a task from being triggered from the wrong state. If a task is triggered from the wrong state, for example if the RXEN task is triggered from the RXDISABLE state, this may lead to incorrect behaviour. As illustrated in Figure 6, the PAYLOAD event is always generated even if the payload is zero.

Before the RADIO is able to transmit a packet, it must first ramp-up in TX mode.

See TXRU in Figure 6 and Figure 7. A TXRU ramp-up sequence is initiated when the TXEN task is triggered. After the radio has successfully ramped up it will generate the READY event indicating that a packet transmission can be initiate. A packet transmission is initiated by triggering the START task. As illustrated in Figure 6 the START task can first be triggered after the RADIO has entered into the TXIDLE state.

Figure 7 illustrates a single packet transmission where the CPU manually triggers the different tasks needed to control the flow of the RADIO, i.e. no shortcuts are used. If shortcuts are not used, a certain amount of delay caused by CPU execution is expected between READY and START, and between END and DISABLE. As illustrated in Figure 7 the RADIO will by default transmit '1's between READY and START, and between END and DISABLED. What is transmitted can be programmed through the DTX field in the MODECNF0 register.

A slightly modified version of the transmit sequence from Figure 7 is illustrated in Figure 8 where the RADIO is configured to use shortcuts between READY and START, and between END and DISABLE, which means that no delay is introduced.

The RADIO is able to send multiple packets one after the other without having to disable and re-enable the RADIO between packets, this is illustrated in Figure 9.

Before the RADIO is able to receive a packet, it must first ramp up in RX mode

See RXRU in Figure 6 and Figure 10. An RXRU ramp-up sequence is initiated when the RXEN task is triggered. After the radio has successfully ramped up it will generate the READY event indicating that a packet reception can be initiated. A packet reception is initiated by triggering the START task. As illustrated in Figure 6 the START task can, first be triggered after the RADIO has entered into the RXIDLE state.

Figure 10 illustrates a single packet reception where the CPU manually triggers the different tasks needed to control the flow of the RADIO, i.e. no shortcuts are used. If shortcuts are not used, a certain amount of delay, caused by CPU execution, is expected between READY and START, and between END and DISABLE. As illustrated Figure 10 the RADIO will be listening and possibly receiving undefined data, illustrated with an 'X', from START and until a packet with valid preamble (P) is received.

A slightly modified version of the receive sequence from Figure 10 is illustrated in Figure 11 where the the RADIO is configured to use shortcuts between READY and START, and between END and DISABLE, which means that no delay is introduced.

The RADIO is able to receive multiple packets one after the other without having to disable and re-enable the RADIO between packets, this is illustrated Figure 12.

The radio implements a mechanism for measuring the power in the received radio signal. This feature is called Received Signal Strength Indicator (RSSI).

Sampling of the received signal strength is started by using the RSSISTART task. The sample can be read from the RSSISAMPLE register.

The sample period of the RSSI is defined by RSSI_PERIOD, see the device product specification for details. The RSSI sample will hold the average received signal strength during this sample period.

For the RSSI sample to be valid the radio has to be enabled in receive mode (RXEN task) and the reception has to be started (READY event followed by START task).

Interframe spacing is the time interval between two consecutive packets.

It is defined as the time, in micro seconds, from the end of the last bit of the previous packet received and to the start of the first bit of the subsequent packet that is transmitted. The RADIO is able to enforce this interval as specified in the TIFS register as long as TIFS is not specified to be shorter than the RADIO’s turn-around time, i.e. the time needed to switch off the receiver, and switch back on the transmitter.

TIFS is only enforced if END_DISABLE and DISABLED_TXEN or END_DISABLE and DISABLED_RXEN shortcuts are enabled. TIFS is only qualified for use in BLE_1MBIT mode, and default ramp-up mode.

The device address match feature is tailored for address white listing in a Bluetooth Smart and similar implementations.

This feature enables on-the-fly device address matching while receiving a packet on air. This feature only works in receive mode and as long as RADIO is configured for little endian, see PCNF1.ENDIAN.

The Device Address match unit assumes that the 48 first bits of the payload is the device address and that bit number 6 in S0 is the TxAdd bit. See the Bluetooth Core Specification for more information about device addresses, TxAdd and whitelisting.

The RADIO is able to listen for eight different device addresses at the same time. These addresses are specified in a DAB/DAP register pair, one pair per address, in addition to a TxAdd bit configured in the DACNF register. The DAB register specifies the 32 least significant bits of the device address, while the DAP register specifies the 16 most significant bits of the device address.

Each of the device addresses can be individually included or excluded from the matching mechanism. This is configured in the DACNF register.

The RADIO implements a simple counter that can be configured to generate an event after a specific number of bits have been transmitted or received.

By using shortcuts, this counter can be started from different events generated by the RADIO and hence count relative to these.

The bit counter is started by triggering the BCSTART task, and stopped by triggering the BCSTOP task. A BCMATCH event will be generated when the bit counter has counted the number of bits specified in the BCC register. The bit counter will continue to count bits until the DISABLED event is generated or until the BCSTOP task is triggered. The CPU can therefore, after a BCMATCH event, reconfigure the BCC value for new BCMATCH events within the same packet.

The bit counter can only be started after the RADIO has received the ADDRESS event.

The bit counter will stop and reset on BCSTOP, STOP, END and DISABLE tasks.

The figure below illustrates how the bit counter can be used to generate a BCMATCH event in the beginning of the packet payload, and again generate a second BCMATCH event after sending 2 bytes (16 bits) of the payload.