Download Word

NSSPCM: P12408
Firmware Design
V 004
1
Contents
1.
Overview ............................................................................................................................................... 4
2.
Microcontroller ..................................................................................................................................... 5
3.
Firmware Operation.............................................................................................................................. 6
3.1
Initialization................................................................................................................................. 10
3.2
Sensor Operation ........................................................................................................................ 11
3.2.1
Temperature ....................................................................................................................... 12
3.2.2
Solar Panel........................................................................................................................... 12
3.2.3
Battery................................................................................................................................. 12
3.2.4
Output ................................................................................................................................. 12
3.2.5
Microcontroller VCC ............................................................................................................ 12
3.2.6
Microcontroller Temperature Sensor ................................................................................. 12
3.3
Fault Handling ............................................................................................................................. 13
3.4
Communication ........................................................................................................................... 16
3.4.1
Communication Speed Analysis .......................................................................................... 16
3.4.2
Implementation .................................................................................................................. 16
2
Revision
001
002
Date
2012-02-14
2012-02-20
003
004
2012-03-21
2012-05-22
Document Modifications
Modifications
Document Creation.
Added minor text changes. Modified design to use raw ADC value instead of
converted value and CRC8 instead of CRC16.
Fixed typographical errors. Added MCU internal VCC and temp sensors.
Added ADC channel chart. Corrected design document for changes in
implementation.
3
1. Overview
The purpose of the NSSPCM firmware is to collect information from power and temperature sensors,
evaluate that information against acceptable parameters and communicate that information with the
payload over a bidirectional communication interface. The core functions of the firmware will not
depend on elapsed time to operate because the system needs to return to operation after a blackout
condition in the case of a depleted battery. Counters required for certain fault condition triggers will be
reset in the event of a blackout. The NSSPCM uses a MSP430F2234 microcontroller.
4
2. Microcontroller
The MSP430F2234 microcontroller was selected primarily because it contained a 12 channel analog-todigital converter (ADC) with 10 bits of resolution per channel. This was required due to the sensing
circuits. This chip also has the capability of being programmed via a 2-wire spy-bi-wire interface from
the MSP430G2 Launchpad, which is a low cost development board for Texas Instruments' value line
series of microcontrollers. Because the NSSPCM management features must be low power, the
microcontroller must consume a small amount of current. With the main clock set to 1 MHz, the
MSP430F2234 consumes 500 µA. When the microcontroller is in standby mode such as waiting for a
sensor update or a serial command, it uses an external oscillator and consumes 1.5 µA. Because the
project requires a serial communication, an on-chip UART greatly simplifies design and reduces power
consumption. The MSP430F2234's UART can use interrupts to allow the microcontroller to be in a low
power mode or perform other functions while communication is not active. Because communication is
used, a larger memory capacity would be required to contain the receive and transmit buffers. The
MSP430F2234 has 512 bytes of RAM and 8 kilobytes of flash memory. An additional advantage is the
familiarity with the MSP430 microcontrollers as well as the MSP430 Launchpad. The programming tool,
Code Composer Studio, is based on Eclipse open source framework and is free for code sizes up to 16
KB.
5
3. Firmware Operation
The firmware will consist of a monitoring loop which will collect sensor data and compare that data
against thresholds to determine if the system is operating within acceptable parameters. The system will
also support interrupt driven RS-485 communication with the payload. The sensor circuits utilize the
MSP430F2234’s analog-to-digital converters (ADC). The ADCs have a 10-bit resolution and use
successive approximation to convert an analog signal to a digital value. The program will follow the
operational loop shown in Figure 1. The high level system flowchart is shown in Figure 2.
Power On
Send Data to
Payload
Initialization
Program Loop
Fault Alert
Read System
Inputs
Yes
Evaluate Status
Fault Present
Fault Handling
No
Figure 1: Program Operation
At power on, the system timers, UART, ADCs and other settings are initialized. The firmware then
proceeds to conduct a self test by reading all of the sensors connected to ADCs and converting the
digital ADC values to the measured value of the sensor in milliamps, volts or degrees Celsius. After the
self test, the program loop will be executed every 60 seconds. ADC details are described in Section 3.2.
The firmware modes of operation are shown in Table 1. The state diagram which defines the flow
between modes of operation is shown in Figure 3. The presence of fault conditions causes the transition
between states. Fault conditions are described in Section 3.3. The loop can be interrupted by an
incoming RS-485 frame at any time after initialization.
6
ID
M1
Name
Normal
Description
Normal operation. No faults detected.
Entry Criteria
No faults detected.
Functions
M2
Temperature Out of
Range
Internal temperature outside of acceptable
range.
F3 or F4 fault
detected.
M3
Low Battery
Battery level is low.
F2 fault is detected.
M4
POST
At power up, evaluate current status.
Previous state was
unpowered.
Evaluate all inputs and proceed to
appropriate operation mode.
M5
Fault
Fault is detected.
F6, F8, F9 or F10 fault
detected.
Fault condition is held until no fault
exists.
Table 1: Operation Modes
7
Power On
High Level Software Flowchart
Initialization
Timers
Inputs/Outputs
Interrupt Setup
Interrupt Enable
Receive
Command
Program Loop
Process
Command
Read System
Inputs
Read Temperature
(Internal)
Read Temperature
(Inside)
Read Solar Power
Read Temperature
(Outside)
Read Solar Power
Read Battery
Send Data to
Payload
Read Battery
Read Temperature
(External)
Read Status
Evaluate Status
Reset Payload
Temperature
within Range
Toggle Output
No
Yes
No
Solar Power
Level
Fault Alert
Yes
Battery Level
No
Yes
Fault Analysis
Figure 2: High Level System Flowchart
8
POWER ON
M4
POST
F3/F4
No Fault
M2
TEMP OUT
OF RANGE
No Fault
F3/F4
F2
F2
F2
M3
LOW
BATTERY
No Fault
F2
F6/F8/
F9/F10
M5
FAULT
M1
NORMAL
F6/F8/
F9/F10
No Fault
F3/F4
Figure 3: Modes of Operation State Diagram
9
3.1
Initialization
During initialization, the GPIO pins are configured for output mode for indicator LEDS, the output switch
and the ADC protection circuit. The UART is also configured to use SMCLK (1MHz) at 9600 baud. At the
end of initialization, the UART interrupt is enabled. The two timers are used by the NSSPCM. One timer
uses the external 32.768 kHz crystal with a clock divider of 1 and set to interrupt every second. This
timer is used to initiate a sensor read and evaluation.
1
≅ 30.5176 µ𝑆 = 𝐶𝑙𝑜𝑐𝑘 𝑃𝑒𝑟𝑖𝑜𝑑
32.768 𝑘𝐻𝑧
1𝑆
≅ 32767 = 𝑇𝐴𝐶𝐶𝑅0
30.5176 µ𝑆
Another timer is based on SMCLK to count the silence time for the start, end and timeout periods for the
UART communication. The second timer uses a clock divider of 8 is set to interrupt every 416 µS which
represents half of a character (4 bits).
4 𝑏𝑖𝑡𝑠
= 416.67 µ𝑠
9600 𝑘𝑏𝑝𝑠
1 𝑀𝐻𝑧
= 125 𝑘𝐻𝑧 = 𝐶𝑙𝑜𝑐𝑘 𝐹𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦
8
1
= 8 µ𝑆 = 𝐶𝑙𝑜𝑐𝑘 𝑃𝑒𝑟𝑖𝑜𝑑
125 𝑘𝐻𝑧
416.67 µ𝑆
= 52 = 𝑇𝐵𝐶𝐶𝑅0
8 µ𝑆
10
3.2
Sensor Operation
The MSP430F2234 has a 12 channel successive approximation register (SAR) analog-to-digital converter
(ADC) with a resolution of 10 bits per channel. All ADC inputs are sent through positive logic controlled
normally open analog switches for protection in the event VCC goes to 0 volts during a blackout
condition. The ADC pins are pulled to ground through a high resistance until the microcontroller
activates the switch. The ADC is used to sense internal temperature, external temperature, solar panel
voltage, solar panel current, battery voltage, battery current, output voltage and output current. Each
sensor value is stored as a raw ADC value as an unsigned integer (16 bits). It is unnecessary to convert
the raw values to desired formats using floating point math at this level. For threshold comparisons, the
values compared to are also unsigned integers.
Pin/Channel
Device
A0
External Temperature Reference
A1
External Temperature
A2
Internal Temperature Reference
A3
Battery Voltage
A4
Solar Current
A5
Internal Temperature
A6
Battery Charging Current
A7
Battery Discharging Current
A10
MCU Internal Temperature
A11
MCU VCC
A12
Output Voltage
A13
Output Current
A14
NC
A15
NC
Table 2 – Connected ADC Channels
11
3.2.1 Temperature
Each temperature sensor, internal and external, uses two ADC inputs each. One is for the temperature
sensor output and the other is for the sensor’s ground reference. The sensor outputs 10 mV per degree
Celsius. Information regarding ADC channel configuration and sensor conversion equations is contained
in Sections 2 and 3 of the Sensor Equations document.
3.2.2 Solar Panel
The solar panel sensor circuit uses one ADC input from the current. Information regarding ADC channel
configuration and sensor conversion equations is contained in Section 4 of the Sensor Equations
document.
3.2.3 Battery
The battery sensor circuit uses three ADC inputs. One is for sensing the current into the battery, one is
for sensing the current out of the battery and one is for sensing the battery voltage. Information
regarding ADC channel configuration and sensor conversion equations is contained in Section 5 of the
Sensor Equations document.
3.2.4 Output
The output sensor uses two ADC inputs. One is from the current sensor and one is for the voltage.
Information regarding ADC channel configuration and sensor conversion equations is contained in
Section 6 of the Sensor Equations document.
3.2.5 Microcontroller VCC
The VCC sensor uses an internal ADC input. The sensor is a simple voltage divider producing VCC/2 and is
used with a reference voltage of 2.5 V. The VCC value is used to achieve more accurate calculated values
for other ADC sensors. Information regarding ADC channel configuration and sensor conversion
equations is contained in Section 7 of the Sensor Equations document.
3.2.6 Microcontroller Temperature Sensor
The microcontroller’s internal temperature sensor measures the temperature of the IC die which gives
an estimation of PCB component temperature. Information regarding ADC channel configuration and
sensor conversion equations is contained in Sections 8 of the Sensor Equations document.
12
3.3
Fault Handling
The NSSPCM supports 10 faults shown in Table 3. Table 3 outlines the detection criteria for each fault as
well as the reaction to each fault. Some faults cannot be detected by the microcontroller such as a
battery failure or a microcontroller failure. Some can be detected but not corrected such as temperature
outside of operational range. The sensor evaluation operation is described in the Fault Handling
Flowchart in Figure 4.
Begin Evaluation
Battery Voltage
Above 10 V?
No
Record low battery
event
Send low battery
alert
Yes
Int Temp
>0°C &
<30°C?
No
Record temp warn
event
Int Temp
> -40°C &
<45°C
Send temp
warning alert
No
Record temp
critical event
Yes
Yes
Send temp critical
warning
Yes
Yes
Output is On?
Output Voltage
<1V?
No
No
No
Self test mode?
Record short
event
Record self test
fail event
Yes
No
Comm timer >
300 s
No
Send ping
Yes
Evaluation End
Ping success?
Record comm fail
event
Yes
Reset comm timer
Figure 4: Fault Handling Flowchart
13
ID
F1
Name
Blackout
Description
No power to module or
payload from battery or solar
collection
Detection
F2
Low Battery
Battery level is lower than
threshold
Battery voltage is less than
10 volts
Fault recorded.
F3
Temperature
Warning
Temperature is out of
acceptable threshold
Internal temperature is
greater than 30 °C or
lower than 0 °C.
Fault recorded.
F4
Temperature
Critical
Temperature is out of
operational threshold
Internal temperature is
greater than -40 °C or
lower than +45 °C.
Fault recorded.
F5
Battery Failure
Battery is not operating
correctly or not charging
None
None
F6
Solar Panel
Failure
Solar collection is not
producing power
None
None
F7
Microcontroller
Failure
Microcontroller hardware
does not function or software
malfunctions
None
F8
Short/Overload
at Output
A short or overload is
experienced at the module
output
Current at module output
is greater than 1 A.
Charger and regulation
operates when
microcontroller is
inoperable. Watchdog
timer is in use.
Disable output for 15
seconds.
None
Reaction
Power-on, evaluate sensor
data, begin appropriate
operation mode.
Comments
No power is supplied
to system from
MPPT/charger when
battery has failed.
14
F9
Communication
Loss
Module cannot communicate
with payload
Ping command sent from
NSSPCM at 300 second
interval failed.
Fault recorded.
F10
Self Test Failure
Module self test fails.
Sensor evaluation is
forced. If result is any
fault condition, self test
fails.
Fault recorded.
Fault clears when ping
succeeds or valid
command is received
from payload followed
by successful ping.
Table 3: Fault List
15
3.4
Communication
The NSSPCM uses RS-485 for communication because of the resistance to noise due to differential
signaling. RS-485 exceeds the speed and length requirements as outlined in the Engineering
Specifications. The NSSPCM is set to communicate at 9600 baud using 1 start bit, 8 data bits, and two
stop bits (8N2). The NSSPCM supports a modified MODBUS protocol as outlined in the Communication
Protocol Specification and the instruction set included in Appendix A of the Communication Protocol
Specification.
3.4.1 Communication Speed Analysis
Engineering specification 6 states that the update rate of the module must meet or exceed 1 Hz. More
specifically, the entire status of the NSSPCM must be communicated to the payload in less than one
second. The largest single message supported by the NSSPCM is the GET_STATUS command which is
issued from the payload to the NSSPCM. This is shown in Appendix A of the Communication Protocol
Specification. The total size of the message is 184 bits which is 23 bytes. Ignoring frame setup time and
ADC polling time, the module must be able to achieve at least 184 bits per second across the
communication bus. The modified MODBUS protocol specifies that 9600 baud be supported by default.
The MSP430F2234 is capable of easily supporting this speed. This baud rate exceeds our minimum
speed requirement.
3.4.2 Implementation
The NSSPCM uses a Maxim IC MAX3483 transceiver to accomplish RS-485 differential signaling. The
MAX3483 is powered by the same voltage as the microcontroller at 3.3 Volts. It has a guaranteed speed
of up to 250 kbps and is half duplex. It is also low power utilizing (typically) 1.1 mA while transmitting,
0.95 mA while receiving and 0.002 µA while disabled.
The MAX3483 is connected to the MSP430F2234’s UART. The UART is configured for interrupt mode, no
parity, LSB first, eight data bits, and two stop bits. Error checking is handled within the protocol through
a 16 bit cyclic redundancy check. When a command is received from the payload, the microcontroller
exits low power mode and processes the command. The transmit message function diagram is shown in
Figure 5 and the receive message function diagram is shown in Figure 6.
16
Begin Frame
Preparation
Add module
address to buffer
Yes
Add function code
to buffer
Data Required
Add data to buffer
No
Yes
No
End of data?
Generate CRC8
Add CRC8 to
buffer
End Transmission
Figure 5: Transmit Message Function Diagram
Read address byte
from UART RX
buffer
RX Interrupt
Is this device
address?
No
Yes
Yes
Store function
code
Read function byte
from UART RX
buffer
Valid function
code
No
No
Store byte from
UART RX buffer
End of
message?
Yes
Message end
Yes
Process message
Yes
CRC8 valid?
Generate CRC8
No
Message
requires
response?
Message valid?
No
No
Flush receive
buffer
Yes
Begin transmit
response
Figure 6: Receive Message Function Diagram
17
4. Firmware Implementation Notes
The submitted firmware code is NSSPCM Firmware Version_1_1. This version satisfies all engineering
specifications. The firmware contains a main.c file which includes the appropriate files, initializes the
hardware, enables interrupts, begins the first sensor read and then enters low power mode (LPM3). The
code is divided into modules containing header and source files for clocks, comm_functions, CRC
functions, GPIO, communication (RS-485/UART), sensors, and timers. Each of these files contains the
specific implementations for the relevant hardware or functionality.
Due to UART interface problems with the MSP430 Launchpad, the UART speed was changed from the
originally designed 19200 baud to 9600 baud. Because of this, timerB also had to be recalculated. To
compensate for the speed of the Diagnostic Utility running on the PC, a 200 ms delay was added at the
end of the executeMessage() function before transmitting the response in order to allow the Diagnostic
Utility to transition from transmit to receive mode. 2 ms delays were added after the transmission of
each byte to allow for the speed of the Diagnostic Utility. Although the communication times were
within specification, the times can be greatly decreased by removing the manual delays and repairing
the diagnostic utility as well as increasing the UART speed. In the release version, fault alerts are
disabled for two reasons. The first reason is that alerts are generated every iteration of the sensor loop
that a fault is present. This needs to be fixed in a future release. The second reason is that the Diagnostic
Utility does not implement a proper collision handling mechanism to allow for a request to wait while it
is receiving an alert. The payload still has the ability to obtain all fault information by polling the
NSSPCM.
18