A hardware system with ARM-based data processing for nano satellites

Received Nov 25, 2019 Revised Feb 12, 2020 Accepted Mar 01, 2020 The Institute of Scientific and Technical Research for Defense in Argentina (Instituto de Investigaciones Científicas y Técnicas para la Defensa CITEDEF) is developing a processing hardware module based on a ARM Cortex M4 processor from STMicroelectronics. The microcontroller (MCU) has the capacity to run at a maximum clock frequency of 180 MHz, integrates a Floating Point Unit (FPU). An 8MB SDRAM was included for dynamic data allocation. This hardware will host and process the algorithms to calculate and determine the nanosatellite’s attitude. The module is intended to be Cubesat compatible, possess a flexible design, handles various inertial sensors and can manage backups on microSD memory cards with sizes up to 32GB.


INTRODUCTION
The In the Laboratory of Digital Techniques of the Institute of Scientific and Technical Research for Defense (CITEDEF), a processing module is being developed to be applied to nano-satellite platforms. The design principle is based on complying with the requirement of being able to interconnect with a solar sensor (currently under development) and be able to process different types of navigation algorithms (currently under development).
This processing hardware is necessary for, in the future, to be able to incorporate an Attitude Determination and Control System (ADCS). In addition, this module has a minimum of two asynchronous serial ports, one to be able to connect a UHF communications system and the other to have a system debugging functionality. The hardware has a flexible design and is compatible with other sub-systems.
The core of the processing system is a microcontroller (MCU) with ARM architecture. This system was designed based on its performance and features. For their selection, aspects of speed, efficiency and reliability are considered. Since this hardware module will also be part of the ADCS, the processor used must be powerful enough to perform complex calculations (for example, a Kalman filter) using floating point data. Simultaneously, this system can handle a large volume of data, including real-time telemetry data and hardware status. To improvement efficiency (and since the bus of the entire system has limited power, signals and space) the firmware is configured so that the MCU operates always in low power mode. Stabilization actuators and other subsystems of the nanosatelital platform, such as: the UHF transmitter and the electric power system  To meet all the requirements of the  project, it was necessary to design, develop and implement two initial prototypes, and after several tests we  manufactured the final printed circuit board (PCB). This design and development are intended to be compatible with the CubeSat standard following the guidelines of the CubeSat design specifications manual [1]. The initial design is shown in Figure 1.

MCU IMPLEMENTATION
Currently, the electronic device market offers a very wide range of 8-bits microcontrollers (where consumption is critical) up to 32-bits. In this case, the project requires performing mathematical calculations, and especially handling high-precision data types, such as "doubles" and "floats". For this project it was chosen to use a 32-bits MCU since these can handle the mathematics calculations due to the large size of its registers and bus width. The challenge of the firmware is to minimize the power consumption and avoid having to use high-performance RISC architecture microcontrollers. The Cortex-M4 core features a floating point unit (FPU) that supports all instructions and several types of processing data. It also implements a complete set of DSP instructions and a memory protection unit (MPU) that improves application security. These devices incorporate high-speed integrated memories (Flash memory of up to 2 Mbytes and SRAM of up to 256 Kbytes), up to 4 Kbytes of backup SRAM, and a wide range of input/output ports and peripherals connected to two buses APB, two AHB buses and a 32-bits multi-AHB bus array. In addition, it has three 12-bits ADC ports, two DACs, a low-power RTC, twelve 16-bit general purpose timers that include two PWM channels (which can be used to control the magnetorquer placed on a navigation board). on and control), two other 32-bit timers commonly used for timing and main sync. For the microSD card interface the processor uses a port with serial digital input-output (SDIO) pins.
For greater robustness, an integrated independent watchdog (IWDG) was implemented in the hardware. The IWDG is based on a 12-bit down-counter and an 8-bit prescaler. When the processor stops working due to some external error or a faulty sensor, the watchdog restarts and resets the MCU. This is useful when failures are caused by events called Single-Event-Upset (SEU) or Single-Event-Latchup (SEL).
This module allows the selection of the power supply that energizes the MCU. The power supply can be provided by an external source (which is regulated up to 3.3V), through a USB cable or provided by the EPS module.

GENERAL DESCRIPTION AND SYSTEM DESIGN
The system was designed to have the following characteristics and interconnection capabilities, illustrated in Figure 2. An interconnection of the subsystems thorugh a central data bus. This bus interacts directly with: an EPS for power supply and supervision, a UHF transceiver to send data frames to a ground station, a navigation and control board with a reaction wheel and magnetorquers (MTQ) and additional ports for user applications and future expansions. Figure 2. Part of the system schematic A UART port for system debugging. This serial port of the MCU is connected through a UART bridge interface that converts serial data to USB (using the FTDI chi FT232RL [2]) sending real-time information on the general state of the system and all internal sensor data.
A number of sensors integrated in a dedicated SPI channel. An IMU for measuring 9-axis inertial parameters (Invensense MPU-9250 [3]) in a QFN encapsulated unit that encapsulates a 3-axis gyroscope, a 3axis accelerometer and a magnetometer 3-axis. A temperature sensor compatible with SPI (Texas Instruments TMP122 [4]) that measures temperatures with 2°C accuracy in a temperature range from -55°C to 125°C, and can operate up to 150°C. A high-performance, ultra-low-power 3-axis linear accelerometer (STMicroelectronics AIS328DQ [5]) with a user-selectable dynamic scale of ±2g / ±4g / ±8g and capable of measuring accelerations with a measurement frequency 0.5Hz to 1kHz.
For storage of data, there is a microSD memory that captures in real time all hardware data through a SDIO interface, as presented in Figure 3. At the same time there is a SDRAM memory of 64Mb (ISSI IS42S16400J [6]) organized in 1,048,576 bits x 16 bits x 4 banks for get improved performance and achieve high speed data transfer. This is nececesary for a future mplementation of a real-time operating system (RTSO).

