Currently there's an infinite loop in the Motor Control component that blocks the main (idle) task when MC I2C comms fails. This should timeout and send an event. This is critical because this would be pretty bad during surface ops (esp. without #148 ) so this needs to be fixed soon since the final upload op is rapidly approaching.
Bug was induced simply by running the mc-spin-all command alias.
Ideally, MotorControl should be an async component with this as a relived loop.
NOTE: This problem was only observed on a test SBC, where it's possible that not all of the MC MSP430s were programmed, leading to no I2C response, leading to the loop.
NOTE: If this halt does happen, it will likely stop telem because it will block the Idle task that sync FPrime components run in (since MotorController is sync) but this likely won't block the ability to reset Hercules since comms tasks and Watchdog Interface are async. So, this failure is likey recoverable (i.e. lower priority), though this should be tested.
Currently there's an infinite loop in the Motor Control component that blocks the main (idle) task when MC I2C comms fails. This should timeout and send an event. This is critical because this would be pretty bad during surface ops (esp. without #148 ) so this needs to be fixed soon since the final upload op is rapidly approaching.
Bug was induced simply by running the
mc-spin-allcommand alias.Ideally,
MotorControlshould be an async component with this as a relived loop.NOTE: This problem was only observed on a test SBC, where it's possible that not all of the MC MSP430s were programmed, leading to no I2C response, leading to the loop.
NOTE: If this halt does happen, it will likely stop telem because it will block the Idle task that sync FPrime components run in (since
MotorControllerissync) but this likely won't block the ability to reset Hercules since comms tasks and Watchdog Interface areasync. So, this failure is likey recoverable (i.e. lower priority), though this should be tested.