CubeComputer V4.1. General purpose on-board computer. Datasheet

Transcription

1 CubeComputer V4.1 General purpose on-board computer Datasheet

2 Page: 2 Table of Contents 1. System Summary Application Compatibility Heritage Features Functional Description System Overview Microcontroller Memory Communication Customisation Electrical Characteristics Waveforms Error detection and correction SRAM latch-up response Connector Details FPGA programming header MCU header Debug UART header Watchdog enable header Backup power domain header Piggyback header MicroSD card holder Main PC104 header Communication Debug UART Miscellaneous UART System I 2 C Secondary I 2 C SPI CAN Physical Specifications Mass Dimensions Additional mounting holes Header and component height... 25

3 Page: 3 8. Environmental Tests Vibration test Heated vacuum test Radiation test Document Version History List of Acronyms/Abbreviations A2D ADC ADCS C&DH EBI EDAC EEPROM EPS FPGA GPIO I 2 C MCU OBC PCB RTC SEL SEU SPI SRAM SWD TID TT&C UART WDGEn Analog-to-Digital Analog-to-Digital Converter Attitude and Determination Control System Command and Data Handling External Bus Interface Error Detection And Correction Electrically Erasable Programmable Read-Only Memory External Power System Field Programmable Gate Array General Purpose Input/Output Inter-Integrated-Circuit Microcontroller Unit On-board Computer Printed Circuit Board Real-Time Clock Single Event Latch-up Single Event Upset Serial Peripheral Interface Static Random Access Memory Serial Wire Debug Total Ionising Dose Telemetry, Tracking, and Command Universal Asynchronous Receiver/Transmitter Watchdog Enable

4 Page: 4 1. System Summary 1.1 Application General purpose on-board computer (OBC) for nanosatellites Low power consumption, radiation tolerant, and robust Suitable for ADCS, C&DH, TT&C, mass storage, and payload management 1.2 Compatibility CubeSat standard, compatible with ISIS, ClydeSpace, and GomSpace products Compatible and easily integrates with all other CubeSpace products 1.3 Heritage Design based on knowledge and technology from SUNSAT and SumbandilaSat Used as ADCS OBC on QB50 precursor satellites and DeorbitSail More than 30 CubeComputer units to be launched on various satellites by Features Microcontroller High performance, low power 32-bit ARM Cortex-M3 based MCU DMIPS/MHz Internal and external watchdog for added reliability Memory & Storage 32 KB EEPROM 4 MB flash for code storage 1 MB external SRAM for data storage Single Event Upset (SEU) protection through FPGA based flow-through EDAC Single Event Latch-up (SEL) protection by detecting and isolating latch up currents MicroSD socket for storage up to 2 GB Communication 2 x I 2 C interface with multi-master capabilities 1 x CAN interface capable of standard and extended data and remote frames Customisation Piggyback header allows for mission specific expansion boards Header includes 3.3 V, 5 V, V battery, I 2 C, UART, SPI, ADC, PWM, and GPIO interfaces

5 Page: 5 2. Functional Description 2.1 System Overview CubeComputer is a general purpose OBC for nanosatellites. It is designed to be fully compatible with the CubeSat standard and CubeSat products from ISIS, Pumpkin, ClydeSpace, and GomSpace. CubeComputer can also easily integrate with all CubeSpace products. The OBC is built around an ARM Cortex-M3 based MCU which delivers high performance at very low power. To protect the OBC against radiation effects such as SEUs and SELs, fault tolerance techniques (such as error detection and correction, or EDAC) have been implemented for increased reliability. Figure 1 shows a simplified block diagram of CubeComputer. Figure 1 CubeComputer block diagram

