Theory of Operation
Health and Status Firmware
Written: Ian MacKenzie
Health and Status Firmware Overview
The purpose of the MPPT Heath and Status firmware is to provide up-to-date information
concerning the status of the satellite relevant to the MPPT such as solar panel voltages, solar
panel temperatures, and system current. The information collected by the MPPT Health and
Status firmware is requested by the primary microcontroller of the satellite, referred to as the
Internal Housekeeping Unit (IHU), and is eventually transmitted to Earth via amateur radio.
Software Block Diagram
The MPPT Health and Status firmware has two primary functions:
(1) Measure analog inputs using an Analog-to-Digital Converter (ADC)
(2) Periodically report measurements to the Internal Housekeeping Unit upon request
Figure 1: Signal and data flow
Microcontroller Overview
The microprocessor selected to run the MPPT Health and Status firmware was the Texas
Instruments MSP430FR5739 mixed signal microprocessor. The MSP430FR5739 offered many
advantages over other microcontrollers, including but not limited to:






FRAM technology
o Adds a layer of protection against Single-Event Upsets (SEUs) due to harmful
ionizing radiation by being naturally radiation resistant
o Nearly limitless read/write cycles
Error-Correcting Code (ECC) memory
o Automatic correction of single-bit errors
14-Channel 10-bit Analog-to-Digital Converter (with internal voltage reference)
Native I2C support with ability to interact using multiple slave addresses
Extensive clock system
Availability of a low-cost development board
While the primary Maximum Power Point Tracker PCB was being designed, the Health and
Status firmware was developed using the MSP-EXP430FR5739 Experimenter Board. After the
Maximum Power Point Tracker PCB was fabricated and populated, an MSP-FET430UIF USB
Debugger was used to program the MSP430 via a JTAG interface. All firmware code was
developed using Code Composer Studio v5.3.0.
Modular Software Structure
Every major software function, particularly those requiring a hardware interface, is separated
into an independent block referred to as a “module”. This modular structure allows individual
modules to be changed or replaced with minimal impact on the rest of the firmware. Information
may be passed between different modules only within a call from the main program loop.
Figure 2: Block diagram of the modular structure employed in the MPPT Health and Status
firmware
Any given module consists of three parts:
(1) Interface – Refers to the interface between the main program loop and the module. Any
external function to the module may only call a function within a module’s Interface;
access to the Library or Target-Specific functions is forbidden. The file containing a
module’s interface, as well as the function and variable names included in that file, have
a _INT suffix.
(2) Library functions – Functions necessary to carry out the operation of the module, but do
not need to be visible to the main loop, and contain no hardware-specific dependence.
The file containing a module’s library operations, as well as the function and variable
names included in that file, have a _LIB suffix.
(3) Target-Specific functions – Functions and interrupt service routines that are
microcontroller (target)-specific in nature. For example, the I2C Slave module’s targetspecific functions may involve direct access to the microcontroller’s communications
peripheral, such as the eUSCI. For a module with a purely software implementation (no
hardware dependence), the Target-Specific operations block may be excluded. The file
containing a module’s target-specific operations, as well as the function and variable
names included in that file, have a _TGT suffix.
A specialized ‘System’ module was created to handle firmware environment specific tasks, such
as setting up the internal voltage reference and clock system.
In addition to being modular, the firmware was written to be portable as well. In the event that
the MSP430FR5739 becomes unsuitable for use on the spacecraft, the firmware can be easily
ported to a similar Texas Instruments microcontroller device.
Startup Sequence
Upon a Power-On Reset (POR), the firmware prepares the microcontroller for operation. The
startup sequence is shown below.
Figure 3: Flowchart of the MPPT Health and Status start-up sequence
Running Sequence
Figure 4: Flowchart of the MPPT Health and Status primary operation
Within the main loop, the I2C Slave module is continually checked for any incoming messages or
requests. The eUSCI’s ability to communicate using multiple slave addresses allows the MPPT
(MSP430) to have multiple channels for communications. The “Primary” address is used during
normal communications with the Internal Housekeeping Unit. The “debug” address allows
alternative data to be easily requested. Up to two more addresses could be utilized for additional
functionality.
Currently, only the transmission of data in a predetermined packet format is handled by the I2C
Slave module, but code can very easily be added in future revisions to incorporate the ability to
take in and interpret data from the Internal Housekeeping Unit.
In addition to running through the main loop, a few additional processes run automatically via
the use of interrupts:



Upon completion of an ADC10 sample set, the sample data is copied into an array of
“current” data (which is then replaced upon the completion of another ADC10 sample
set). The data is not copied into the array if an ADC10 lockout is currently in place, as is
the case when building a reply message. The purpose of this lockout is to prevent mixing
of sample sets being sent to the IHU within a single packet.
The I2C bus is constantly monitored for reception of any slave address corresponding to
the Health and Status firmware. Upon reception of a relevant slave address and a READ
or WRITE signal, the I2C Slave module updates a structure within the module, so that it
may be checked within the main loop.
When a message is in the process of being transmitted, an interrupt will trigger when the
next byte is available to be sent.