On Choose your Activation Type window, select one of the following options:

A reboot may be required to complete installation of the Wind River (Diab) compiler.

If using one version of the Wind River (Diab) compiler, either setup the OPENECU_DIAB_5_5_1_0 environment variable as described in the next point, or adjust Window's system path to include the absolute path to the compiler's bin directory.

If using more than one version of the Wind River (Diab) compiler (for instance, when you are using two or more versions of OpenECU which require different versions of the Wind River (Diab) compiler), the environment variable OPENECU_DIAB_5_5_1_0 must be set to the absolute path to the compiler's bin directory. This macro must terminate in a “\” and must use the DOS 8.3 short naming convention.

E.g., D:\Progra~1\diab\5_5_1_0\win32\bin\

Closed: incorrect generation of object code for “float <= float” comparisons.

The compiler incorrectly generates object code for “float <= float” comparisons, turning the comparison into “float > float”. This issue has been resolved by removing the -Xieee754-pedantic command line option to the compiler command line option to the build configuration files.

Open: incorrect generation of object code for long C functions.

The compiler incorrectly generates jump instructions in the object code if the jump destination address differs from the address of the jump instruction by more than 15 bits (signed). No warning or error is generated by the compiler. The result is a model which does not behave as expected when run on target (usually the ECU appears as if it is continually resetting).

To alert the user to this risk, an OpenECU build checks for large functions and issues a warning message if any are found. The message takes the form:

Warning: Function foo is very large (0x000abcdef).
The generated object code may be susceptible to a known compiler defect.
Refer to the OpenECU user guide for further details.

Workaround (Simulink): RTW generates just a couple of C functions for the model, rather than splitting major sub-systems into their own functions. Hence those functions can become large enough to hit this compiler problem if the model is large. This can be avoided by applying the atomic subsystem option to key subsystems in the model. RTW generates a different C function for each atomic subsystem, where each resulting function corresponds to just part of what would have been one large function. You should split any large model up like this to avoid any one C function becoming large enough to hit this compiler problem.

Open: generation of non-existent labels.

The compiler can generate non-existent labels such as ".L1013" when compiling code involving large structures, such as those generated by TargetLink. The code then fails to link because the labels are not defined. This has not yet been seen with Simulink builds but it may possibly be seen in future.

Workaround: if this problem is encountered, a patched version of the compiler is available from Wind River for customers who have compiler support (quote service request 1054126).

Open: incorrect rounding on conversion from float to integer types.

The compiler rounds values when converting from floating point to integer, e.g. from "float" to "signed long" (in terms of native types, otherwise known as F32 and S32 in the OpenECU environment). For example, 3.6 as a float is rounded to 4 as an integer, but the C standard requires that the fractional part is truncated, so a converted value of 3 would be correct. Similarly -3.6 is rounded to -4 instead of being truncated to -3. This defect is fixed in version 5.8.0.0 of the compiler.

Workaround: if this problem is encountered, a patched version of the compiler is available from Wind River for customers who have compiler support (quote service request 864470).

Closed: Can't use Simulink look up blocks

There has been a known issue which restricts the compiler to use Simulink lookup block. When using Simulink lookup blocks, the Diab compiler would stop compilation with this error message:

'[model-name].c', line [line-num]: warning (dcc:1792):
                                   trying to assign 'ptr to volatile' to 'ptr'

This has now been fixed, see F-CR 13325 in the release notes.

Closed: compiling the main model file can take a long time.

Small models compile in a short period of time, but once the code presented to the compiler exceeds a limit, the compiler takes a long time to compile the main model file (model-name.c).

Workaround: the compiler sets aside an amount of memory for the compilation phase and if the size of the model code exceeds the limit, the compilation slows down. This can be avoided by increasing the size of the compiler's buffer using a command line option. Add the pcomp_CompileOptions block to the model, set the mode parameter to Add to options and set the compiler options parameter to -Xparse-size=100000. If the compilation is still slow, increase the option value further.