Firmware design
The software that runs within the MCU was designed with the purpose of accurately have the status of all hardware in real time. The acquisition of all internal sensors and hardware status it is done in a slot time, and another time slot for the user to implement the necessary navigation and control algorithms is left free. It was necessary to carry out a study on reducing the acquisition times of the sensors and the reading-writing times of the memory in order to allow a longer free time interval for calculations of attitude determination and stabilization of the nanosatelital platform [7,8]. The data is updated every 100ms through the implementation of a main timer (heartbeat), of which only 10 ms is used to acquire all internal sensors and memory read and write operations. A time of 90ms is free for other calculations, as shown in Figure 4. In addition, the software must monitor several peripheral channels ADC, I2C, UART and SPI and the central bus, and is responsible for all data operations on it. Due the communication peripherals requires a stable clock source on both the receiver and the transmitter side, we place an external 8MHz oscillator. A second 32.768 kHz oscillator is responsible for low frequency peripherals, including real time clock (RTC). This is important for synchronization of data and subsystems, and for some ADCS algorithms that have problems with absolute time [9]. For external supervision, the MCU has an IWDG which takes its time base from the LSI oscillator, in order to gain independence from the MCU. The internal timer of the IWDG must be reset every 4 seconds, if the waiting time is reached, the IWDG will restart the MCU and the status problem will be recovered.
An additional 32GB microSD card was installed as a redundant storage system, accessed through the SDIO interface of the MCU as shown in the schematic diagram of Figure 3.
The software is organized with different classes, one per device or sensor, this is important to maintain portability, update and compatibility with trademarks.

Subsystem interconnection
The hardware module is linked to other subsystems through a standard PC104 connector [10], each pair of rows subdivided into two connectors called H1 and H2, shown in Figure 5. The H1 and H2 connectors (Samtec ESQ-126-39-GD [11]) are responsible for maintaining mechanical compatibility and signal interconnections with all subsystems connected to the central bus, allowing access to the EPS and to the navigation and control board containing the MTQ control and to the UHF telemetry transceiver for sending data and receiving commands. This module was designed to contemplate two types of bus, one for laboratory tests and another compatible with some commercial trademarks.

Power supply
The module has access to the regulated 3.3 V of the EPS power supply through the central bus, through an independent 3.3 V regulator placed on the board, or from USB. These options can be configured with jumpers. The details is shown in the schematic of Figure 6.

Final implementation
The board was successfully designed using the Altium Designer PCB design tool. To simplify the design and avoid manufacturing problems, the PCB was developed using only two layers. The first prototype (using the STM32F429 evaluation board) is shown in Figure 7 and the final PCB design is shown in Figure 8.

RESULTS
The main features of the developed hardware have been measured, and we obtained the following results:

Timings
a.  [13]). a. Data size = 512 bytes: Average = 7ms | Tmax = 14ms (during a sector change). With this con fi guration significant latencies can occur when the MicroSD memory empties its internal buffer and changes sectors. b. Data size = 4096 bytes: Average = 18ms | Tmax = 24ms (during a sector change). Note: All time measurements were made using the Tektronix TBS1202B digital oscilloscope [14]. Time base accuracy: 50 ppm. In summary, the time available for other purposes (calculation of attitude determination, control system implementations, external sensor management, etc.) is approximately 90 ms and 70 ms during the writing periods of microSD memory. It should be noted that the number of write periods per second depends on the size of the data block. For example: in the case that the size of the data block is 512 bytes, 3 frames are required to fill the transmission buffer, which means that a write operation is performed in the SD memory every 300 ms (or 3 sampling periods), while the size of the 4 kB data block is set to 24 periods. This means that each writing period occurs every 2.4 s. The main values are shown in Table I.

CONCLUSION
This article presented the design, development and implementation of a high performance processing hardware system to be applied to nanosatelital platforms. The module uses a processor with ARM Cortex M4 architecture with an operating speed capacity of up to 180MHz. An additional visual test software was developed to monitor and detect failures of the MCU or some internal sensor. The concept of modularization and the availability of several different peripherals have made it possible to reuse and update the design in a simple way. The hardware was developed in two initial prototypes using evaluation kits before the final implementation of the system.