In Simulink's Autosar generated code, the IRV interface is executed with `irv_write` first, followed by assignment, which causes `irv_write` to have an incorrect value.

See the attached code for details. In the mainfunction function, line 85 is generated first, and it is a temporary variable.

Rte_IrvWrite_Dgp_MainFunction_10ms_Runnable_dgp_irv_veh_running_flg_b(tmp_Switch_njm0);

It was then assigned a value on line 129.

tmp_Switch_njm0 = ((41943U * (uint32)tmp_tmpRead) > 12582912U);

This caused the 10ms task to consistently set `dgp_irv_veh_running_flg_b` to 0, leading to the incorrect use of this 0 value in subsequent operations.

Why does the automatically generated code perform `Irv_write` before assigning the value?

This issue also occurred with several other IRV interfaces in the model, only some of which generated global variables that masked the problem.

Version: Matlab R2023b

We look forward to your explanation of the cause and proposed a solution. Thank you.

[Tang]

Answer 1

[Ayush]

Hi Tang,

I understand you're seeing an issue where the generated code writes to the IRV before the correct value is assigned, which leads to incorrect values being used downstream.

This might be happening because the data dependency between the calculation and the IRV write isn't clearly defined in the Simulink model. When the execution order or data dependencies are ambiguous, the code generator can sometimes schedule the IRV write before the value is actually set, causing it to use a default or previous value. This behavior can occur if the model structure doesn't enforce a strict calculation-before-write sequence.

You can refer the following documentation to understand more about Simulink execution order:

https://www.mathworks.com/help/releases/R2023b/simulink/ug/controlling-and-displaying-the-sorted-order.html

Hope, this helps.

If the issue still persists, you should contact MathWorks Technical support at:

https://www.mathworks.com/support/contact_us.html