15-01-2008, 10:34 AM
Embedded control software contains many things outside the scope of the language.
Interrupt Service Routines (ISR) are an example of code which IS reachable, but outside the definition of C. Compliers often have extensions like \"__interrupt\" to flag this.
Defining code for ALL ISRs is a good idea.
Within the file that the ISR is defined, it will appear to be an external function.
Across all files in the system, ISRs may appear to be uncalled global functions, although they may be referenced by the code which sets up the vector of ISRs.
Is there a MISRA Rule which bans uncalled global functions?
Another practice is to place trap code in unused ROM. Should the program counter be corrupted to point into unused ROM, the unused ROM contains NOP (no-operation) instructions and is incremented thru until the trap is reached. This is particularly useful if having reset, it is not possible to determine the cause. The trap could store the cause prior to the reset.
Examination of the assembler and/or final memory image is required to confirm correct build.
I treat this rule as being limited to statements withinin functions which are unconditionally bypassed by preceding statements. The examples in the exemplar suite appear to support this view.
George
Interrupt Service Routines (ISR) are an example of code which IS reachable, but outside the definition of C. Compliers often have extensions like \"__interrupt\" to flag this.
Defining code for ALL ISRs is a good idea.
Within the file that the ISR is defined, it will appear to be an external function.
Across all files in the system, ISRs may appear to be uncalled global functions, although they may be referenced by the code which sets up the vector of ISRs.
Is there a MISRA Rule which bans uncalled global functions?
Another practice is to place trap code in unused ROM. Should the program counter be corrupted to point into unused ROM, the unused ROM contains NOP (no-operation) instructions and is incremented thru until the trap is reached. This is particularly useful if having reset, it is not possible to determine the cause. The trap could store the cause prior to the reset.
Examination of the assembler and/or final memory image is required to confirm correct build.
I treat this rule as being limited to statements withinin functions which are unconditionally bypassed by preceding statements. The examples in the exemplar suite appear to support this view.
George