Mastering Embedded Safety Traps
Shawn A. Prestridge
Senior Field Applications Engineer
Agenda
• Company overview
• C in Embedded Systems:
What’s the problem?
• MISRA C
• The wonders of volatile
• Functional safety tools for ARM
• Summary
Providing developers of embedded systems
with world-leading software tools
Global professional technical
support in 9 languages
Large ecosystem of partners
10 offices worldwide
with HQ in
Uppsala, Sweden
Listed on
NASDAQ/
Stockholm
33 years
in the industry
32% of revenue
invested in R&D
Uppsala San Francisco
Munich Dallas
Paris
Boston
Tokyo
Los Angeles
+ Distributor
Seoul
representation
Shanghai
in 43 countries
Complete offering for ARM
Cortex-A15 Cortex-A9 Cortex-A8 Cortex-A7 Cortex-A5 Cortex-R7 Cortex-R5 Cortex-R4
Cortex-M7 Cortex-M4 Cortex-M3 Cortex-M1 Cortex-M0(+)
ARM11 ARM9 ARM7 SecurCore
•
•
•
•
Unique independence with support for all
available ARM cores, from all major vendors
including TI, Renesas, NXP, ST, Cypress, Toshiba
etc.
4,500+ supported devices in total
8,400+ example projects to enable quick start
Close cooperation with several SoC vendors
Take full control of your
development!
C-STAT:
Powerful static code analysis
C-RUN:
Runtime execution analysis
I-jet and I-jet Trace:
Debugging and trace probes
Why Use C for Embedded Systems?
•
Widespread knowledge of the
language
–
–
•
Widespread tool support for the
language
Many different compilers for
virtually any target
• Many middleware options
• Many static analysis tools
•
Virtually every developer knows C,
at least to some extent... 
Many languages are very similar to
C
•
Fairly close to hardware
You can abstract to a
higher level of interaction
with the hardware
• You can get all the way
down to writing bits to ports
•
So, what’s the problem?
The IEC61508 Standard
Table C.4.5 of the standard gives a description of a suitable language:
• The language should be fully and
unambiguously defined.
– There are ~190 undefined behaviors in C99
• The language should be user- or problemoriented rather than processor/platform
machine-oriented.
– Well...
• Widely used languages or their subsets are
preferred to special-purpose languages.
– OK, but not more than that later
And it goes on…
IEC61508-7 , Table C.4.5 continued:
The language should encourage:
• The use of small and manageable software
modules;
• Restriction of access to data in specific
software modules;
• Definition of variable subranges; and
• Any other type of error-limiting constructs.
IEC61508 standard
With the right C subset and use of
static analysis tools, C can be a
Highly Recommended standard
for all 4 levels of SIL.
MISRA C
MISRA C Definition
MISRA C stands for the Motor Industry Software
Reliability Association, a consortium based out
of Cambridge in the UK that promotes
standards to improve the safety and reliability of
embedded code.
More importantly, MISRA is:
• A C language subset
–
Takes out the undefined behavior of C
• Add your own coding standard
–
Cover deviations, modularization, variable range control etc…
Simple MISRA C Rules
•
No use of native primitive ("plain") types like int, float, char, etc.
–
–
•
Loops and conditional statements are required to have code blocks encapsulated in { }
if (exp) then { statement; } else { statement; }
–
•
The size and signedness of these types is different on sundry MCUs
Instead, use types like uint16_t that explicitly tell other developers the size and signedness you
intend
Code intended to execute with those statements is explicit
Implicit conversions are not allowed
unsigned int i = 1;
/* ? */
unsigned int i = 1u; /* Definitely intended to be unsigned */
MISRA C 2004 Rule 8.5
This rule states:
There shall be no definitions of objects or functions in a header file
File foo.h:
int myGlobal; //Creates an instance
//for each inclusion of foo.h!
Different linkers treat this differently... You might get multiple static copies of the variable!
Or multiple overlaying copies...which means a change of tool chain will probably create chaos!
MISRA C 2004 Rule 23
This rule states:
All declarations at file scope should be static where
possible.
Declaring a variable or a function static means it cannot be
seen or used directly by other modules in the application.
This rule:
• Prevents you from unintentionally exposing internal help
functions and file-local variables
• Forces you to really design the interface of new modules
• Makes the interface clearer, something very important as
applications become legacy and the person who wrote the
code may not be available to interpret it
MISRA C 2004 Rule 33
This rule states:
The right hand side of a "&&" or "||" operator
shall not contain side effects
There is nothing in the C language that prevents you
from writing code that looks like the following:
if ((x == y) || (*p++ == z))
{
/* do something */
}
MISRA C 2004 Rule 33
In this example:
• The right hand side of the || operator is only evaluated (and
its side-effects executed) if the expression on the left-hand
side is false—that is, if x and y are not equal
• In this example, the side-effect is to post-increment the
pointer p.
However:
• Even if this behavior is specified by the standard, it is still
easy to get it wrong when writing the code.
• Even if you manage to get it right, everyone that will ever
read or maintain the code must also understand the rules
and your intentions.
Using MISRA C in IAR
Embedded Workbench
The MISRA C checker is completely integrated with IAR C/C++
Compiler.
• 1998 and 2004 rulesets come with IAR Embedded Workbench
• The 2004 and 2012 rulesets and MISRA C++ 2008 are in C-STAT
The MISRA C dialog box is available in the Project Options dialog
box.
• Selecting your project in the Workspace window
• Clicking Project-Options
• Select the “General Options” category
• Go to either the MISRA 2004 or MISRA 1998 tab
What is C-STAT?
•
•
Complete static analysis tool
Includes:
–MISRA-C: 2004
–MISRA-C: 2012
– Improved version of the 2004 edition
–MISRA-C++: 2008
– 165 checks to address C++ specific issues
–Standard checks
– More than 200 additional checks for C and C++ to
address issues covered by CWE (common weakness
enumeration), CERT C coding standard etc.
– Categories like Array bounds, Arithmetic errors
– Support for export/import selection of checks
– Fully integrated in the IAR Embedded Workbench IDE
– Can also be invoked from command line and through Eclipse plugin
Runtime Analysis C-RUN
• Detection of data manipulation issues
during runtime
• Arithmetic, bound and heap checking
• Very efficient instrumentation of compiled
code
The wonders of volatile
Why use a volatile variable?
Several reasons to declare a variable as volatile:
• Shared access of the variable, such as between several tasks in a
multithreaded environment, ISR and main loop
• Trigger access of the variable, such as a memory-mapped SFR
where the fact that an access has occurred has an effect on the
variable
• Modified access of the variable, where the contents of the object
can change in ways not known to the compiler at compile-time
Declaring a variable as volatile tells the compiler to not perform
optimizations on the accesses to the variable.
Common Misconceptions About
volatile
Guarantees?
All accesses are preserved!
That’s it…
Often, you also get:
– All accesses are complete, that is, the whole object is accessed
– All accesses are performed in the same order as given in the abstract machine
– All accesses are atomic, that is, they cannot be interrupted.
• Only if the object is of a type that can be read/written atomically
• Know your object types!
Is It Atomic?
volatile int32_t vol = 1;
void f5()
{
vol++; /* Is this atomic? */
}
LDR.N
LDR
ADDS
STR
BX
R0,??DataTable7
R1,[R0, #+0]
R1,R1,#+1
R1,[R0, #+0]
LR
;;vol address
;; Atomic
;; ADDS…
;; Atomic
;; return
Functional Safety Tools for ARM
Functional Safety Tools
Validated according to IEC 61508 &
ISO 26262
Simplified validation
•
•
•
Functional safety certificate from
TÜV SÜD
Safety report from TÜV SÜD
Safety Guide
Guarantees support through the
product life cycle
•
•
•
Prioritized support
Validated Service Packs
Monthly report of known problems
www.iar.com/safety
Summary
Take it away!
•
•
•
•
•
Use MISRA C as the basis for a coding standard
Code analysis tools can help you find defects more quickly
Review your usage of variables declared volatile
Implement a test and analysis strategy for stack allocation
Use Functional Safety versions of your development tools
to speed your path to safety-certification
Questions?
www.iar.com
Thank you for your attention!