A prototype that works on the bench is not the same as firmware that is ready for series production. For safety-relevant products, standards such as IEC 61508 and ISO 26262 expect a defined coding standard – and in embedded C that usually means MISRA C. We recently took the firmware of a safety-relevant product through exactly this step. Here is how we approach it.
Why MISRA C matters
C leaves a lot to the compiler: implicit type conversions, undefined and implementation-defined behaviour, pointer arithmetic. MISRA C turns these risks into checkable rules. Code that follows them is more predictable, easier to review and easier to argue in a safety case.
MISRA C:2012 sorts its guidelines into three categories:
| Category | Meaning |
|---|---|
| Mandatory | Must be followed – no deviation allowed |
| Required | Must be followed unless a formal, justified deviation is documented |
| Advisory | Recommended good practice |
Our approach in five steps
- Baseline. Configure the static analyser for MISRA C and run it on the complete code base. The first report is usually long – that is normal.
- Triage by risk. Separate real defects from style. Undefined behaviour, unchecked return values and dangerous conversions come first; readability findings later.
- Fix in small, reviewable steps. Each change is linked to its finding and reviewed. The product has to keep working after every step.
- Document deviations. Where a required rule cannot reasonably be followed – for example in hardware access code – the deviation is justified and documented, not silently ignored.
- Keep it clean. The analysis becomes part of the build, so new code does not bring old problems back.
Typical findings
- Implicit conversions between signed and unsigned types or different widths
- Return values of functions that are never checked
switchstatements without adefaultbranch- Side effects hidden in conditions or macros
- Recursion or dynamic memory in code that must have bounded resources
- Unused code and variables that make reviews harder
None of these is exotic – but in a safety-relevant product each of them is a question an assessor may ask.
Plan it before the series launch
MISRA work is cheapest early and most expensive just before series production, when every change needs a new round of testing. If the launch date is fixed, start with a baseline analysis now: it shows how big the task really is.
Firmware Code Review
MISRA analysis, architecture and testability review of one firmware component – with a prioritised list of findings and concrete fixes.