Flight Software Seyoung Yoon and Sameet Ramakrishnan Space Sciences Laboratory

1. Flight Software Seyoung Yoon and Sameet Ramakrishnan Space Sciences Laboratory Kyung Hee University University of California, Berkeley

2. BKG.A EXEC.A STEIN FPGA LD.A SRAM & EEPROM STEIN Elect HSK.A Analogs SPI Helium STEIN.A CMD.A STEIN Atten POWER Switches Cmds TM.A Torque Coils PWR.A COMM FPGA S-Band Tx Sun Sensors Timers ACS.A MAG FPGA MAG Elect MAG.A SDCARD SSR.A SPI SPI Simulink FSW MAJOR MODULES I II III IV Overview

3. Tasks • Two kinds of tasks • Foreground tasks (called by EXEC module) • Run asynchronously in available time • No hard limit on execution time • Configurable by ground commands • Will be frequently interrupted by Background commands, so should not rely on IO peripheral state • Attitude Control System (ACS), SRAM scan, memory peek/poke… • Background tasks (called by BKG module) • Interrupts fired at 1024 Hz • Run at specific times • Must complete before next interrupt (~9700 instructions) • Performs tasks that must occur on time • Data flow management, MAG sampling, housekeeping (analog) ADC sampling…

4. Background Task Table

5. Overview Background module completed and tested EPS module completed and tested SD card drivers in progress Drivers have since been completed, and circular buffers on SD card have been built Transmission module mostly completed “Overflow” packet handling not complete Support for Memory Dump Packets needed Error handling Testing

6. Overview

7. Real Time Clock (RTC) • Description: • Time-stamping science data • Scheduling Commanded events • Referencing ACS “ephemeris” • Set via ground command • Offset maintained for drift • Progress: • Built interface library (over I2C) • Initialize, read, start/stop, halt/unhalt • Future: • Finalize details of maintaining offset. • Potential addition of a background task to automatically correct drift?

8. Data Handling Slow Digital HSK HskDataBuff[ ] ACS HSK Module STEIN Module SD Card Transmission Module Fast Digital HSK SteinDataBuff[ ] MagDataBuff[ ] EPS Analog HSK MAG Module

9. Housekeeping Overview • Schedules sampling of analog inputs, EPS values, state of software and peripherals • Sample rate 16Hz • Packet refresh rate 10 seconds • Timestamps and packetizes information for downlink • During orbit, the blocks are stored onto the SD card • During downlink period, the blocks are directly down-linked at next available opportunity • New “recent” block sent approximately every 10 seconds • Maintains updated record of EPS solar currents for ACS • Sample rate 32 Hz, 6 values so .1875 second refresh rate

10. Housekeeping Packet Format • First 80 bytes “slow digital housekeeping” • Timestamp + General program state • Actuators Status • Power Status • ACS/Sun Sensor? • MAG Housekeeping, STEIN housekeeping • 7 repeated blocks of 60 bytes each • Updated ~2 second rate • limited by sampling all EPS values) • Analog Housekeeping from EPS • Analog inputs into microcontroller • Fast Digital Housekeeping • Torque coils status, Spin Rate, Elevation from ACS • SSR state

11. Housekeeping Status • Progress: • Sampling analog inputs, retrieving EPS, framework for retrieving digital value completed • ACS solar current refreshing completed • Packetization completed (for now…) • Future: • CTM finalization*! • Digital values filled into framework as they become available • Action/Error log (maybe not here) • Overflow packets? • I2C error handling, testing

12. Housekeeping Verification • Demonstration later in the week?

13. Command Module Description • DMAs uplinked commands from radio into PIC’s DMA RAM • Serial UART2 -> DMA RAM • By comparing uplink rate against CMD module interrupt rate, we can calculate necessary DMA buffer size (~75 bytes) • Sorts commands from DMA RAM into 1 of 2 lists in non DMA RAM: immediate command list or delayed command table • Delayed Commands buffered for the duration of the orbit • Immediate Commands received and handled “immediately” • Initiate downlink, request packet, mode switches, etc. • Provides functions for EXEC to access these lists

14. Command Progress • Immediate Command handling completed • Implemented as a circular buffer data structure • Delayed Commands currently handled as “table” • Delayed Packet with entries of 6 bytes • Maintains a 4 byte “time field” and a 2 byte “command field” • Table “halted”, reloaded, restarted • Originally linked list • Lots of space overhead for the flexibility of inserting commands in correct temporal location • Does not seem necessary/consistent with table structure/large one shot packet uploads • Limits number of commands total that can be stored, adds software execution time overhead • Sorting more of a ground task anyways? • These decisions must still be made

15. Command Module Verification

16. Command Future/Problems • Command uplink format finalization • How many commands? Space on dsPIC? Sorted? • Delayed Command Table manipulation post uplink • Deletion • Insertion? Modification? • Verification/error checking of uplinked commands • CRC verification scheme needed? • Redundancy? • General error handling needed • Needs testing under larger data rates

17. STEIN Module Description • Single point of entry for SSR writes • Scheduled frequently enough that this makes sense • May “absorb” other modules with busy times • HSK, MAG blocks • Error handling from a single place • Retrieve, timestamp, packetize STEIN data from FPGA • Force packet writes at minimum every 1 second • Hardware timestamp rollover

18. STEIN progress • Able to write blocks (STEIN, MAG, HSK) to SD card • Primitive scheduling system • Error handling/reset sequence completed • Hard/Soft Reset • Retrieval and Packetization of Stein data completed • Refer to CTM for Stein packet format • One second force needs “hardware support”

19. STEIN Module Future • Handle potential changes in software requirements from instrument side • Currently just assumes arbitrary 32 bit values, doesn’t parse data at all • Change in STEIN packet format, some status bytes/meta data needed? • Needs testing with FPGA, STEIN hardware • Ensure Stein packet format is acceptable

20. Magnetometer Description • Description • Interacts with MAG through I2C interface to FPGA • Initializes hardware • Schedules and commands sampling (based on mode) • Baseline of 64Hz, divided down for slower sampling • Controls mode switching/power settings • Via ground command • Packetizes data • Repeat of status byte, 4 24 bit vectors (1 for each axis and OB temperature) • Inboard temperature replacement • Maintains shared values for ACS • CPD for full details on all the nuances • Progress • Done “in theory”, but needs testing with real hardware

21. Conclusion and Future Tasks • Review and finalization of the CTM • Will allow finalization of the Housekeeping, Command, Transmission modules • Tying modules together • Implementation of the EXEC module/command parsing • Testing modules together, and with GSEOS • Verification of software with hardware • IIB, MAG and eventually STEIN • Integration of ACS code with FSW • Load Module