6 Page: Microcontroller CubeComputer uses an EFM32GG280F1024 MCU from Silicon Labs. The MCU is based on the 32-bit ARM Cortex-M3 architecture and operates at 4-48 MHz, delivering 1.25 DMIPS/MHz. The MCU is also optimised towards efficiency and therefore has a very small power consumption footprint of 200 μa/mhz when executing from flash and 0.9 μa when running in deep sleep mode. The MCU includes all the required on-chip peripherals for a nanosatellite OBC: real-time clock (RTC), timers, analog-to-digital converter (ADC), external memory interface, UART, SPI, and I 2 C. To safeguard the MCU against software and hardware lock-ups, both an internal and an external watchdog are implemented. In the event that the lock-up is caused by a radiation induced latch-up within the MCU, a normal reset will not recover the MCU. Therefore, the external watchdog will power cycle the OBC in order to remove the latch-up. 2.3 Memory CubeComputer has an extensive memory subsystem which includes EEPROM, flash, SRAM and optional microsd card storage. 32 KB of external EEPROM is used to store critical code applications, such as a safe mode operating program, due to its resistance against radiation effects or accidental software writes. 4 MB of external FLASH is available for additional code storage. 2 1 MB of SRAM is included for data storage by the operating application. A microsd card slot is optionally available which allow for up to 2 GB of general purpose storage. Since SRAM is especially vulnerable against the effects of radiation, such as SEUs and SELs, it is implemented externally (from the MCU) in order to effectively mitigate these single event effects. A flow through EDAC is implemented on the external bus interface, between the SRAM and the MCU, to detect up to 6 and correct up to 2 bit-flips per byte. The SRAM supply current is constantly monitored to quickly detect an SEL and correct it by power cycling the component. If it cannot be recovered, the SRAM is isolated from the bus. The redundant SRAM configuration ensures that no data is lost when one of the SRAM modules is power cycled or isolated. 2.4 Communication CubeComputer provides all the needed interfaces to communicate with other subsystems in the satellite. The OBC provides two I 2 C channels, where one is used to interface with the main I 2 C bus on the PC104 bus, either as a slave or master, and another can be used to communicate with a separate slave device(s) and/or subsystems. A CAN bus is also available for high speed and high reliability communication on the main PC104 header. An SPI bus is also available on the piggyback header.

7 Page: Customisation The CubeComputer includes a separate piggyback header which can be used to interface directly with mission specific expansion boards. Various interfaces (I 2 C, UART, and SPI) and functionality pins (PWM, ADC, and GPIO) have been routed to the piggyback header which can be accessed directly by the MCU. The piggyback header also has access to the full range of power supply voltages: raw battery bus voltage (V battery ), 5 V and 3.3 V. Examples of typical expansion board applications include an attitude and control subsystem (ADCS) and/or payload interface. Several of the MCU pins available on the piggyback header can also be routed to various pins on the main PC104 header. Refer to Section 5.8 for more information regarding the pin layout of the PC104 header.

8 Page: 8 3. Electrical Characteristics Table 1 CubeComputer electrical characteristics Symbol Parameter Min Nom Max Unit V CC Supply voltage V V R Reset threshold 2.93 V f Clock frequency 4 48 MHz T A Operating temperature C 1 I O Supply current: MCU 2 Fibonacci 39 / 23 while(1) 35 / 22 Stop Mode 24 / 19 Sleep Mode 23 / 19 Supply current: Peripherals 3 UART +6 ma CAN ADC +4 EEPROM Flash SRAM microsd V I2C I 2 C voltage levels / 5 V R I2C I 2 C bitrate kbps V UART UART voltage levels 3.3 V VCC = 3.3V, T A = 25 C 48 MHz external crystal oscillator (first measurement) / 14 MHz internal RC oscillator (second measurement) 3 Current consumption on top of Stop Mode current while being used

9 Page: 9 4. Waveforms 4.1 Error detection and correction Figure 2 to Figure 5 shows simulated waveforms for the flow through EDAC implemented in the FPGA. The EDAC has the capability to detect and correct up to two errors per byte. Three error bit signals are output by the FPGA if an error has been detected, which will generate an interrupt on the MCU. Table 2 provides the interpretation of the error signals. Table 2 Error signal description Errors [0:2] Description 000 No errors 100 Single error 010 Double error 001 Multiple errors Figure 2 EDAC encoding and decoding with no errors Figure 3 EDAC encoding and decoding with single error

10 Page: 10 Figure 4 EDAC encoding and decoding with double error Figure 5 EDAC encoding and decoding with multiple errors 4.2 SRAM latch-up response Figure 6 to Figure 8 shows measured latch-up response waveforms of the supply current for the CubeComputer SRAM modules. During normal operation the latch-up can be detected and the module disabled within 20 µs (Figure 6). In most cases a power cycle should be enough to remove the latch. In order to avoid false positive latch-up detection due to inrush currents (Figure 7), a blanking period is given before latch-up detection is enabled. Figure 8 shows a latch-up response (which occurs after the blanket period) when an SRAM module is enabled. Figure 6 Supply current latch-up response during normal SRAM operation

