1 / 34

Flight Software Seyoung Yoon and Sameet Ramakrishnan Space Sciences Laboratory

Flight Software Seyoung Yoon and Sameet Ramakrishnan Space Sciences Laboratory Kyung Hee University University of California, Berkeley. FSW Agenda. Overview Seyoung’s presentation I2C module Sun-Sensor Power, Torque Coils SPI MAG Sameet’s presentation Real Time Clock

arawn
Download Presentation

Flight Software Seyoung Yoon and Sameet Ramakrishnan Space Sciences Laboratory

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  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…

  5. Background Task Table

  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

  7. Overview

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

  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[] EPS 0x2B RTC 0x68 SCL1 dsPIC I2C1 SDA1 BATT 0x2A 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

  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 T3 T1 Sensor 1 3.3 V Interval 0 V Sensor 2 Interval T2 T4 3.3 V Interval 0 V

  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 dsPIC I2C2 IIB : Instruments Interface Board IIF : Instruments Interface FPGA SCL2 SDA2 • Sequence of writing data to FPGA • 01 I2C2_TX_BUF[0] = data#1; • 02 ⁞ ⁞ • 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]; • 04 ⁞ ⁞ • 05 data#n = I2C2_RX_BUF[n-1]; • 06 else then communication has error IIF I2C

  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.

  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 DMA : Direct Memory Access

  15. FSW modules development • SPI2 Module(Cont.) SRAM DPSRAM DMA Control 0 1 2 3 4 5 6 7 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(%) : 0 - 100, address0-1) • OC4_INIT() – initialize OC4 as PWM mode dsPIC33 IIB RD3 PWM MUX Torque Coils RF0 Address 0(which coil) RF1 Address1(which Polarity) 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 EXEC IO CMD FPGA LD slowDigHSK() HSKDataBuffer[] HSK PWR ACS SUN

  18. Thank you!

  19. 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?

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

  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 .1875 second refresh rate

  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

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

  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

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

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

  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?

More Related