To start with: My [Bruce] original email
During running it's quite likely a ROD will go busy at some point. It happened earlier today, a module went into an as yet undiagnosed state. I was able to find which module was causing the busy by directly reading the formatter error bits and turning the module off... (I need to implement a mask module method).
So, how to notice a busy and what to do when one occurs? I think RCD has a system for masking a ROD from a crate when it exerts busy, but we should be able to find which link on a ROD to do something with.
- ) SBC polls TIM busy mask and investigates the registers on any ROD that stays busy (read the latch register and the monitor register).
- ) DSP polls ROD registers and does something
- First, how to do polling:
- ) Read RRIF_STATUS_0 on each pass of the main loop (is there anything else to watch?)
- This would be for Slink problems
- RRIF_STATUS 1 has busy limit flags for A & B
- ) Add a new monitoring task to MDSP (sounds a bit heavy-weight)
- ) something else
- ) Read RRIF_STATUS_0 on each pass of the main loop (is there anything else to watch?)
- Then what should it do:
- ) Sends text buffer message asking SctApi to investigate
- ) Copies formatter error flags to memory (as they clear on a read)
- ) write text buffer mentioning which link(s) is causing problems and why
- ) turn off link in formatter
- ) check that ROD busy now not asserted
Maybe both SBC and MDSP should poll, as the TIM latch register will show up brief ROD busies and I suspect RRIF_STATUS_0 won't. Then SBC can read the formatter registers to see what happened (and clear them for next time).