Rules:
6.5.a. Interrupt service routines (ISRs) are not ordinary functions. The compiler must be informed that the function is an ISR by way of a #pragma or compiler-specific keyword, such as “ interrupt”.
6.5.b. All functions that implement ISRs shall be given names ending with “_isr”.
6.5.c. To ensure that ISRs are not inadvertently called from other parts of the software (they may corrupt the CPU and call stack if this happens), each ISR function shall be declared static and/or be located at the end of the associated driver module as permitted by the target platform.
6.5.d. A stub or default ISR shall be installed in the vector table at the location of all unexpected or otherwise unhandled interrupt sources. Each such stub could attempt to disable future interrupts of the same type, say at the interrupt controller, and assert().
Example:
#pragma irq_entry
void
timer_isr (void)
{
uint8_t static prev = 0x00; // prev button states
uint8_t curr = *gp_button_reg; // curr button states
// Compare current and previous button states.
g_debounced |= (prev & curr); // record all closes
g_debounced &= (prev | curr); // record all opens
// Save current pin states for next interrupt
prev = curr;
// Acknowledge timer interrupt at hardware, if necessary.
}
Reasoning: An ISR is an extension of the hardware. By definition, it and the straight-line code are asynchronous to each other. If they share global variables or registers, those singleton objects must be protected via interrupt disables in the straight-line code. The ISR must not get hung up inside the operating system or waiting for a variable or register to change value.
Note that platform-specific ISR installation steps vary and may require ISRs functions to have prototypes and in other ways be visible to at least one other function.
Although stub interrupt handlers don’t directly prevent defects, they can certainly make a system more robust in real-world operating conditions.
Enforcement: These rules shall be enforced during code reviews.