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

2. Seyoung’s presentation
FSW Agenda
Overview
Seyoung’s presentation
I2C module
Sun-Sensor
Power, Torque Coils
SPI
MAG
Sameet’s presentation
Real Time Clock
Command and Data handling
Housekeeping module
Command module
STEIN module
MAG module
Future Goals

3. Overview FSW MAJOR MODULES I II IV III
Helium
Cmds
Analogs I II IV
III
Simulink
PWR.A
ACS.A
Sun
Sensors
Torque
Coils
STEIN
Atten
MAG
Elect
MAG.A
STEIN.A
SPI
S-Band Tx
TM.A
SDCARD
FPGA
POWER
Switches
Timers
BKG.A
EXEC.A
SSR.A
LD.A
CMD.A
SRAM &
EEPROM
HSK.A
COMM
FSW MAJOR MODULES
Logic and Data flow chart for Flight Software.
Commands come in through command, parsed by exec. BKG calls scheduled tasks/drivers.
These write their respective packets to the SD card via SSR module, TM will pull these from the SD card and downlink them.

4. 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

5. Background Task Table
HSK
STE TX
MAG
CMD

6. 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
After this slide, Seyoung will present 6

7. Overview This block diagram is for early FSW.
I’m participating in these modules.
Most of the modules are done. Several modules remained to test.

8. I2C1 - General read, write module EPS Sun-sensor Power
Overview
I2C1 - General read, write module
EPS
Sun-sensor
Power
SPI2 – between dsPIC and IIF for STEIN
Torque Coils
I2C2 – between dsPIC and IIF for MAGIC
HSK
MAGIC
I’ll skip several modules.
EPS module was presented last week by Nestor.
And I have already presented this module in Feb. CDR.
If you want to get EPS information, you can find it in Nestor’s CPD and my CDR presentation. These documents are on Knowledge tree.
And also, I’ll skip HSK module. This module is presented by Sameet.

9. FSW modules development
I2C Module
Hardware : I2C1, Software : I2C
Description : General function for reading and writing
I2C1_INIT()
I2C1_READ(slave address, number of bytes)
Data is saved in I2C1_RX_BUF[]
I2C1_WRITE(slave address, number of bytes)
Data is sent from I2C1_TX_BUF[]
First module is for I2C. (I2C is serial communication protocol which is used in many microprocessors)
Actually, I2C module includes functions for I2C1, I2C2 and RTC.
(The dsPIC has two I2C. RTC module is using the I2C1)
But, I’ll talk about each of them because each module operates differently in function.
So..First, I2C1 includes general functions for reading and writing.
ClydeSpace EPS, Battery and Real Time Clock module are connected to I2C1.
AS we use these functions, we can control devices such as like EPS, BATTERY and RTC.
dsPIC
I2C1
SCL1
SDA1
EPS
0x2B
BATT
0x2A
RTC
0x68
EPS : Electrical Power System
RTC : Real Time to Clock

10. FSW modules development
EPS Module
(You can see Seyoung’s CDR presentation)
Hardware : EPS, BATT, I2C1
Software : EPS, I2C
Description : This module is called by HSK module for ACS and Housekeeping.
EPS_INIT() – Variables and I2C1 initialization
EPS_READ_HSK() – be not used any more
EPS_CMD() - shall be called to command to EPS and BATT
EPS_I2C_REQ() – request a sample to EPS or BATT
EPS_I2C_READ() – read a sample from EPS or BATT
As I said, I’ll skip this.