11 Page: 11 Figure 7 Inrush current when SRAM is enabled Figure 8 Supply current latch-up response when SRAM is enabled

12 Page: Connector Details Figure 9 shows the top view of the CubeComputer PCB layout, with the connectors indicated in red. Pin 1 of each header is marked in green. This section will be dedicated to the detailed description of each connector shown in Figure 9. Figure 9 CubeComputer V4.1 top view Figure 10 shows the bottom view of the CubeComputer PCB layout, with the piggyback header indicated in red.

13 Page: 13 Figure 10 CubeComputer V4.1 bottom view

14 Page: FPGA programming header The FPGA is programmed during assembly and does not need to be programmed again. The FPGA header (number 1 in Figure 9) shown in Figure 11 is the highest of the CubeComputer connectors (except for the PC104 header) and can be removed before shipment if required. Figure 11 FPGA programming header 5.2 MCU header The 6-way MCU header (number 2 in Figure 9) shown in Figure 12 contains the required Serial Wire Debug (SWD) pins to program and debug the EFM32GG280F1024 MCU. Figure 12 MCU header This 2 mm pitch, right angle, female header can be populated on the top or the bottom of the PCB. Table 3 gives the pin definition of the MCU header. Table 3 MCU header pin definition Pin Description Connected to V PCB 3.3 V power 2 DBG_SWDIO MCU pin 77 (PF1) 3 DBG_SWCLK MCU pin 76 (PF0) 4 GND PCB ground 5 DBG_SWO MCU pin 78 (PF2) 6 nreset MCU pin 36, (RESETn)

15 Page: Debug UART header The Debug UART header (number 3 in Figure 9) allows CubeComputer to easily interface with a computer using the appropriate software and a UART-to-USB cable. The MCU s UART 1 (or U1) module is used as the Debug UART. The header is a 2.54 mm pitch, right angle, female header, as shown in Figure 13. The TX and RX pins are connected to the MCU through a buffer to protect the MCU from being back powered by the computer s UART transmit line when connected. Figure 13 Debug UART header Table 4 shows how the UART pins are connected to the MCU and the PC104 header. Table 4 Debug UART connections Pin Description Connected to 1 GND PCB ground 2 Debug UART RX MCU pin 38 (PB10; U1 RX) via buffer H1-17,18,19,20 (optional via link resistor) H2-21,22 (optional via link resistor) 3 Debug UART TX MCU pin 37 (PB9; U1 TX) via buffer H1-17,18,19,20 (optional via link resistor) H2-21,22 (optional via link resistor) 5.4 Watchdog enable header The watchdog enable (WDGEn) header (number 4 in Figure 9) can be used to permanently enable the external watchdog by placing a jumper over the header pins, as shown in Figure 14. The external watchdog can also be activated in software. The header (2 mm pitch, right angle, male) can be populated on the top or the bottom of the PCB. If a jumper is placed over the WDGEn header and the external watchdog is activated, debugging the MCU will not be possible. The application needs to trigger the watchdog to keep it from resetting the MCU. If the running application is halted during debugging, the watchdog will time out and power cycle the MCU.

16 Page: 16 The watchdog can also be permanently enabled before launch by soldering one of two link resistors (R501 on the top, as can be seen in Figure 14, or R503 on the bottom) found near the header. Populating one of these link resistors will have exactly the same effect as placing a jumper over the WDGEn header. Figure 14 Watchdog enable header and link resistor (top) 5.5 Backup power domain header The backup power domain header (number 5 in Figure 9), or the BU_VIN header, gives access to the power supply of the MCU s backup power domain. One pin is connected to the BUVIN pin on the MCU (PD8, pin 54) and the other pin is connected to ground. If this pin is not used to supply power to the backup power domain, it can be reconfigured to be used as a GPIO pin. For more information on the backup power domain, the backup RTC, and further uses of pin 54, refer to the MCU s datasheet and to the Silicon Labs application note AN0041 Backup Power Domain. The 2-way Molex PicoBlade (1.27 mm pitch, right angle) male header, shown in Figure 15, can be populated on the top or the bottom of the PCB. The BUVIN of the MCU can furthermore be connected to the always on 3.3 V power supply (H2-27,28) or H2-42 on the PC104 header if required. Figure 15 Backup power domain header (top) Table 5 gives the pin definition of the backup power domain header. Table 5 Backup power domain header pin definition Pin Description Connected to 1 BU_VIN MCU pin 54 (PD8) 2 GND PCB ground

