Why do I get an error stating that recursion is prohibited in Simulink Design Verifier 1.7 (R2010b)?

I try to run the Simulink Design Verifier on my Simulink model and I get an error that there is some recursive function in the Stateflow chart. I would like to know why is there a recursion in a Stateflow chart in my Simulink model.

The following is the output of the Simulink Design Verifier Compatibility Check (note that the names of the model and the chart events may vary):

Checking compatibility of model 'FireControlProcess_v2'

Compiling model... done

Checking compatibility...

Errors occurred during translation:

Please refer to the diagnostics window for more information.

'MyModel' is incompatible with Simulink Design Verifier.

Translation failed: Error reported by S-function 'sf_sfun' in 'MyModel/ SFunction ':

Errors occurred during codegen

Call cycle detected among the following functions: Chart 'MyModel/FCP_Logic_04' (#18), Local Event 'disarmed' (#377), State 'warning' (#160), Local Event 'lockout' (#385), Local Event 'reset' (#378), Local Event 'NotLnchng' (#383), and Local Event 'Reset_TOF_Timer_Flag' (#384).

Recursion is prohibited in Simulink Design Verifier.

Answer 1

[MathWorks Support Team]

Recursive behavior in Stateflow charts can come from the following sources:

1. Graphical functions calling each other recursively (i.e., f() calling g() calling h() calling f(), or simply f() calling itself).

2. The second case comes from local events in a chart. Stateflow has a top-down semantics which means, the chart activity function invokes it's child state function which in turn invokes it's child's state function and so on. When one of the states in a chart make an "undirected" local event broadcast, this causes a child state function to recursively call the chart

function. Hence, "undirected" local event broadcasts using the syntax "E" or "send(E)" will almost always cause recursion in the chart as the events are likely to be parented by the chart. The best way to avoid recursion is to make sure that local events are broadcast using the following rules:

(a) Only use directed broadcast syntax "send(E,S)" where E is the local event and S is the destination state that you want to wake up using this event.

(b) If the source of the event broadcast is on a state action, then make sure that the destination state is NOT an ancestor of the source state in the chart hierarchy.

(c) If the source of the event broadcast is on a transition, then make sure that the destination state is NOT an ancestor of the transition in the chart hierarchy. In addition, make sure that the transition is not connected to the destination state.

3. The third case comes from "implicit" events in a chart (entry, exit and data change events). Once again, you need to make sure that the source of the event broadcast and the destination of the event broadcast do not have a child-ancestor relationship.

These rules give us the following "best practice" for local event broadcast:

The only time it makes sense to use local events is when you want one parallel state to effect a state transition in a sibling parallel state. This can always be done using the directed event broadcast to the sibling parallel state. This is not only not recursive, it will also be efficient.