Problem Statement

The cube satellite requires a central control system which can process and relay information between subsystems for safety and survival of the cube satellite, as well as to achieve the cube satellite’s research purpose which is to communicate image and location data to the ground station. The preliminary hardware components chosen by the other subsystems are made by different manufacturers and use different hardware communication protocols which have different data rates and interrupts. An appropriate command and data handling (CD&H) board must be chosen which can handle the different types of serial data. The embedded operating system must react to interrupts given by the other subsystems by processing serial data and relaying relevant information to other subsystems.

Current Status

Onboard computing

The initial flight software was built using the STM32Cube IDE, along with the FreeRTOS and FatFS middleware, for the Nucleo F429ZI board (ARM Cortex-M4). Additionally, a substitute camera and mock EPS module were created to further simulate the full hardware system.

The flight software runs multiple tasks using FreeRTOS, namely:

• Querying of sensors and subsystems for data
• Writing data to SD card
• Passive and scheduled rotation modes (ADCS algorithms not implemented)
• Scheduled image captures
• Various commands
• Logging of events
• Packetizing/transmitting data

Final hardware: Endurosat OBC

Prototyping hardware: NUCLEO-F429ZI

Development IDE: STM32Cube IDE

Bootloader

A preliminary bootloader has also been created in order to verify what functionality can be achieved before designing the final version of the bootloader. Currently, the preliminary bootloader features:

• Memory partitioned into bootloader and application
• RAM memory partitioned to include SRAM (save data between restarts, e.g. count number of restarts and determine what to do based on that)
• Jumping to application software that was flashed in by the IDE
• Reading a binary file stored on an SD card
• Erasing the onboard flash memory and flashing in a new binary file
• Ability to further partition the flash memory (recovery partition?)

Bootloader Philisophy:

• Bootloader must be able to load the appropriate program image into the program memory
• Bootloader must be able to check integrity of program memory as well as RAM
• Bootloader must be able to recover from software faults
• Bootloader must be able to communicate with the ground station to receive updated program image packets
• Bootloader must be able to assess the integrity of each packet before writing them into the flash memory
• Bootloader must be able to assess the integrity of the whole program image
• Bootloader must be able to write the program image into the program memory
• Bootloader must be able to jump into the program memory to begin operations

Flight Software Tester

Using a development board, a flight software tester will be developed to simulate the outputs of other subsystems. Through these simulations, the behaviour and responses of the flight software could be monitored and modified accordingly. The Flight Software Tester is still under development.

Current Challenges

Flight software:

• Integration with bootloader
• Adaptation to interface with ground station (changes to command format, implementation to return status codes on commands)
• Implementation of new communication process for downloading files (e.g. re-transmission of corrupted packets)
• Implementation of ability to upload a new binary file to the CubeSat
• Eventual integration of interfacing with the actual hardware
• Command to restart the Cubesat, e.g. software patch (must properly reset all board peripherals and hardware to a known state for the bootloader/software)

Bootloader:

• Figure out implementation of the rest of the basic functionality (e.g. jump to application flashed from SD card, currently has issues)
• Create minimized code needed to achieve the individual basic functions that will be used by the actual bootloader
• Devise an overall process for how a software patch should be applied to the CubeSat (file transfer, command behaviour, backups, etc.)
• Create and implement final design of the bootloader