In-depth research on the underlying platform of wireless sensor networks

Introduction
    At present, the research on WSN (Wireless Sensor Netwoek) mainly focuses on protocol stack, positioning algorithm, energy consumption management and architecture design, while the research on wireless sensor network operating system is relatively small, especially the research on its underlying platform. Therefore, there is a very broad space for the research on the underlying platform of wireless sensor network operating system. This paper introduces STMicroelectronics STM32 series MCU and TI's CC2520 wireless module. It mainly describes the construction of the underlying platform of the operating system and the implementation of the hardware driver. The underlying hardware abstraction layer of this paper is for the CC2520 wireless RF module, including platform construction, related registers, and peripheral interfaces. The hardware driver is mainly designed to complete the hardware driver required for wireless communication, which mainly includes: the interrupt mechanism of the corresponding asynchronous event; the USART driver for communication with the PC; the SPI driver for connecting the MCU and CC2520; the timer for completing the timeout, etc. The effective composition of these modules can constitute a complete minimum communication system of wireless sensor network, completing tasks such as data transmission, data processing, positioning and navigation between nodes. The
    STM32 series MCU adopts the Correx-M3 core of ARM's V7 architecture. CC2520 is the second generation ZigBee/IEEE 802.15.4 transceiver.

1 Research on the underlying platform
     There are many underlying hardware modules in the hardware abstraction layer. This section only briefly introduces the underlying module design related to wireless sensor networks.
1.1 Timer
     The CPU of the STM32 series can provide 8 timers, of which TIM1 and TIM8 are advanced timers that can be used for various purposes, including measuring the pulse length of the input signal (input capture) or generating output waveforms (output comparison). Their clocks are provided by APB2. TIM2~TIM7 are ordinary timers, and their clocks are provided by APB1. Figure 1 shows the timer part of the STM32 clock tree.

As can be seen from Figure 1, the clock frequency generated from the clock source set by the system is input to the AHB pre-divider for frequency division, and then different clock frequencies are provided to different modules through the APB1 pre-divider and the APB2 pre-divider. The following takes timer 2 as an example. When the input frequency of the AHB pre-divider is 72 MHz, since the maximum frequency supported by APB1 is 36 MHz, the APB1 pre-divider must be set to be greater than or equal to 2. Assuming it is set to 2, the frequency is set to 72 MHz in the APB1 multiplier (when the APB1 division number = 1, the APB1 multiplier multiplication factor is 1, and when the APB1 division number > 1, the APB1 multiplier multiplication factor is 2), so the final frequency provided to timers 2 to 7 is 72 MHz. Therefore, you only need to set the values ​​of the APB1 pre-divider and the APB1 multiplier to provide timers with different frequencies. The timer uses the count overflow method to trigger the timer interrupt, so if you want to use the timer, you must first configure the timer interrupt.
1.2 Interrupts
     The interrupt configuration steps for the STM32 series MCU are as follows:
    ① System initialization: For example, the system clock is initialized. Use the SystemInit() function in the firmware template. This function adjusts the main frequency to 72 MHz by default.
    ② GPIO configuration: Configure the pin that triggers the CPU interrupt. Be sure to turn on the GPIO clock and AFIO clock of the corresponding pin. Configure the frequency and input mode of the pin, which is generally a floating input mode.
    ③ EXTI configuration: First, specify which pin is used as the pin to trigger the external interrupt in the current system, then clear the interrupt flag, configure the interrupt request and trigger mode (rising edge trigger or falling edge trigger).
    ④ NVIC configuration: Mainly configure the channel corresponding to the interrupt, set the priority level, and finally enable the channel.
    ⑤ Write an interrupt service program: The interrupt service program is the program that actually runs when an interrupt occurs. It interrupts the running program and handles the corresponding interrupt event accordingly. Since the interrupt program interrupts the operation of the existing program and needs to respond quickly to the interrupt event, it should be as short as possible, and cannot pass parameters and has no return value.
1.3 USART
    The USART module is generally divided into three parts: data transmitter, data receiver and clock generator. All modules share control registers. The clock generator consists of a baud rate generator and a synchronous logic circuit. The
    data transmitter part consists of a write buffer register (USART DR), a check bit generator, a serial shift register and a control logic circuit. Using the write buffer register, multiple frames of data can be sent continuously and quickly.
    The data receiver is the most complex part of the USART module. The most important part is the data receiving unit and the clock. The data receiving unit is used to receive asynchronous data. The data receiver also includes a shift register, control logic, a check bit checker and a receiving buffer. The data receiver supports the same frame structure as the data transmitter, and supports the detection of data overflow, frame error and check error. The
    wireless node can communicate with the PC through the USART. This article only implements simple USART functions. The serial port needs to be initialized before use, mainly setting the word length, baud rate, parity bit, transmission mode, number of data bits, flow control, turning on the serial port clock and configuring the serial port sending and receiving pins.
    With the input/output function of the serial port, you can rewrite the library function printf yourself to facilitate debugging and observing the operation of the node, redirect the node terminal output to the PC, and then display the data information sent by the node through the serial port tool on the PC to analyze the terminal operation. The specific function design is: if the node outputs string data, the serial port output string function is directly called to send the string data to the PC for display through the serial port; if it is a digital output, the number is first converted into a string according to the specified display base, and then processed in the output string mode. You can rewrite the itoa() function to save the input number into a string according to any base.
1.4 SPI
    SPI has three registers: control register (SPI_CR), status register (SPI_SR), and data register (SPI_DR). The SPI interface includes 4 signals: MOSI - slave device data input, master device data output; MISO - slave device data output, master device data input; SCLK - clock signal, generated by the master device; NSS - slave device select enable signal, controlled by the master device, some chip manufacturers will mark it as CS (Chip Select).
    Since the wireless module CC2520 must communicate with the MCU through the SPI interface, the SPI interface must be implemented first to control CC2520 to receive and send data. The processing method of the SPI interface is very similar to that of the USART interface. This article only implements simple SPI functions. SPI must be initialized before use. The main work includes setting the master-slave mode, baud rate, number of data bits, data frame format, configuring the input/output pins and the phase and polarity of the clock signal, etc.
1.5 CC2520 drives
    the MCU to control CC2520 to start, shut down, send and receive data, etc. through the SPI interface. The SPI interface consists of four pins: SI, SO, CSn and SCLK. During the communication process between MCU and CC2520, CC2520 is the SPI interface slave device, receiving the clock signal and chip select signal sent by the MCU, and performing operations such as sending and receiving data under the control of the MCU; STM32 is the interface master device, and can access the internal storage area and registers of CC2520 through the SPI interface. CC2520 uses four pins: FIFO, FIFOP, SFD and CCA to indicate the working status. MCU can obtain the status of CC2520 receiving and sending data by reading the data of these pins. SFD signal indicates that the frame start signal has just been received or sent; FIFO signal indicates that one or more bytes are in the receiving buffer; FIFOP signal indicates that the number of bytes in the receiving buffer exceeds the set threshold or at least one complete frame of data is received; CCA signal indicates that the channel is idle.
    The general workflow of CC2520: First, preparation. The halRfInit() function is used in the upper-level application to complete some initialization work of CC2520, such as resetting CC2520 and turning off the voltage regulator. According to the CC2520 data sheet, a delay of 1100μs is required. After the delay is completed, turn on the voltage regulator, delay for another 200μs, and then enable CC2520. After completion, apply for SPI resources and initialize. Turn on the oscillator, and then configure the default values ​​of some registers in CC2520 through the SPI interface, such as the values ​​of registers such as TXPOWER, CCACTRL0, MAMCTRL0, and MAMCTRL1. Then, the pins connecting the MCU and CC2520 are initially configured, such as configuring RSTN, VREN and CSN as output mode, and configuring FIFO, FIFOP, CCA and SFD as input mode.
    The basicRfInit() function is used in the upper-level application to complete the setting of the channel, short address and network ID, and the receive interrupt processing function is configured to process the received data when an interrupt is generated when receiving data.
    When the application executes the send command, after encapsulating the data layer by layer from the upper layer according to the protocol stack, the data is finally handed over to the basicRfSendPacket() function for processing. The specific sending process is shown in Figure 2.

The format of the package in the figure complies with the protocol requirements, and the content mainly includes data length, frame control field (FCF), destination address, source address, destination network ID, source network ID, transmission data, CRC (Cyclic Redundancy Check) check code, etc. When hardware CRC check is used, the user does not need to calculate and add CRC check code, nor does the CRC check data need to be written into TXFIFO (CC2 520 transmission buffer). There is a special register to store CRC check data, and the hardware completes the check and transmission. When software CRC check is used, the user needs to calculate the CRC check data by himself, fill it in the last two bytes of the frame, and write it into TXFIFO together with other data in the frame. [page]
    After encapsulation, write the data into TXFIFO. Note that the CC2520 transmission buffer is 128 bytes and cannot exceed this range, otherwise it will cause TXOVERFLOW exception. Then, the send command can be called to send data after the receive data interrupt is turned on. Here, the sending process can be fully controlled. For example, in the process of sending data, the rising edge signal of the SFD pin can be captured to accurately time the transmission. After sending data, wait for the receiver to reply ACK. If ACK is not received within the specified time, determine whether the number of retransmissions exceeds the maximum number of retransmissions. If not, back off for a period of time according to a certain strategy and then resend the data packet. If the maximum number of retransmissions is exceeded, discard the packet and set the send failure flag for reference by the upper-layer program. If ACK is received within the specified time, the RX_FRMDONE interrupt will be triggered, and the basicRfRxFrmDonelsr() receive data interrupt handler will be called to analyze the received ACK packet. If it is a correct reply to the packet just sent, it means that the transmission is successful, and the corresponding information is updated, such as adding 1 to the send sequence number, updating the send status, and clearing the TX_FRM_DONE exception. The
    receiving process is similar to the sending process, and the specific receiving process is shown in Figure 3.

