Configuration of Representable Features

Configuring BSW modules follows the general MICROSAR stack approach. For general settings, see the Technical References and help of the BSW modules. This chapter provides special hints and details on representable features (see Representable Features) that need special attention when you use them with vVIRTUALtarget.

Background Tasks

You can configure some functions as background tasks, for example, the FEE main function. The execution environment detects background tasks that do not advance simulation time and stops the processing core. If needed, you can avoid this by implementing a user callback.

Background tasks are generally tricky to virtualize because, by definition, they consume all remaining computing capacity of the virtual CPU. Since vVIRTUALtarget has no knowledge of the target CPU, it cannot quantify that remaining computing capacity. Therefore, you must explicitly annotate time consumption in the code. Call the function VttPlatformEmu_ConsumeTime() or VttPlatformEmu_ConsumeTicks() at least once within each cycle of the background task to consume and thereby advance simulation time. If the application implements the background task, you can add VttPlatformEmu_ConsumeTime() directly.

If the RTE implements the background task, you can inject the VttPlatformEmu_ConsumeTime() call using the following pattern, for example. This pattern is useful because the RTE won’t overwrite your manual changes each time it generates code.

Injecting VttPlatformEmu_ConsumeTime via a Generated Runnable

  1. Go to DaVinci Developer Classic.

  2. Add a new runnable called Background_Runnable to one of your software components.

    DaVinci Developer Classic - Add Background Runnable with Background Trigger
    Figure 1. DaVinci Developer Classic - Add Background Runnable with Background Trigger

  3. Switch to DaVinci Configurator Classic and synchronize the configuration.

  4. Map the Background_Runnable and all configured background functions (for example, Fee_MainFunction) to your background task.

  5. Implement the runnable so it calls VttPlatformEmu_ConsumeTime().

FUNC(void, RTE_APPL_CODE) Background_Runnable(void)
{
#ifdef VVIRTUALTARGET
  VttPlatformEmu_ConsumeTime(1000000);
#endif
}

The parameter 1000000 is an example value that denotes the number of nanoseconds the virtual CPU spends in the simulated busy state. Adjust this number carefully to get a realistic ratio between computing time spent on background and non-background tasks.

A lower number causes more iterations inside the background task, while a higher number results in fewer iterations. From a simulation performance standpoint, choose the highest possible number: this results in fewer background task invocations and therefore less host CPU load.

Note that small numbers severely impact performance. Even well-chosen numbers may still impair performance. So, reconsider whether the virtual target really needs a background task. For example, disable a background task for measuring CPU load on the virtual target, because it would not work there anyway.

For a detailed description of how to influence the timing behavior of a vECU, see the ECU Timing Control section in the vVIRTUALtarget Help.

Handling Different MCU Clock Offsets

AUTOSAR does not specify the handling of the ClockSettingsConfig parameter. Some MCAL modules use the value of this parameter with an offset of 1 while other MCAL modules start with 0.

VTTMcu uses 0 as the offset. If the hardware MCU uses 1 as the offset, you must make sure that you call Mcu_InitClock with the correct offset value. To adapt the code accordingly, you can use a VTT macro, see Code Integration in Dual-Target Projects.

For example, in EcuM_Callout_Stubs.c, switch the (different) value(s) of the Mcu_InitClock argument using #ifdef.

NvM Block Length Strict Check

The NvM Block Length Strict Check verifies whether each NvMBlock (container /MICROSAR/NvM/NvMBlockDescriptor) has the exact same size as the corresponding variable the compiler generates. Because the variable’s size heavily depends on the compiler and its options, no single value works for both the embedded compiler and the host compiler. Therefore, do not enable Block Length Strict Check in Dual-Target projects. Instead, set the parameter

/MICROSAR/NvM/NvMBlockDescriptor/NvMNvBlockLength

to the maximum of the values required by either compiler. If you enable NvM Block Length Strict Check in DaVinci Configurator Classic, the resulting code might not compile.