Fix Model Design Issues Found as Run-time Errors and Coding Rule Violations in Generated Code

After testing your Simulink^® model for standards compliance and design errors, you can generate code from the model. Before deployment, you can perform a final layer of error checking on the generated code by using Polyspace^®. The checks detect issues such as dead logic or incorrect code generation options that can remain despite tests on the model.

Prerequisites

Before you run Polyspace from Simulink, you must link your Polyspace and MATLAB^® installations. See Integrate Polyspace with MATLAB and Simulink.

To open the model used in this example, at the MATLAB Command Window, run:

openExample('polyspace_code_prover/FixIssuesInGeneratedCodeFoundWithPolyspaceCodeProverExample')

Open Model

This example uses:

Open Model

The model CruiseControl_RP contains a Stateflow chart with design issues. The issues translate to possible run-time errors or unreachable branches in the generated code.

Detect and Fix Run-Time Errors

Detect Run-Time Errors

On the Polyspace tab, click anywhere on the canvas. The Analyze Code from field shows the model name. If you use Embedded Coder^®, then click Run Analysis. If you use other code generating tools, manually generate the code before starting a Polyspace analysis.

For more information, see Run Polyspace Analysis on Code Generated with Embedded Coder.

After the analysis is complete, the Code Prover results open in the Polyspace user interface. The results contain gray checks (unreachable code) and orange checks (potential run-time errors).

Fix Gray Checks

Select one of the two Unreachable code checks. Review the code that is unreachable.

            if ((CoastSetSw_prev != CruiseControl_RP_DW.CoastSetSw_start) &&
                CruiseControl_RP_DW.CoastSetSw_start &&
                (CruiseControl_RP_Y.tspeed > (real_T)mintspeed)) {
              /* Transition: '<S1>:74' */
              CruiseControl_RP_DW.is_ON = CruiseControl_RP_IN_Coast;
              CruiseControl_RP_DW.temporalCounter_i1 = 0U;

              /* Entry 'Coast': '<S1>:73' */
              CruiseControl_RP_Y.tspeed -= (real_T)incdec;
            }

Click the Transition:'<S1>:74' link in the if block. The transition is highlighted in the model.

Stateflow transition related to the unreachable code is highlighted in the Stateflow chart.

Note the design flaw. The condition for outgoing transition 3 cannot be true without the condition for outgoing transition 2 also being true. Therefore, transition 3, which executes later, is never reached. This design flaw in the chart translates to the unreachable if block in the generated code.

One possible solution of the issue is to switch the execution order of transitions 2 and 3. To begin, right-click transition 3.

After switching the execution order, regenerate and reanalyze the code. You no longer see the gray Unreachable code checks.

Fix Orange Checks

Select one of the two Division by zero checks. Review the code.

if (CruiseControl_RP_DW.temporalCounter_i1 >= (uint32_T)(incdec /
               holdrate * 10.0F))

Place your cursor on the variable holdrate. You see that it is a global variable whose value can be zero.

The fact that holdrate is a global variable hints that it could be defined outside the model. Open the Model Explorer window. In the model hierarchy, choose the base workspace. Find holdrate in the list of parameters. You see that holdrate has a value 5, but the value can range from 0 to 10. The Code Prover analysis uses this range and detects a division by zero.

You can modify either the generated code or the analysis configuration:

Modify code:
In the Model Explorer window, change the storage class of holdrate from Global to Define. The generated code defines a preprocessor directive stating that holdrate has the value of 5.
```
#define holdrate 5
```
Modify analysis configuration:
On the Polyspace tab, select Settings. Modify the optionTunable parameters to use the calibration data. The Code Prover analysis uses the value 5 for holdrate instead of a different value in the range 0 to 10.

If you regenerate and reanalyze the code, you no longer see the orange Division by zero checks or any other orange checks that have the same root cause. The Dashboard pane shows that the checks are green.

Check distribution pie chart on the Dashboard pane showing that all checks are green.

Detect and Fix Coding Rule Violations

Detect MISRA C:2012 Violations

To detect MISRA C™ violations:

In the Mode section of the Polyspace tab, select Bug Finder.
Select Settings to open the Simulink Configuration Parameters window. In the Settings from menu, select Project configuration and MISRA C 2012 checking.
Start the analysis by clicking Run Analysis.

Fix MISRA C:2012 Violations

After running the Bug Finder analysis, Polyspace reports the violations of MISRA C:2012 in the generated code. To fix some of these violations, you might need to modify the model. Consider the violation of rule 3.1:

The character sequences /* and // shall not be used within a comment.

Two of the violations is located in this code on the declarations of RES and SET:

typedef struct {
  uint8_T CC_Mode;                     /* '<Root>/CC_Mode' */
  boolean_T RES;                       /* '<Root>/RES//+' */  
  boolean_T SET;                       /* '<Root>/SET//-' */
  real_T SpeedSet;                     /* '<Root>/Speed_Set' */
  real_T SpeedAct;                     /* '<Root>/Speed_Act' */
  boolean_T Break;                     /* '<Root>/Break' */
} ExtU_CruiseControl_RP_T;

In these statements, you see two instances of // in the code comments in the structure definition.

To navigate to the corresponding location in the model, click '<Root>/RES//+' in the code comment. You see that the comment comes from the input variable RES/+, which contains the / character.

Input block related to MISRA C:2012 violations is highlighted in the model.

Rename the variables RES/+ and SET/- so that they do not use the / character. When you reanalyze the code, you no longer see violations of rule 3.1.