11. FSW modules development
Sun-sensor Module(SUN.c, SUN.h)
Hardware : Sun-sensors, Timer(2, 3), Input Capture(1,5)
Description :
SUN_INIT() – Timers and Input Captures initialization
SUN_INTERVAL() – Update sun-azimuth, sun-elevation, spin period and interval time between left-sunsensor and right-sunsensor. If data is updated, the function returns 1.
SUN_INTERVAL() function is called each time in 0.419sec
Rising Edge Detecting
3.3 V
0 V
Interval
Sensor 1
Sensor 2 T1 T2 T3 T4
The sun-sensor module consists of two functions.
SUN_INIT() function performs initialization for timers and Input captures.
SUN_INTERVAL() function returns sun-azimuth, elevation and period.
Below right expressions are from Karla verga’s thesis. We can calculate the values using these equations.
And this function is called every about 0.419sec or less than.
It’s not using interrupt, so we have to make it update values.
Look at the below left figure. Current software is detecting only rising edge.
If detecting only one edge creates some problem in ACS, I need to change the software.
As current module is not using interrupts, sun-sensor module becomes more complicated if I change the software to detect middle of signal.
So, I hope it’s not changed as far as possible.

12. FSW modules development
I2C2 Module
Hardware : IIB, I2C2
Description :
I2C2_INIT() – initialize I2C2 as Master mode
writeI2C_FPGA(register address, num of data)
readI2C_FPGA(register address, num of data)
Pseudo code
IIB : Instruments Interface Board
IIF : Instruments Interface FPGA
dsPIC
I2C2
SCL2
SDA2
IIF I2C
Sequence of writing data to FPGA
01 I2C2_TX_BUF[0] = data#1;
⁞ ⁞
03 I2C2_TX_BUF[n-1] = data#n;
04 error_check = writeI2C_FPGA(register address, num of data);
05 if error_check = 1 then normal
06 else then communication has error
Sequence of writing data to FPGA
01 error_check = readI2C_FPGA(register address, num of data);
02 if error_check = 1 then
03 data#1 = I2C2_RX_BUF[0];
⁞ ⁞
05 data#n = I2C2_RX_BUF[n-1];
06 else then communication has error
I2C2 is connected only to the FPGA on the IIB.
This module is called to control IIB.
Type the register address and number of data, and then the module communicates with FPGA until all data is moved.

13. FSW modules development
Power Module
Hardware : I2C2, IIB, IO(RE6, RE7)
Software : I2C, PWR
Description :
Switch STEIN High Voltage Supply – turn STEIN High voltage supply on or off as writing command to IIF’s register using I2C2.
Switch power to IIB – turn IIB on or off through IO pin(RE7).
Check Over-current on IIB
check over-current on IIB using IO pin(RE6).
If occurred over-current, returns 0. If not, returns 1.
Deploy UHF antennae(not programmed yet)
Using Countdown timer.
Need to determine condition to start timer.
Power module is almost done except function to deploy UHF antennae.
This module includes 4 functions, now.
The one is to switch STEIN high voltage supply and power to IIB.
Other one is to check over-current on IIB. This functions can be designed using FPGA register.
But, I am just using a IO pin, because reading IO pin is more simple than reading FPGA register.
(Over-current indicator is also connected to dsPIC’s IO pin.)
And the other one is funtction to deploy UHF antennae. This function is not programmed yet.
Maybe, it shall be using timer.
But Sameet and me, we don’t know when this timer start and also we don’t know this timer has how much time.
It depends on operation sequence.

14. FSW modules development
SPI2 Module
Hardware : SPI2, DMA3, DMA4, IIB, SD Card
Software : SPI2, SSR
Description
Initialization SPI2 and DMA channels
cfgSPI2(), cfgDMA3(), cfgDMA4()
DMA3 as Transmission channel, DMA4 as Reception channel.
Saving STEIN data into shared memory buffer.
readSTEIN()
Receive STEIN data from IIF through SPI2, and Send null data.
Save received data into steinDMABuffer[]
Writing data for transmission to IIF from SD Card.
writeTLM()
Write transmission data into IIF buffer from SD Card.
Checking DMA3,4 busy status
SPI is serial communication protocol such as I2C.
Although this protocol doesn’t support BUS mode, bit rate is very faster than I2C.
SPI1 is used to communicate with SD card.
SPI2 module has three functions.
First is saving STEIN data into shared memory buffer.
Data in shared memory is saved into SD Card by another SPI.
Second function is writing data to FPGA’s register from SD Card.
Transmitted data is for transmission to GroundStation.
Last function is to check DMA’s status.
DMA is device for automatically communication between peripheral devices.
If request for SPI communication is called when DMA is being used, transmission data may be crashed.
So we can prevent this situation by using checking function.
DMA : Direct Memory Access

15. FSW modules development
SPI2 Module(Cont.)
SRAM
DPSRAM
DMA
Control 1 2 3 4 5 6 7
This diagram is showing how to be connected using DMA.
But, to explain this diagram is not important. I’ll skip.
(If saving STEIN data function is called, FPGA is ) SAMEET: This sentence is a little unclear?
CPU
FPGA
SD Card
DPSRAM : Dual Port SRAM

16. FSW modules development
Torque Coils Module
Hardware : IIB, Torque Coils, Timer2, Output Compare4
Description : This module is called by ACS to control torque coil.
TCM() – Three parameters (duty rate(%) : , address0-1)
OC4_INIT() – initialize OC4 as PWM mode
Address 0(which coil)
Address1(which Polarity)
RD3
RF0
RF1
dsPIC33
IIB
PWM
MUX
Torque Coils
Torque coils module is called by ACS module to control magnetic torque coils.
Torque coil control function has three parameters.
Duty rate is constant to determine that the module makes how much positive signal. It’s generally expressed as a percentage.
Address0 is for selecting the axis of the coil.
Address1 determines the current direction in the torque coil.
PWM : Pulse Width Modulation

17. FSW modules development
Housekeeping Module
(You can see more detail in Sameet’s presentation.)
Hardware : IIB, I2C2
Software : HSK
Description : Save slow housekeeping data into housekeeping buffers.
slowDigHSK()
Slow housekeeping data is defined in APID264 of CTM.xlsx
As I said when start presentation, I’ll skip this module.
In brief, I made a processing function for slow digital housekeeping data such as operating mode and devices status.
slowDigHSK function collects data from the other modules and save the data into Housekeeping Data buffer.
EXEC IO
CMD
FPGA LD
slowDigHSK()
HSKDataBuffer[]
HSK
PWR
ACS
SUN

18. Thank you!

19. Real Time Clock (RTC) Description: Progress: Future:
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?
Don’t spend too much time on the Real-Time Clock, as its not particularly interesting

20. Data Handling ACS STEIN SD HSK Module Module Card EPS MAG Module Slow
Digital
HSK
HskDataBuff[ ]
ACS
HSK Module
STEIN
Module SD
Card
Transmission
Module
Fast
Digital
HSK
SteinDataBuff[ ]
MagDataBuff[ ]
Rest of the presentation is about handling collecting data. Fleshed out more later in the presentation, but the idea is that each module collects its own 512 byte blocks, and buffers them on independent buffer on the SD card. The Telemetry module will be in charge of scheduling/selecting which packet to downlink.
Thanks to Seo for color coordination
EPS
Analog
HSK
MAG
Module

21. 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 second refresh rate
(16 Hz means that every 16 Hz, the next value is taken from the EPS board value, and the next Slow Housekeeping value is retrieved)
When a full 512 blocks is completed, its either stored on the SD card or directly downlinked at the next available opportunity . This occurs approximately every 10 seconds.

22. 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
CTM, be very brief about this.

23. Housekeeping Status Progress: Future:
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

24. Housekeeping Verification
Demonstration later in the week?

25. 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
Discuss what DMA means; Commands will just be transferred into memory from the Radio by hardware on the flight board without the CPU having to intervene. Every now and then we check up on the commands, parse them, and distribute them.
Parsing/distributing : commands sent to one of two lists, immediate or delayed table.

26. Originally linked list
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
Basically if anyone knowledgeable is there, hope to get some input regarding this linked list vs table structure

27. Command Module Verification

28. 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

29. 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

30. Able to write blocks (STEIN, MAG, HSK) to SD card
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”

31. Handle potential changes in software requirements from instrument side
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

32. Magnetometer 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
DOUBLE CHECK THIS INBOARD/OUTBOARD REPLACEMENT BUSINESS

33. 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

34. Questions or Comments?