timburke
commented
10 years ago The last 2 commits should make the MoMo much more robust. First we remove the likely offender of filling the taskloop by having scheduled tasks not rampantly readd themselves when they are scheduled if the previous invocation of themselves has not run yet. This will prevent any single scheduled task from filling the taskloop.
Second, if the taskloop does fill, we log an error and reset the controller This is the only sensible course of action to take in this case since nothing is guaranteed to work anymore because almost everything requires adding tasks to the task loop. This should make the controller much more robust against this issue.
amcgee
There is a potential issue in the handling of flash memory reads and writes. The routines that actually communicate with the flash chip were not protected from interrupts. This means that they could be interrupted in the middle of sending a command to the flash chip. This could be a source of issues and I had noticed in the past that sometimes modtool reflash or modtool push would take a variable amount of time to send the same file (sometimes >2x faster than others).
This PR create two new functions (since the old macros only work for up to ~15000 cycles due to a limitation of the built-in disi instruction) and uses them to protect all memory routines that directly interact with the flash chip.
This change fixes the issue with variable modtool push and pull times as well at least I have not been able to reproduce the old variable behavior with this change.