CDH Phase C Test Progress

CDH EM Board Operations Guide

Setting Up the EM Board

Put on the ESD wrist strap, ensure that it is connected to the ESD mat and that the ESD mat is grounded.
Connect the FlashPro6 JTAG debugger to your computer via the USB cable.
Plug the other end of the JTAG debugger to the board on the JTAG header connector as shown in the figures below.

Figure 1: CDH JTAG and Power Connection Lines

Figure 2: Power (+/- ) and JTAG connection to CDH EM board

Connecting the Board to Power

WARNING: Throughout this process, make sure that the positive and negative power lines DO NOT TOUCH. Keep them well away from each other to prevent a short from happening

Put on the ESD wrist strap, ensure that it is connected to the ESD mat and that the ESD mat is grounded
Make sure the power and ground pins are NOT connected to the variable power supply, to prevent accidental shorts
While the variable power supply is NOT connected to the EM board, turn on the variable power supply and:
1. Make sure it is on Constant Voltage (C.V.) mode
2. Set it to 6.40 V
3. Turn off the power supply
4. Hook up the multimeter to the power supply and set the multimeter to measure voltage
5. Turn on the power supply
6. Check the voltage using on the multimeter to confirm it reads 6.40 V
7. Turn off the variable power supply
Plug the ground cable onto the two CDH_NEG pins on the board
Plug the power cable onto the two CDH_POS pins on the board
Connect the ground cable to the variable power supply's negative (black) power terminal with the alligator clip
Connect the power cable to the variable power supply's positive (red) power terminal with the alligator clip
Turn on the variable power supply

Powering Down EM Board

WARNING: Throughout this process, make sure that the positive and negative power lines DO NOT TOUCH. Keep them well away from each other to prevent a short from happening.

Put on the ESD wrist strap, ensure that it is connected to the ESD mat and that the ESD mat is grounded.
Turn off the variable power supply.
Disconnect the power cable to the variable power supply's positive (red) power terminal with the alligator clip.
Disconnect the ground cable to the variable power supply's negative (black) power terminal with the alligator clip

Interfacing Via The JTAG Debugger

You should be able to interface with the board with the JTAG Debugger using Libero SoC and SoftConsole, after the board has been connected to the debugger and powered on. For details on the required software versions and the project details, please visit the Flight Software design page.

EM Model Errors, Issues and Fixes

Some errors in the CDH EM board electrical schematics were determined post manufacturing while testing the EM board. The errors and the approach to fix the errors are detailed below.

Avalanche SRAM Purchasing Delay

Due to COVID-19 related delays and delays in purchasing the 16Mb SRAM from Avalanche Technologies, the team had to purchase and solder the SRAM chip in-house to avoid manufacturing stoppage at Microart. In an effort to acquire the part sooner, the originally speced SRAM model (AS3016101-0010X0PSAR) was replaced with a newer space-grade model (from Avalanche Technologies) for EM testing due to lack of availability of the original part from the manufacturer. If the newer model (AS3016204-0108X0PSAY) functions as intended, it will be used on the FM instead of the older model (AS3016101-0010X0PSAR).

MRAM and Flash Assembly on Breadboard

Due to improper dimensioning of the Everspin Technologies 4Mb MRAM and Winbond Electronics 16Mb Flash Memory, both IC's could not be soldered onto the EM board directly. The signals for each of the two IC's were exported onto a breadboard using DFN adaptors. The IC's are soldered onto the DFN adaptors which then attach onto a breadboard. Thin wires are soldered onto the appropriate locations on the EM board to export a total of 16 signals (8 MRAM signals and 8 Flash signals) to the breadboard. See the images below. Schematics and Altium models will be updated to reflect proper dimensioning for FM manufacturing.

Figure 3: Exporting MRAM and Flash signals using a DFN breakout

Floating VDDI3 Signal

During testing, it was discovered that the VDDI3 signal was floating which resulted in FlashPro6 JTAG debugger being unable to read the Microsemi processor. The V_JTAG signal on the JTAG connector should read 3.3 V for the programmer to detect the processor. However, the floating VDDI3 signal resulted in V_JTAG reading only 1.5 V. To fix this issue, an external connection was soldered from the 3.3 V pin of J1 to the V_JTAG pin of J4. The electrical schematics of the CDH EM board can be found here.

Phase C Test Results

Un-Powered and Powered Hardware Tests

Test results for Unpowered Hardware Tests and Powered Hardware Tests completed tests are detailed below.

