Expected meeting w/ Navtaj @ 9/24/2025

• Reset handling
  • Are we going to do any handling in BL
    • e.g. freeze in BL to be able to send commands based on reset type
    • Check for boot times/number of resets
      • App sets flag after a minute, BL checks if flag is set
  • Are we likely going to do any handling
  • The reset register gets cleared in the startup code under the interrupt vector. TI forums say to use the FEE (emulated eeprom) to store the reset reason inside the startup code.
    • Is there a need to move it into FRAM in either BL or App
      • If yes, probably move the reset reason to FRAM in the App nd not BL?
• State Manager revamp
• Task priorities/frequencies
  • Which tasks are expected to run periodically? Only GNC mgr?
    • implications for thermal mgr if rtc/comms/bms dont run periodically
  • Too many periodic tasks?
    • Should we rlly cause a watchdog reset when any of these timeout
      • Like what if comms manager has some important events in its q but watchdog just times out cuz some driver fn failed on a periodic task
        • Ig shouldn’t be too big of a problem as most of our driver fns don’t block infinitely
• I assume EPS is a periodic task for MPPT - how often should it run?
  • It should have sufficient time to see how the last change effects the power
• Thermal mgr
  • Above + how to signal to read temp to other tasks
    • Thermal mgr sends signal to other tasks to read temp?
      • Only needed for cc1120
        • Should be fine as long as the task for reading the cc1120 temp is higher prio than thermal mgr
    • Other tasks read temp nd update mailbox periodically
      • Tasks would have to periodically read temps for this (nd the other tasks would need to run faster than thermal mgr)
      • Use shared val (struct)
    • I think what we should do is thermal mgr sends task to other tasks queues to read and update the temp in their respective mailboxes
      • Part of the handling for that event in other temp’s tasks is to send an event to thermal mgr that their mailbox temp values are updated and thermal mgr then reads those values
      • No need for this if tasks reading temp are periodic, update their mailboxes nd run quicker than thermal mgr
      • Would be hard to time properly if thermal mgr is periodic
• SD card sun data
  • Do we need to do research into issues that radiation/overuse may cause
    • If sun data gets heavily corrupted, it would be catastrophic for ADCS
      • We have no way to uplink sun data
      • I inquired if we could add coarse sun sensors to replace the required sun data but mech + elec said that it would be extremely challenging design wise for them
      • Other issues that prevent reading from sd card might lead to mission cookery