17 Page: Piggyback header The piggyback header (number 6 in Figure 9) shown in Figure 16 can be populated with the Samtec ERF S-DV header on both the top and the bottom of the PCB. The mating male connector for this piggyback header is from Samtec s ERM8 series and is available in a number of different height configurations. Figure 16 shows the piggyback header populated on top of the PCB. Figure 16 Piggyback header (top) The pin definition of the piggyback header is given in Table 6. Table 6 Piggyback header pin definition Header pin MCU pin Signal Description 1,2 - V battery Battery supply from main header 3,4-5V SW1 Connected to H1-51 5,6-5V SW2 Connected to H1-49 7,8-5V SW3 Connected to H1-47 9,10-5V MH Connected to H2-25,26 11,12-3V3 SW1 Connected to H ,14-3V3 SW2 Connected to H ,16-3V3 SW3 Connected to H ,18-3V3 MH Connected to H2-27,28 19 PF7 UART0 RX Misc. UART (U0) RX (buffered) 21 PF6 UART0 TX Misc. UART (U0) TX (buffered) 20 PC5 I2C1 SCL Secondary I 2 C clock (buffered, pull-up resistor) 22 PC4 I2C1 SDA Secondary I 2 C data (buffered, pull-up resistor) 23 PE7 SPI MOSI SPI master-out-slave-in data 25 PE6 SPI MISO SPI master-in-slave-out data 27 PE5 SPI CLK SPI clock 29 PE4 SPI CS SPI chip select 24 PA8 GPIO/PWM GPIO/PWM (TIM2_CC0 #0) 26 PA9 GPIO/PWM GPIO/PWM (TIM2_CC1 #0) 28 PA10 GPIO/PWM GPIO/PWM (TIM2_CC2 #0) 30 PA13 GPIO/PWM GPIO/PWM (TIM2_CC1 #1) 31 PB12 GPIO GPIO 32 PA12 GPIO/PWM GPIO/PWM (TIM2_CC0 #1) 33 PB11 GPIO/PWM GPIO/PWM (TIM1_CC2 #3) 34 PA11 GPIO GPIO 35 PD8 BU_VIN Backup power domain power supply (see Section 5.5)

18 Page: NC Not connected 37 PF8 GPIO/PWM GPIO/PWM (TIM0_CC2 #2) 38 - NC Not connected 39 PC10 GPIO/PWM GPIO/PWM (TIM2_CC2 #2) 40 PA7 GPIO GPIO 41 PC3 GPIO General purpose input/output 42 PA14 GPIO/PWM GPIO/PWM (TIM2_CC2 #1) 43 PC9 GPIO/PWM GPIO/PWM (TIM2_CC1 #2) 44 - GND Ground 45 PD7 GPIO/ADC GPIO/ADC (12-bit) 46 PD4 GPIO/ADC GPIO/ADC (12-bit) 47 PD6 GPIO/ADC GPIO/ADC (12-bit) 48 PD5 GPIO/ADC GPIO/ADC (12-bit) 49,50 - GND Ground 51,53,55, 57,59 - NC Not connected 52 - CAN_H CAN High (termination resistor R610, default 120Ω) 54 - CAN_L CAN Low (termination resistor R610, default 120Ω) 56 - GND Ground 58 - I2C0 CLK System I 2 C clock (buffered, pull-up resistor) 60 - I2C0 DA System I 2 C data (buffered, pull-up resistor)

19 Page: MicroSD card holder The microsd card holder (number 7 in Figure 9), shown in Figure 17, is sourced from Molex (part number: ). Figure 17 MicroSD card holder 5.8 Main PC104 header The main PC104 header (number 8 in Figure 9) fully conforms to the CubeSat standard. The header pins are shown in the Table 7 and each header pin is described in Table 8 and Table 9. The user can select form a variety of headers to populate on the PCB. This selection is available in the CubeComputer V4.1 Option Sheet. The user can also select to connect or not certain pins. The pin connections are made by selecting the appropriate configuration in the options sheet. Table 7 Main PC104 header H2 H Table 8 H1 (PC104) pin definition Header pin MCU pin Signal Description CAN Low (termination resistor R610, default 120Ω) CAN High (termination resistor R610, default 120Ω) 2 PA13 (34) GPIO GPIO 4 PB12 (40) GPIO GPIO 5 PA11 (30) GPIO GPIO 6 PB11 (39) GPIO GPIO 7 PA14 (35) GPIO GPIO 8 PA12 (33) GPIO GPIO

20 Page: 20 9 PC3 (21) GPIO GPIO 10 PA7 (26) GPIO GPIO 11 PC9 (69) GPIO GPIO 13 PD4 (50) GPIO/ADC GPIO/ADC (12-bit) 14 PD5 (51) GPIO/ADC GPIO/ADC (12-bit) 15 PD6 (52) GPIO/ADC GPIO/ADC (12-bit) 16 PD7 (53) GPIO/ADC GPIO/ADC (12-bit) 17,18,19,20 PB9 (37) UART1 TX Debug UART (U1) TX (buffered, configurable) PB10 (38) UART1 RX Debug UART (U1) RX (buffered, configurable) 21 PC5 (23) I2C1 SCL Secondary I 2 C clock (buffered, pull-up resistor) 23 PC4 (22) I2C1 SDA Secondary I 2 C data (buffered, pull-up resistor) 29 PE5 (65) SPI CLK SPI clock 30,31 PE6 (66) SPI MISO SPI master-in-slave-out data PE7 (67) SPI MOSI SPI master-out-slave-in data 32 PE4 (64) SPI CS SPI chip select 39,40 PF6 (84) UART0 TX Misc. UART (U0) TX (buffered, configurable) PF7 (85) UART0 RX Misc. UART (U0) RX (buffered, configurable) 41 PC6 (55) I2C0 SDA Main (System) I 2 C data (buffered, pull-up resistor) 43 PC7 (56) I2C0 SCL Main (System) I 2 C clock (buffered, pull-up resistor) 47,49,51-5V_SW1,2,3 5 V power supplies from EPS 48,50,52-3V3_SW1,2,3 Switched 3.3 V power supplies from EPS Table 9 H2 (PC104) pin definition Header pin MCU pin Signal Description 15 PA7 (56) GPIO GPIO 17 PB11 (39) GPIO GPIO 18 PA12 (33) GPIO GPIO 19 PB12 (40) GPIO GPIO 20 PA13 (34) GPIO GPIO 21,22 PB9 (37) UART1 TX Debug UART (U1) TX (buffered, configurable) PB10 (38) UART1 RX Debug UART (U1) RX (buffered, configurable) 25,26-5V Main 5 V supply from EPS 27,28-3V3 Main 3.3 V supply from EPS 29,30,32 - GND Ground 42 PD8 (54) BU_VIN Backup power domain power supply (see Section 5.5) 45,46 - V battery Unregulated battery power supply from EPS

21 Page: Communication 6.1 Debug UART The MCU s UART1 module is used as the Debug UART. It is connected to Debug UART header on the side of CubeComputer for ease of access. The Debug UART can also be connected to the PC104 header on a number of different pins, as indicated in Table 8 and Table 9. A summary of these pins are given by Table 10. Table 10 Debug UART pin connections to the PC104 header MCU pin MCU designator PC104 pin 37 PB9 (U1 TX) H1-17 H1-18 H1-19 H1-20 H2-21 H PB10 (U1 RX) H1-17 H1-18 H1-19 H1-20 H2-21 H Miscellaneous UART The Misc. UART is the MCU s UART0 module and is connected to the piggyback header. The Debug UART can also be connected to the PC104 header on a number of different pins, as indicated in Table 8 and Table 9. A summary of these pins are given by Table 11. Table 11 Miscellaneous UART pin connections to the PC104 header MCU pin MCU designator PC104 pin 84 PF6 (U0 TX) H1-33 H1-35 H1-39 H PF7 (U0 RX) H1-33 H1-35 H2-39 H2-40

22 Page: System I 2 C The I2C0 module of the MCU is used to implement the System I 2 C bus. The System I 2 C is normally used by the OBC to communicate with the other I 2 C nodes in the satellite. The System I 2 C bus is buffered and can be populated with pull-up resistors on both sides of the buffer. The System I 2 C is accessible from the piggyback header and the main PC104 header on H1-41,43. Additional information regarding the use of the System I 2 C bus can be found in the CubeComputer I 2 C Application Note. 6.4 Secondary I 2 C The I2C1 module of the MCU is used to implement the Secondary I 2 C bus. The Secondary I 2 C is used to establish communication with subsystems of the satellite not connected to the main I 2 C bus. The I 2 C bus is buffered and includes pull-up resistors on both sides of the buffer. The Secondary I 2 C is accessible from the piggyback header and the main PC104 header (H1-21,23). Additional information regarding the use of the Secondary I 2 C bus can be found in the CubeComputer I 2 C Application Note. 6.5 SPI The MCU s US0 SPI module is routed to both the piggyback header and the main PC104 header (H1-29,30,31,32). The user can implement the SPI interface to communicate with several SPI slave nodes using multiple GPIO pins to select the various slaves. 6.6 CAN The combination of a CAN controller and a CAN transceiver allows CubeComputer to interface on a 3.3 V or a 5 V CAN bus. The CAN controller communicates via SPI with the MCU s US1 SPI module. The CAN bus is available on both the piggyback header and the main PC104 header (H1-1,3). Although a 120 Ω termination resistor is used between the CAN High and CAN Low bus lines by default, the user can specify their own termination resistor value. Refer to the CubeComputer CAN Application Note for more information on the use of the CAN bus.

23 Page: Physical Specifications 7.1 Mass A fully populated CubeComputer V4.1 weighs 56 g. The mass will however vary depending on the CubeComputer configuration. 7.2 Dimensions The CubeComputer PCB is designed to fit most standard CubeSat structures. Figure 18 show the dimensions of the PCB, with measurements in mm. The PCB material used is FR4. Figure 18 Dimensions of CubeComputer PCB

24 Page: Additional mounting holes In addition to the normal CubeSat PCB mounting holes, CubeComputer has four additional mounting holes. The positions of these mounting holes are shown in Figure 19. Figure 19 CubeComputer V4.1 mounting holes

25 Page: Header and component height The height of the main PC104 header (H1 and H2) depends on the user s header selection. Table 12 shows the height of the headers and the highest components on CubeComputer, as given by the relevant datasheets. Table 12 Header and component heights of CubeComputer Component Height (mm) Highest component on the bottom of the PCB 2.60 Highest component on the top of the PCB 1.75 MicroSD card holder 1.80 FPGA header 3.45 MCU header 2.00 UART header 2.41 WDGE header 1.98 BU_VIN header 3.45 Piggyback header 5.10 Figure 20 shows the side view of CubeComputer V4.1 and several of the dimensions from Table 12. Figure 20 Side view of CubeComputer V4.1 Figure 21 shows the front view of CubeComputer V4.1 and several of the dimensions from Table 12. Figure 21 Front view of CubeComputer V4.1

26 Page: Environmental Tests 8.1 Vibration test Description A vibration test subjects a subsystem to vibrational loads of various frequencies and amplitudes. This test is required to verify that the subsystem will still perform as intended after experiencing the vibrations which occur during launch. Given that the orientation of the satellite in the launch vehicle is not known beforehand, the maximum loads were tested in all three major axes (X, Y, and Z). Table 13 and Table 14 show the vibration loads CubeComputer was subjected to for qualification and acceptance tests. Table 13 Sine vibration specifications Characteristic Qualification Acceptance Sweep rate 2 [oct/min] 4 [oct/min] Frequency [Hz] Amplitude [g] Qualification Acceptance Table 14 Random vibration specifications Characteristic Qualification Acceptance RMS acceleration 6.5 [g] 5.2 [g] Duration 35 [s/axis] 35 [s/axis] Frequency [Hz] Amplitude [g] Qualification Acceptance For vibration testing, the following risk factors have been identified: CubeComputer microsd card connector CubeComputer components solder joints

27 Page: Results Post vibration test results showed no damage to the areas that were considered risk factors and no measurable difference were noted to normal operating behavior after the vibration tests. 8.2 Heated vacuum test Description A vacuum chamber was used to test the operation of the module in a low pressure environment similar to that found in space, which is in the order of 10-5 mbar. This low pressure can have a variety of adverse effects on the module: Outgassing of components Bubbles in soldering can cause a solder connection to crack and explode Heat dissipation through convection becomes negligible and hot spots can occur The vacuum chamber was de-pressured to 3.5 x 10-3 mbar and the module heated to 60 C in order to verify the lack of any thermal hotspots Results No measureable differences were detected in operating conditions during and after vacuum cycle. The temperature of the board and components also settled close to ambient, which verified adequate heat dissipation via conduction. 8.3 Radiation test Two separate radiation effects were investigated: (1) total ionising dose (TID); and (2) SEU caused by high energy particles TID test The TID test was performed with a Cobalt-60 source. CubeComputer was radiated at a dose rate of 4 krad per hour for more than six hours for a total of 25 krad. This is above the dosage requirement according to the ISO2002 standard of 10 krad for small scale satellites. CubeComputer stayed responsive throughout the entire 25 krad test procedure. The supply current telemetry of CubeComputer is shown in Figure 22, from which it is clear that CubeComputer suffered damage between 18 and 19 krad TID. This damage significantly influenced its power consumption, but did not notably affect the performance of the unit.

28 Current (ma) Temperature ( C) Part: CubeComputer V4.1 Page: 28 CubeComputer Supply Current Dosage (krad) Avg Current Max Current Temperature Figure 22 CubeComputer supply current versus radiation dosage Post-test analysis of CubeComputer confirmed the failure of the EEPROM and flash modules. The internal flash of the microcontroller was still working nominally. While running the application in debug mode, it was established that the reading capabilities of EEPROM was still working nominally (except for 1 bit flip) but not the writing capabilities; the reading and writing of the external flash module was not working. This is most likely due to the charge-pumps on the EEPROM and flash modules that failed, which is needed to reprogram the device. This is consistent with results published of TID tests on similar component types. A test pattern was repeatedly written to the modules (about every 60 seconds), during the TID test. It is during this write process that the device is most susceptible. It is expected that writes to the EEPROM and flash module will be less frequent during in-flight operation, which could improve the module s lifetime. CubeComputer has two SRAM modules. During the TID test, a test pattern was continuously written to and read from the one module while the other module was kept idle. The posttest analysis showed that the module that was active (reading and writing) showed degradation. When writing to certain addresses, the modules (wrongly) overwrote data in other addresses. The module that was kept idle showed no signs of degradation. After a few days of annealing the additional anomalous 15 ma average current (as can be seen in Figure 22) persisted. This indicates that increase in current is due to a failure in one of the modules (EEPROM and/or flash) on CubeComputer.

29 SEU Count Part: CubeComputer V4.1 Page: SEU test The SEU tests were performed using a 66 MeV proton beam at na for 5 to 60 second intervals. Two tests were conducted: in one the beam was focussed on the MCU, and in the other it was focussed on the SRAM. The goals of the tests were as follows: SRAM MCU Verify that single event upsets occur (single, double and multi bit errors). Verify that the EDAC can correct them. Verify that single event latch-ups occur. Verify that automatic power cycle that occurs can correct the latch. Verify that single event effects cause the MCU to stall. Verify that the external watchdog will cause a power cycle of OBC which removes the latch and resume nominal operation. The results of the tests were as follows: SRAM Single event upsets did occur (single bit only). The EDAC successfully corrected them. No double or multi-bit errors could be induced. A potential latch-up might have occurred. However, due to limitations of the power supply circuitry (limited current supply), the anti-latch-up circuitry for the SRAM module could not be verified during this test. The circuitry was however verified beforehand. Test results show evidence of micro latches in the SRAM module which were removed after the power cycle. Figure 23 shows the SEU count with respect to total beam exposure over time SEU Count vs Beam Exposure Beam Intensity Test Time Figure 23 SRAM SEU count result

30 Temperature ( C) Part: CubeComputer V4.1 Page: 30 MCU Multiple resets did occur during exposure of the MCU. However, it is difficult to ascertain whether the resets from the supervisor circuit were due to watchdog timeouts or brown-out related. Figure 24 shows the OBC temperature during the testing procedures CubeComputer Temperature Test Number OBC Temperature Figure 24 Temperature during tests

31 Page: Document Version History Version Author(s) Pages Date Description of change 1.0 CJG ALL 28/06/2016 First draft 1.1 CJG 16,18 05/07/2016 Corrected UART pin descriptions. Updated layout to new template. 1.2 GHJVV ALL 11/07/2016 Several changes to layout and wording 1.3 CJG 25 20/07/2016 Updated Table 12 and Figure 21 to show the Real Time Clock as the highest component on the bottom of PCB at 2.6mm