Interrupt Handling

An interrupt signals a change of state in peripherals and can be used to alter program execution. Embedded applications use interrupts, e.g. to respond to events in real-time. It is, therefore, important that a system can detect errors in the interrupt functionality. Specifically, Class B applications should be able to detect whether an interrupt is not being executed as often as expected (or not at all).

The chosen method is time-slot monitoring with the Real-Time Counter (RTC, clock independent from the CPU clock). In short, any interrupt to be monitored has to increase a counter every time it is executed. The RTC generates an interrupt periodically where the interrupt counters are checked. If any counter is outside an interrupt-specific configurable range, the error handler is called.

The interrupt monitor checks the frequency of those interrupts that are both registered and activated. Registering an interrupt means to give the interrupt monitor the following information on the interrupt to check: identifier, expected frequency, and deviation tolerance. The interrupt monitor creates a data structure with this information. Activating an interrupt means to tell the monitor that it should start checking a registered interrupt to be monitored: The interrupt monitor can be turned ON and OFF for individual interrupts using a state variable for each registered interrupt. The possible transitions between states are shown in Figure 1.
Figure 1. Interrupt States
The default state, for any interrupt, is OFF and in this state, the interrupt manager does not check the frequency of the interrupt. The state of the interrupt should be set to ENABLE when the main application wants the monitor to start checking the interrupt frequency. The next time the interrupt monitor is executed, it will then change the interrupt state to ON. This ensures that the interrupt counter is synchronized with the interrupt monitor. The interrupt counter starts being increased exactly after a single period of the interrupt monitor. Similarly, if the main application decides that an interrupt should not be monitored anymore, the interrupt state should be set to DISABLE. The interrupt monitor will change the state to OFF the next time it is executed.
Note: There should only be one enable/disable request per RTC period.

The implemented interrupt monitor has two features that further increase the robustness of the main application. The first one is an interrupt counter that increases only if the interrupt is ON, and therefore the counter should be zero while an interrupt is OFF. This is checked by the interrupt counter for all registered interrupts. Otherwise, the error handler is called. The second feature is that enabling an interrupt that is ON or disabling an interrupt that is OFF will call the error handler if the constant CLASSB_STRICT is defined.

The RTC calls the interrupt monitor function periodically. All registered interrupts are processed according to their state. Active interrupts are checked for their frequency. If there is no error, the interrupt monitor resets the counter. If an error is found the error handler is called and the monitor ends immediately (this is configurable). The counter of inactive interrupts is compared to zero for coherence. If the main application has requested to activate an interrupt, its state is set to ON and vice versa. Note that when the state is OFF the interrupt counter is set to zero.

In order to monitor an interrupt the following steps should be followed:

  1. 1.The interrupt should be declared in classb_int_identifiers by providing an identifier to the interrupt.
  2. 2.The main application has to register the interrupt by calling classb_intmon_reg_int(). A structure is then created for the interrupt.
  3. 3.The RTC has to be set up to generate an interrupt periodically and to call back the interrupt monitor.
  4. 4.The interrupts that have to be monitored should call classb_intmon_increase() on each execution.
  5. 5.The main application has to request that the monitor starts checking the interrupt. This is done by changing the interrupt state to ENABLE with classb_intmon_set_state().
  6. 6.If at some point an interrupt should not be monitored anymore, the main application can change the state to DISABLE.

In the example application, a Timer/Counter (TC) is set up to generate an overflow interrupt periodically, which is checked by the monitor. In addition, the application sets up two button interrupts. The first one changes the frequency of the TC interrupt. The second one deactivates the interrupt in the monitor. An LED is switched ON to show that the application is working correctly. The application stays in a loop with the LED ON as long as the buttons are not pressed. If the first button is pressed, the frequency of the TC interrupt will change, and the monitor should set the error flag. The main application will then leave the loop and switch the LED OFF. The second button can be pressed in order to deactivate the TC interrupt in the monitor. In this case, pressing the first button still leads to a change in the frequency of the interrupt but the monitor will not generate an error.

The interrupt monitor relies on a working RTC. The RTC also supports the CPU frequency tests and it is checked in the related software modules. It can, therefore, be assumed that there is no failure in the RTC. In order to increase the reliability of the application, registered interrupts could have a maximum value of the counter, which could be tested within the interrupt. If the counter reaches this value, it can then be assumed that the interrupt monitor is not working.

The monitor can be tested in different ways.