init new proc:
Does some initialization that should only be done one time. Specifically:
--Finds the right size for MRAM etc (which wipes out previous contents).
--Initializes the values for things that are generally going to be tweaked on the bench, and not after the satellite is assembled, namely the default values of the 4 Rx frequencies, the Tx frequency
and the values of the high and low power.
++++Note that these values are at the early address of the MRAM, so if you add stuff to MRAM, these locations should not change.
--Does "clear mram" (see below)
preflight init
--Initializes all values in MRAM that want to be fresh when first launched. For example, Min/Max values, Epoch, time, startup state, autosafe voltages, frequency of saving WOD, etc. (Maybe some
of these are not relevant for PacSat)
--Initializes the MRAM version number. (See below)
--Probably by rights it should format the filesystem too. Right now, it zaps the MRAM so 'main' sees that the file system can't be initialized and formats it. A bit convoluted.
--Clears the "in orbit" flag so that the satellite code waits about 50 minutes after power on before transmitting or doing anything else other than waiting. This is so it can clear the Launch
Vehicle.
clear mram
--The same as preflight init, except that it SETS the "in orbit" flag. and starts right away.
Note on the "default frequency"
Currently the Rx default freqs are all the same. Fix in "IHUInitSaved", module nonvolManagement.c. I'd change from a do to 4 WriteMRAMReceiveFreq calls each with a different DCT_DEFAULT_RX_FREQ
(defined in config.h. Look for comment "AX5043 radio constants".
In the module "nonvolManagement.c" there are routines called ReadMRAMReceiveFreq (which takes an integer indicating the receiver number as an argument). This routine/macro reads the value
and its check value out of MRAM. If the checkvalue is wrong, it returns DCT_DEFAULT_RX_FREQ. Note that it does NOT write the default Rx frequency back. It would be best to arrange to return the defualt frequency for the specifiied receiver on error rather
than the generic frequency.
Note on "raise/lower rx freq" etc
These routines allow you to tweak (or more) the receive and transmit frequencies. You specify the amount you want to tweak by (example: "raise rx freq 10" raises the frequency by 10Hz. It will
be changed immediately for testing purposes, but it is not saved in MRAM until you give the command "save freq". If you do not issue 'save freq' the frequency will revert to the currently saved value on the next reboot. Please don't change the frequencies
anywhere else, or this whole scheme will be broken. You really need to be able to tweak frequencies on individual boards due to differing crystals, caps, etc, and you do not want to have to redo those tweaks each time you clear mram or preflight init.
Notes on the MRAM version number:
In MRAMmap.h, there is a #define for a version number (currently 6). This value should be changed anytime you change something in the MRAM map. It works by being written into the MRAM itself.
The flight software compares what is in the MRAM to what is MRAMmap.h and will complain frequently if they do not match. (This has saved me a number of times! Before I put this feature in I spent hours figuring out why something did not work, and it was
only because the MRAM was screwed up!) Either "clear mram" or "preflight init" updates the version number in MRAM, and of course puts stuff in its new location. Please do not comment out the prints that complain about the version number--you really do not
want to do any testing if the version number is wrong!
73,
Burns Fisher, WB1FJ
AMSAT(R)
Engineering -- Flight Software