Added an Extensions to Alarm for detailed status/substatus reporting.
Extended Alarms are the first in the Alarm structure and have corresponding fields in Status and Substatus structures.
Also added a filter to the HWsettings update to prevent to block arming when actual settings have not changed.
+review OPReview
The module can be configured to enable what's needed from board voltage, battery voltage and battery current measurement.
In GCS the POWER box in system healt will show alarm related to the supply voltage to the board.
If a power warning/critical alarm is raised, the warning condition is left even if the board voltage return to an acceptable value.
Conflicts:
ground/openpilotgcs/share/openpilotgcs/diagrams/default/system-health.svg
shared/uavobjectdefinition/systemalarms.xml
After 3 failed warm start attempts, the init sequence
will force the RAM version of the HWSettings object
to its defaults. This should allow a user to regain
connectivity to a board that is continually faulting
during init.
This is accomplished by:
- Incrementing a boot counter that is stored in the
STM32 BKP registers. These registers survive a
warm start but are cleared on a cold start (ie. powerup).
- On multiple failures, force hwsettings to defaults
and raise the (new) BootFault alarm to prevent arming.
- Resetting the boot counter whenever the system manages
to successfully run the System Module task.
NOTE: This does not actually change the hwsettings object in
flash. That's up to the user.
This is intended to catch ONLY faults during early initialization.
It should not be used to recover from faults after the application
is up and running.
The UAVObject definition (.xml) files are used by both the
GCS build as well as the flight software builds.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2526 ebee16cc-31ac-478f-84a7-5cbb03baadba
