Need top-down review of interrupt preemption, priorities, and driver in general

[Nathan-Stohs]

This has been sloppy since the start. We are probably doing some horrifying things.

Also the whole interrupt driver needs a refactor. Functionality is fine, but its not so easy on the eyes.

[MichaelAtSamraksh]

I feel like I've been saying interrupt priorities and groups need examined for over a year now and each time I've been told it wasn't an issue. Nathan, what caused the change of heart? We all know that the TinyCLR software interrupt architecture is loop-based and thus it is not compatible with always-enabled interrupts, but we still can have control over their order of execution without abandoning the existing structure. I would love to work on this issue.

[Nathan-Stohs]

What bothered me is that I just noticed interrupt pre-emption is fully active, and I have serious concerns about our thread safety model with it on. I think it should just be disabled, with the exception of the RTT. But that change has large scope, so I'd assume someone would have to shepard it through.

It is still the case that simple priorities don't concern me so much. I don't see a real win there. My interest in preemption is the correctness issue.

[MichaelAtSamraksh]

NVIC has groups and priorities. There is no preemption if all interrupts are in the same group. I thought they were all in the same group/ the settings were okay. I thought TinyCLR runs most of the time with interrupts disabled until it was ready to check interrupts during the HAL loop; certainly during Global Lock the interrupts are disabled, and Global Lock is supposed to be during all critical sections. Our problem before was that Nived had made Global Lock enable interrupts as it exited each level of nesting instead of remaining locked until popping the final lock, and in that case there would be preemption during critical sections. But I fixed Global Lock earlier this year, and interrupts remain off until the last lock exits. So what setting allows preemption during critical sections? We have three bits to play with; I thought every interrupt was running in the same preemption priority group with the same sub group priority. Changing the sub group priority only affects order of execution within that group, not preemption of other group members, right?

• Locks over critical sections work
• Non-reentrant IRQ handlers have global locks around them
• CLR executes with interrupts disabled to prevent C# preemption
• Interrupt priorities are set to make everybody the same priority group which means no preemption and no nesting

These should be enough to start constructing a proof that there is no current problem. What is interesting is when we have an intuition that the .NOW is unresponsive to interrupts. In that case, I have advocated in the past that we move the COM handler to a higher priority, simplify its design to only fill a buffer, and add software locks around the buffer, to allow the COM handler to jump in and fill a buffer without touching anything, then change Global Locks to change the base priority instead of disabling the interrupts, so that we are actually running most of the time with all interrupts except COM disabled... That's the kind of "let's measure and engineer a solution for interrupt priorities" that I've tried to advocate in the past when we've had COM response problems, and should probably be part of the RealTime code.

P.S. Steve Maillet also thinks the interrupt architecture for TinyCLR is broken when presented with the options on ARM Cortex processors.

[Nathan-Stohs]

I don't know that we actually have a problem, and given how much you've looked into it already, maybe we don't. I think what we really need is some additional confidence (especially given that the interrupt driver is our oldest code, and everything else to date has gotten a pass or two).