Phase C Test Results

Powered Software/Firmware Tests

Test results for software/firmware tests completed tests are detailed below.

C-1-SW: FPGA Functional Test

Requirements:

The CDH shall be able to operate the flight software (R-CDH-0001)
The CDH shall have a minimum 2.5mb of work memory to hold a full image plus the runtime memory (R-CDH-0002)
The CDH shall provide a minimum 500kb of boot memory to hold the flight software reference image, and bootloader (R-CDH-0003)

Verifications:

Test FSW on CDH EM (Engineering Model), and measure the CPU performance to ensure used CPU resources are less than the required (V-CDH-0001)
Test written FSW so far on CDH EM, and measure the work memory used to ensure used work memory is less than the available (V-CDH-0002)
Test FSW on CDH to determine used boot memory to ensure available boot memory is enough for FSW to be uploaded (V-CDH-0003)

Objective: Verify that FPGA array and test software can be uploaded and run on the processor/FPGA unit.

Process: Connect the CDH board to the computer using the FlashPro6 JTAG debugger. Run Libero software and upload FPGA array and debug software (see GitHub for details). Use Microsemi SmartDebug application to read the device ID and device status.

Results: Output of device ID and status details are stored here.

C-2-SW: LED Toggle &

C-3-SW: Reset Button

Requirement: The CDH shall be able to operate the flight software (R-CDH-0001)

The CDH shall recover within 5 min in case of power module reboots (R-CDH-0060)

The CDH shall be capable of resuming operation following a hardware reset (R-CDH-0061)

Verification: Test FSW on CDH EM (Engineering Model), and measure the CPU performance to ensure used CPU resources are less than the required (V-CDH-0001)

Test if CDH resumes normal operations in 5 min in the event of a power module reboot by running cycles of power (on and off) to CDH (V-CDH-0060)

Perform hardware reset on CDH and check the system response to resuming normal operations. (V-CDH-0061)

Objective: Verify that the FPGA fabric can be programmed by turning on the LED (USR_LED) and verify that the reset button (S1) performs a system reset when pressed by turning off the LED.

Process: Run a simple command to turn on the LED and while toggling the LED on, press the physical reset push button (S1, RESET) to trigger a reset. Verify that the LED stops momentarily.

Results: Both the power and programmable LEDs on the CDH board would not turn on. This is likely because they could be soldered onto the PCB in the opposite polarity or if they are blown. However, the verification activities are verified through test C-1-SW through S-12-SW since we are able to program the MCU and run sample code to test other aspects of the CDH assembly. Additionally, the reset test was also verified using software in SoftConsole by pressing the physical reset button (S1) on the CDH board while running an active task on CDH through SoftConsole. SoftConsole responded to the reset and by terminating the active task and outputting to the command window that a reset was detected.

C-4-SW: CAN Transceiver: Receive &

C-5-SW: CAN Transceiver: Transmit

Requirement: The CDH processing system shall have a CANBus controller (R-CDH-0191)

Verification: Run sample commands on CDH to ensure that data can be sent and received over CAN Bus between CDH and other connected subsystems (V-CDH-0244)

Objective: Verify that CDH can send and receive sample messages over CAN Bus.

Process: A secondary device with a CAN transceiver (used CDH dev kit from Joseph) was connected to CDH CAN Rx and CAN Tx lines on connector CN3. Test code was used to set up CDH in transmit mode to send data from CDH while the secondary CAN transceiver was set up in receive mode. Sample data was sent over from CDH and read over on the secondary CAN transceiver. The two ID's and data were compared to verify they were the same. This verifed CDH was able to transmit messages via CAN. The test was repeated with CDH on receive mode and secondary CAN transceiver on transmit mode to verify CDH can receive messages via CAN. (Test code on GitHub: can_tests.c)

Results: See CAN message in Figure 4.

Figure 4: CAN message "Hello World" sent for testing CAN transceiver

C-6-SW: ADCS SPI Communication

Requirement: The CDH subsystem shall interface with the ADCS controller using SPI (R-CDH-0133)

Verification: Run sample commands on CDH to verify that it is able to communicate with ADCS controller over and SPI connection (V-CDH-0248)

Objective: Verify that CDH can send sample data over the ADCS SPI lines using.

Process: Test code was used to set up CDH in transmit mode to send data from CDH over the SPI lines for ADCS. A logic analyzer was connected to the ADCS SPI lines (MOSI, MISO, SCK, CS) on connector CN1 and the sample messages were viewed and decoded by the logic analyzer and compared to the signals sent by CDH to verify that CDH can communicate over the ADCS SPI line. (Test code on GitHub: adcs_tests.c)

Results: See logic analyzer data in Figure 5. The data read on the logic analyzer corresponds to the sample data coded in SoftConsole in adcs_tests.c

Figure 5: SPI signals on logic analyzer for sample data.

C-7-SW: 1Gb Flash Functional Test

Requirement: The CDH shall provide a minimum of 100 MB Flash storage memory (R-CDH-0005)

Verification: Run sample code on CDH to verify functionality of the flash memory (V-CDH-0005)

Objective: Verify that data can be written to and read from the Flash device.

Process: Test code was used to write to multiple locations of the flash memory and was then read and compared to the written data to ensure we can write, store and read the sample data. Additionally, the device ID was determined and verified against the part datasheet. (Test code on GitHub: memory_tests.c)

Results: See device ID in Figure 6. Device ID reads efaa21 as in the datasheet.

Figure 6: 1Gb Flash Device ID

C-8-SW: 16Mb Flash Functional Test

Requirement: The CDH shall provide a minimum of 100 MB Flash storage memory (R-CDH-0005)

Verification: Run sample code on CDH to verify functionality of the flash memory (V-CDH-0005)

Objective: Verify that data can be written to and read from the Flash device.

Results: See device ID in Figure 7. Device ID reads ef4015 as in the datasheet.

Figure 7: 16Mb Flash Device ID

C-9-SW: 4Mb MRAM Functional Test

Requirement: The CDH shall provide a minimum 500KB of safeguard memory to hold the actual satellite configuration and status log, ground commands, results of processed images, and system state registers (R-CDH-0004)

Verification: Run sample code on CDH to verify it can read and write data on the MRAM (V-CDH-0004)

Objective: Verify that data can be written to and read from the MRAM device.

Process: Test code was used to write to multiple locations of the MRAM memory and was then read and compared to the written data to ensure we can write and read the sample data. (Test code on GitHub: memory_tests.c)

Results: The MRAM (and it's datasheet) does not contain a device ID, however, the test is verified successfully since we were able to write and read to all memory locations of the MRAM which can be seen in SoftConsole.

C-10-SW: 16Mb SRAM Functional Test

Requirement: The CDH shall have a minimum 2.5mb of work memory to hold a full image plus the runtime memory (R-CDH-0002)

Verification: Test written FSW so far on CDH EM, and measure the work memory used to ensure used work memory is less than the available (V-CDH-0002)

Objective: Verify that data can be written to and read from the SRAM device.

Process: Test code was used to write to multiple locations of the SRAM memory and was then read and compared to the written data to ensure we can write and read the sample data. Additionally, the device ID was determined and verified against the part datasheet. (Test code on GitHub: memory_tests.c)

Results: See device ID in Figure 9. Device ID reads e61141 as in the datasheet.

Figure 8: 16Mb SRAM Device ID

C-11-SW: ADC Functional Test

Requirement: CDH shall accommodate one thermistor P/N NTCG163JX103DTDS to monitor main CDH processor temperature. (R-CDH-0004)

Verification: Run FSW on CDH to verify that CDH is able to read and monitor the temperature of its processor from the thermistor located in CDH. (V-CDH-0266)

Objective: Verify that the temperature can be read in the software using the thermistor and ADC device.

Process: Run test code on CDH and read the voltage on the ADC. Convert the voltage on the ADC to temperature using the reference ADC voltage and thermistor resistance. Compare the voltage in software to the voltage read on TP23 on the CDH board measure using a multimeter (Test code on GitHub: adc_tests.c)

Results: Digital voltage read from the ADC corresponds to the voltage difference read across TP23 and GND. Need to calibrate the digital voltage to convert it to the temperature which will be done in Phase D during TVAC tests.

C-12-SW: RTC Functional Test

Requirement: The CDH shall keep track of time for the duration of the mission (R-CDH-0034)

Verification: Run FSW on CDH and verify that CDH is to keep track of time using the RTC on the EM (V-CDH-0241)

Objective: Verify that the RTC on CDH is able to keep track of time and in sync with the MCU's clock.

Process: Set time on the MCU and apply the same time to the RTC. Read the output time every few seconds or minutes and verify against a stopwatch/phone clock. Also, verify that both the external RTC and MCU's clock are in sync and read the same time. Then, a second test was run. The time was set on the RTC and the code was modified to prevent writing/setting the time and would only read the RTC time. The CDH board was turned off which would cause the RTC to run on the coin cell. The board was turned on and the RTC time was read after a given period while tracking the time on a phone clock. This verifies that the RTC can keep track of time even when CDH board is unpowered/turned on. (Test code on GitHub: rtc_tests.c)

Results: ADC is able to track time with or without power supply to the CDH board. A delay of approximately 1-2 seconds is seen because of the delay in running the code, reading the RTC and displaying the output. See video here.

CDH PCB Mass Inspection

Requirement: CDH shall have a maximum non-structural mass of 96 grams. (R-CDH-0151)

Verification: Verify that CDH does comply with the structural mounting path by attaching the CDH PCB to the CDH/COMMS structural module. (V-CDH-0214)

Objective: Measure the mass of CDH PCB and ensure that the total CDH mass budget is less than 96g.

Process: Since the CDH PCB contained errors and the 4Mb MRAM and 16Mb Flash Memory are connected to the PCB through a DFN breakout and breadboard, the mass inspection involved measuring the PCB mass without the MRAM and Flash. The MRAM and Flash mass is expected to be very small and not impacting the overall mass budget.

Results:

Mass of PCB (without MRAM and Flash) = 27 [g]

Total CDH module mass: 45.6 [g]. See CDH mass budget for details.

CDH Structural Fit Check

Requirements:

The CDH shall mount to the spacecraft structure. (R-CDH-0150)
All fasteners should have a thread size of 2-56, 4-40, or 6-32 (R-CDH-0159)

Verification: Verify that CDH does comply with the structural mounting path by attaching the CDH PCB to the CDH/COMMS structural module. (V-CDH-0214)

Objective: Ensure the mounting holes on the PCB are sized and positioned correctly.

Process: Use the EM COMMS/CDH module and connect the CDH PCB to the structure EM shells with the fasteners to ensure the mounting holes on the PCB are sized and positioned correctly.

Results: CDH corner mounting holes align with the structure module mounting holes. See Figure 9 and Figure 10.

Figure 9: CDH-STR fit check in the CDH/COMMS module.

Figure 10: CDH-STR fit check showing the four corner mounting paths to the in the CDH/COMMS structural module

CDH-PCU Power Check & Inrush Current Test

Requirements: The CDH shall use a maximum current of 0.3 A. (R-CDH-0122)

Verification: Test the power consumption and measure the current used by CDH. Verify that the current is less than 0.3 A. (V-CDH-0245)

Objective: Check that PCU can power CDH and that the inrush current does not exceed 0.3A (max current draw that CDH can expect from PWR).

Process: Connect CDH to the PWR PCU and connect a 1 Ohm resistor across the positive power input line into CDH. Attach an oscilloscope across the 1 Ohm resistor. Turn on the PWR PCU and supply power to CDH and record the current draw across the resistor on the oscilloscope. Ensure that the maximum current (inrush current) is less than 0.3 A.

Results: CDH current draw on startup (inrush current) is less than 0.3 A. See Figure 11 and Figure 12.

Figure 11: CDH current draw from power-up to shutdown.

Figure 12: CDH inrush current upon power-up from PWR PCU

CDH Assembly and Harnessing Mockup

Requirements:

The CDH shall mount to the spacecraft structure. (R-CDH-0150)
All fasteners should have a thread size of 2-56, 4-40, or 6-32 (R-CDH-0159)

Verification: Verify that CDH does comply with the structural mounting path by attaching the CDH PCB to the CDH/COMMS structural module. (V-CDH-0214)

Objective: Ensure that the CDH assembly procedures are feasible to install the CDH board into the CDH/COMMS module and solder the required harnessing.

Process: Use the EM COMMS/CDH module and the two CDH EM PCB (one of them to act as the COMMS PCB) and mock the CDH assembly and Integration plan (Link can be found here). Verify that the assembly procedure is feasible and make and changes required to the assembly plan (if needed). This will ensure that integration of the CDH FM into the full satellite (as part of Phase D AIT activities) can be performed with the available tools.

Results: CDH assembly and integration plan are feasible. Two minor changes were made to the plan:

Changed the four corner mounting screws to four threaded rods with nuts
Added holes on the top surface of the PLD module to provide a surface to zip tie the harnessing from the CDH board to the intermodule connector located on the top surface of the PLD module.

(Videos of the mockup can be found on the CDH assembly and Integration plan page)

Page updated

Google Sites

Report abuse