2 Test
2.1 Test method
     Each node under test is connected to the PC via a serial port line. Add test code to the test program to send the MAC (Media Access Control) layer data information sent and received by the test node to the PC via the serial port. Then display it through the serial port debugging assistant on the PC. By analyzing this data information, you can know the running status of each module program on the node.
2.2 Test process and results
     The running status of the underlying module is judged by analyzing the process of the cluster head node broadcasting data frames to the terminal nodes in the cluster. The cluster head node A and the terminal nodes (B, C, D) in the cluster are all connected to the PC via serial port lines. The cluster network number is 0x0001, and the addresses of nodes A, B, C, and D are: 0x0001, 0x0002, 0x0003, and 0x0004 respectively. A sends broadcast data to B, C, and D through the wireless module, and sends the sent data to the PC for display, and finally sends the received ACK reply frame to the PC for display; B, C, and D receive the data sent by A through the wireless module, reply to the received data frame after delaying according to the size of their own node address, and send the received data frame and reply ACK frame to the PC for display through the serial port.

    Figure 4 shows the process of the cluster leader node sending data frames and receiving ACK frames. The encapsulation format of the protocol stack MAC layer frame follows the IEEE 802.15.4 standard. As can be seen from Figure 4: the first frame is the data frame sent by the sending node, and the following three frames are the ACK frames replied by the receiving terminal node. According to the frame encapsulation format in the IEEE Std 802.15.4-2006 standard, the first byte displayed in the sending window is the physical layer data length. The FCF (Frame Control Field, which occupies 2 bytes) follows, which is 0x8801 for sending trusted broadcast data frames. Referring to the FCF settings in the standard manual, it can be seen that the settings for the data frame are as follows: both the node address and the network address are 16 bits; the frame includes the source network ID, source node address, destination network ID, and destination node address; ACK frame confirmation is required; no security settings are used. The following is DSN (1 byte), which is the first frame transmitted, so it is set to 0x01. The following is the destination network number 0x0001 (occupying 2 bytes). The following is the destination node address 0xFFFF (2 bytes), which is the broadcast address. When CC2520 finds that the destination node address is a broadcast address, it transmits the broadcast frame to all nodes. The following is the source network number 0x0001 (2 bytes). The following is the source node address 0x0001 (2 bytes). Because this is a broadcast frame sent by the head of the same network segment to the terminal node, the destination network number and the source network number are the same. The following 2 bytes are MAC layer data. In order to simplify the test, only 2 bytes of data (1 and 2, ASCALL codes are 0x31 and 0x32) were sent during the test. The trusted broadcast frame requires the receiving node to reply to the ACK frame. The data in the following three boxes are the ACK frames replied by nodes B, C, and D respectively. The format of the reply frame is similar to the setting of the data frame. The difference is that the FCF of the reply frame is 0x8802, indicating that it is a reply frame and does not need to be confirmed. There is no data field in the reply frame, and the destination network number and destination address in the reply frame are the source network number and source address in the received data frame.

    Figure 5 shows the received data frame of the receiving node B. As can be seen from the figure, the first frame is the received trusted broadcast data frame, and the data in the second frame is the sent ACK frame. The data in the front of the receiving window is the same as the data in the sending window. The difference is the last 2 bytes (for a detailed explanation, please refer to Section 3.5 CC2520 receiving process). The receiving node parses the destination address and finds that it is a broadcast address. It needs to check whether the Ack Request in the FCF field is 1. If it is 1, it needs to reply with an ACK frame. In order to avoid channel collision caused by the node in the group receiving the trusted broadcast data frame and replying to the ACK frame at the same time, the reply ACK frame is sent with a delay according to the size of its own node address. The receiving serial port display data of other nodes (C, D) in the group is similar to that of node B, so it will not be explained in detail here.

Conclusion
     From the test results, the data sent by the sending node through CC2520 can be received, and the node receives it correctly and sends it to the PC through the serial port. This shows that each module introduced in the paper can work correctly and stably. Through the collaborative work of these underlying modules, basic communication services are provided for the upper operating system and protocol stack. This paper simply completes the functions of each module, and there are still many areas for improvement. For example, precise timing control can be added during the CC2520 communication process to provide better services for the upper layer.