Store the last TaskId in the RTC registers #2162
Conversation
We have an awkward problem where if some task is looping forever we are stuck and can't access anything except via SWD. There are some situatiosn (read racks) where we can't get dongle access. We already have a watchdog which is used for reset. The RTC block has a small set of backup registers that will not be reset so long as we don't lose power to VDD (i.e. don't ignition cycle). This makes our scheme: - Setup our RTC block and use registers 0 and 1 for our purposes - On context switch store the task ID into Register 0 - On bootup, copy the contents of Register 0 to Register 1 - In a separate task, set a timer to turn the watchdog off/on - Log the value of Register 1 to see what the last task ID that was running was
| @@ -170,7 +170,9 @@ pub(crate) fn event_timer_isr_exit() { | |||
| } | |||
|
|
|||
| pub(crate) fn event_context_switch(tcb: usize) { | |||
There was a problem hiding this comment.
I don't understand this change, unless it was broken before?
There was a problem hiding this comment.
The existing profiling just stores the base of the task, which is both fast and may have been fine for cliff's debugging (thanks again cliff for adding this). I was struggling to figure out how to go from task base to useful information so I did the calculation here. If we really hate this, we can get humility to do this work for us.
task/bork/src/main.rs
Outdated
| &mut self, | ||
| _mgs: &RecvMessage, | ||
| ) -> Result<(), RequestError<core::convert::Infallible>> { | ||
| loop { } |
There was a problem hiding this comment.
Nit: add cortex_m::asm::nop() here?
|
@labbott do we intend to eventually merge this change to master or is this just being used for the present debugging? |
I'm split. I don't think we want to use the SWD watchdog in production because that does automatic bank swap which is not what we want. I also think the hack to get the TaskID is, well, hacky. Longer term, it's probably time to actually add a watchdog task but that may require more discussions about how that should work for hubris. I do think we need some kind of debugging for last state before reset. So maybe once we figure out the current issue we'll have a better idea of what we wish we would have wanted. |
We have an awkward problem where if some task is looping forever we are stuck and can't access anything except via SWD. There are some situatiosn (read racks) where we can't get dongle access. We already have a watchdog which is used for reset.
The RTC block has a small set of backup registers that will not be reset so long as we don't lose power to VDD (i.e. don't ignition cycle). This makes our scheme: