To download the PDF version click here: AN_DiagCalib.pdf

Introduction

Scope

This application note describes how to calibrate diagnostic parameter using RTA-BSW 3.1 and INCA. The document contains the list of parameters that can be calibrated with the RTA-BSW. The application note project is based on a RTA Starter-Kit TC264.

Assumptions

You must have the following ETAS software installed:

• ISOLAR-AB 4.0.2
• RTA-BSW 3.1
• INCA 7.2

This application note could be used as a reference for any generic AR based project.

Diagnostic calibration

In order to calibrate a specific parameter of Dem, there are some steps to follow:

1. Modify the module specific MemMap file to allocate the parameter in the correct memory area
2. Modify the linker script of the target in order to dispose the correct sections in memory
3. Modify the A2L of the ECU adding the information about the parameter that needs to be calibrated
4. Use a measurement and calibration tool to proceed with the parameter calibration

In this chapter the first three steps are described, and the objective is to provide the general strategy that shall be used to calibrate a parameter. The specific focus is on the calibration of diagnostic parameters.

In the last chapter "Supported Diagnostic calibrations in RTA-BSW" you will find details on how to calibrate every specific diagnostic parameters currently supported in RTA-BSW.

Please notice that the example shown in this application note is based on Hightec compiler for Tricore. There may be differences in case of usage of different compilers/targets.

RTA-BSW MemMap files

In this section we describe what is the content of the MemMap file associated to the RTA-BSW modules and how to modify these files in order to have the desired mapping of the variables and code in the memory.

Every RTA-BSW module has a generated MemMap file into the Integration folder. For example, for the Dem module DemCfgMemMap.h is generated. <These files contain module-specific memory mapping definitions and allow to map the module memory sections to ECU-specific memory sections.

An example of the content of the Dem MemMap file is shown in the screenshot below. As you can see, there is the definition of two macros, DEMSTARTSECRAMINIT and DEMSTOPSECRAMINIT.

Figure 2.1: Example of content of Dem MeMmap file

Analyzing the file, you can notice that there are always a "Start section macro" and an "End section macro" for every section defined. Every element which is surrounded by these macros, will be included into that specific section. Since the MemMap files are part of the integration code, the integrator is free to modify the content of the file in order to define in which part of the memory the elements of the module will be allocated.

For example, let's suppose we want to calibrate an already configured DTC changing its code value. As will be detailed in the chapter "Supported Diagnostic calibrations in RTA-BSW", the DTC value is defined in the BSW as a constant variable in the ROMCONST section. The variable which contains all the code values is *"DemAllDTCsParam32"*, therefore this is the one that we need to calibrate.

Figure 2.2: Declaration of the Dem_AllDTCsParam32 in the code

Now we need to change the DEMSTARTSECROMCONST and DEMSTOPSECROMCONST definitions in order to have the "Dem_AllDTCsParam32" allocated in the .calib section (refer to the following sections for details on how to create the appropriate calibration section of memory modifying the Linker script). To do so, we modify the DemCfgMemMap.h. file as follows:

Figure 2.3: Modification of the Dem ROM sections

The next step is the modification of the Linker Script in order to get the correct sections in memory.

Linker script, WP and RP

In this section we analyze the linker script and how to modify it in order to create the sections in memory needed for the calibration.

As already mentioned, some new sections have to be added (if there are not equivalent sections already defined) in the linker script in order to keep the calibration parameters in specific memory areas. The objective is to have a section in flash memory where the initial value of the parameters are contained and a section of RAM memory which contains a copy of this portion of flash memory, to be used for the calibration. During startup, the mirroring from flash to RAM will be performed. Then, in order to calibrate a parameter, the calibration tool will change the value in RAM and the value will be copied eventually in flash when the correspondent XCP command is sent by the tool to the ECU. The RAM copy of the data is the so called "Working Page" (WP), and it's where the calibration takes place. The flash copy is the "Reference Page" (RP) and it's write protected. The Reference Page can be updated with the content of the Reference Page by the calibration tool (such as INCA) with the download procedure.

In the sample project, only the Working Page is currently implemented. Therefore, in the testing section we will show how to calibrate the WP using INCA.

Adding new memory regions

The linker structure is target dependent, but there are common elements that is worth to analyze. The memory regions dedicated to calibration must be specified in the linkers script. In the "Memory" section of the linker script, we add the references to calibration flash and calibration RAM, with the starting address and the length of these sections and the attribute to indicate if the section is read-only or read and write.

Figure 2.4: Declaration of Calibration Flash and RAM memory portions

Adding new sections

Into the "Section" part, it is possible to define new sections. As shown in the picture below, we will add two calibration sections, one in RAM and another one in FLASH. These sections are used as reference in the integration code as already explained in previous sections.

Figure 2.5: The RAM and Flash sections created for calibration

The line:

> CALIB_RAM AT > CALIB_FLASH

defines that all the content of CALIBRAM will have a flash copy in the region identified by the CALIBFLASH label.

MemCopy during startup

The last modification needed in order to have the flash data copied in the RAM mirror during startup is to add the corresponding section in the .copy_sec as shown in the following screenshot.

Figure 2.6: Sections copied during start-up

Results in the Map file

Let's analyze the map file output of the modifications that we did.

Searching for the "Dem_AllDTCsParam32" that we wanted to calibrate at the beginning into the map file, you can see that a new mapping between .CALIBDATA and CALIBRAM has been done, as shown in the screenshot below.

Figure 2.7: Map file content

As you can see in the picture, highlighted in point 1 there is the evidence that the CALIBRAM section will have a copy in flash and it will be located at address 0x8027c000. Then, highlighted in point 2, there is the variable *"DemAllDTCsParam32"* which contains the parameter we wanted to calibrate (all DTC values). At the same line, there is the information on the RAM address where the variable will be located. These information will then be used to update the A2L file for the calibration.

A2L - What is needed

In this section we analyze the A2L file and what shall be included into this file in order to calibrate the parameters.

INCA needs the A2L of your ECU to get different information. In particular, the A2L contains the information on the parameters which is possible to calibrate and their characteristics (e.g. the data type and the address of the parameter in memory). Therefore, you will need to updated the A2L of your ECU with the new information needed for the calibration. There are different ways to generate the A2L, and there are appropriates tools that may be used for the automatic generation. Since the creation of the A2L is outside the scope of the application note, in this chapter you can find general information on what shall be contained in the A2L file. As example, we will start from an existing A2L and we manually add the sections and parameters that we need for the calibration of some Diagnostic parameters.

Adding a new Characteristic in the A2L

In order to add a variable/array in the list of calibration, the A2L needs to contain some additional information. In A2L the variables that may be calibrated are defined as "characteristic". In our example, since we want to calibrate the Dem_AllDTCsParam32, we add the following lines:

/begin CHARACTERISTIC
	Dem_AllDTCsParam32 
	"Dem_AllDTCsParam32" 
	VAL_BLK 
	0x70100054 		/* Address derived from the map file */
	ULONG_RL 		/* Variable type */
	65535 			
	__Identity 	
	0 				/* Min value */
	4294967295 		 /* Max value */
	NUMBER 6		 /* It is an array of six elements */
/end CHARACTERISTIC

The information added to the A2L are related to the address in RAM memory of the parameter (derived from the already analyzed map file), range of the parameter, and the number of element of the array. In fact, this is an array of six elements since there is an entry for every configured DTC. In our sample project we have six configured DTCs.

We add the definition of the variable type (if not already present) ULONG_RL before the defined CHARACTERISTIC:

/begin RECORD_LAYOUT ULONG_RL 
	FNC_VALUES 1 ULONG COLUMN_DIR DIRECT 
/end RECORD_LAYOUT

The A2L is now completed and ready to be imported in INCA to made the calibration.

Testing

In this section we will test the modification we made in the previous chapter and we will verify that it is possible to calibrate the parameter using INCA.

Connecting the SK to INCA

The first step is to connect INCA to the SK. In order to do so, we connect the ETAS ES582.1 device to establish the CAN connection between the PC and the ECU.

We can add a new folder right clicking on the top folder DEFAULT:

Figure 3.1: INCA: Adding a top folder

Then a new folder is created and we can associate the A2L file that we produced before to our INCA workspace as shown in the screenshot below:

Figure 3.2: INCA: Associating the A2L file

Now we can press the Hardware icon and then the search icon to search for the available devices.

Figure 3.3: INCA: Configure the available HW device

Figure 3.4: INCA: Search for the available HW devices

At this point INCA will detect the ES582.1 connected to the PC. We can select the XCP module from the list.

Figure 3.5: INCA: Selecting the XCP channel

The following screenshot shows the steps:

1. Connect the devices XCP that we selected before pressing the icon
2. Wait for the connection icon highlighted in point 2 to become green
3. Press the icon 3 to show the window related to Memory Pages update/download

Figure 3.6: INCA: Setting up the HW Device

WP update and calibration

The memory page window will shown and now we can update our working page selecting "Upload" in the Action list and selecting From="ECU" and To="Working page"

Figure 3.7: INCA: How to update the Working Page

Once we updated our working page, we can open the experiment and we open the Variable Selection window. From there, we can select the variable "DemAllDTCsParam32" we want to monitor/calibrate.

Figure 3.8: INCA: Menu for Variable Selection

The editor for the variable will show you the current values for the selected variable.

Figure 3.9: INCA: Initial value of the DTC values

Now we can try to calibrate the working page of the ECU changing one of the instances of the DTC values. For example we can modify the value of the DTC related to "DemDTCLostCommMPDU" which is the one in position 2 in the array.

Figure 3.10: INCA: Modification of a DTC value

To confirm that the value has been updated, we can check using the debugger the status change of the DTC value As you can see in the picture below, the "DemDTCLostCommMPDU" code has been changed from 0xC10020 to xC10025 as expected.

Figure 3.11: Test result: The calibrated parameter is updaded in RAM memory

Since in the current example only the working page has been implemented, it is not possible to send the XCP commands through INCA in order to save the calibrated value in the reference page (that would be located in flash). If the value is not saved in the reference page, we will have the DTC restored to the intially configured value after the next shutdown-startup cycle.

Supported Diagnostic calibrations in RTA-BSW

In this chapter a list of all supported parameters for calibration will be provided, together with a description on how to calibrate each parameter.

DemEventAvailable

The parameter DemEventAvailable is used as initial value for availability of an event and may be changed dynamically using the API Dem_SetEventAvailable by a SWC.

The suggested solution to set the DemEventAvaliable for the events using the API Dem_SetEventAvailable dynamically using the SW-C or calling the API after the initialization.

An alternative solution is to make the DemAllEventsParamFlags possible to calibrate. The DemAllEventsParamFlags is used in the Dem_PreInit function to set the configured Events as available or not available during initialization.

The statement of Dem_AllEventsParamFlags parameter is:

#define DEM_START_SEC_ROM_CONST
#include "Dem_Cfg_MemMap.h"
.
.
.
DEM_ARRAY_DEFINE_CONST(Dem_EvtParamFlags, 
                       Dem_AllEventsParamFlags,
                       DEM_EVENTID_ARRAYLENGTH, 
                       DEM_CFG_EVENTPARAMS_FLAGS);
.
.
.
#define DEM_STOP_SEC_ROM_CONST
#include "Dem_Cfg_MemMap.h"

The following screenshot shows the content of the Dem_AllEventsParamFlags. Every entry of the array represent an Event.

Figure 4.1: Content of Dem_AllEventsParamFlags after initialization

The definition on the meaning of each bit of the DemAllEventsParamFlags is contained in the file DemCfg_Events.h, as follows:

Figure 4.2: Bit position meaning for Dem_AllEventsParamFlags 

Please notice that the file DemCfgEvents.h is generated according to the current BSW configuration. For this reason, the bit position and size depends on the number of events and the configuration of each event. Therefore, to configure an Event as avaliable or unavailable, you should check the generated DemCfgEvents.h in order to verify which bits of the DemAllEventsParamFlags you must change. For example, considering the generated DemCfgEvents.h file shown above, the bit that indicates the suppression is the 7th one (DEMEVTBPPARAM_SUPPRESSIONINIT).

Since the statement is inside the Dem ROM Const section, in order to make the parameter possible to calibrate, you can follow the same procedure indicated in the previous chapter "Diagnostic Calibration". In order to calibrate the DemEventAvailable parameter, you shall calibrate the correspondent item of the array changing the value according to the configuration you want. Please notice that there is an array item for each Event configured in BSW. Once also the A2L is up to date and you added the Dem_AllEventsParamFlags to the list of the characteristics, you can calibrate the value of every item of the array using INCA as shown in chapter "Testing".

It is not possible to add or remove events from the configuration but just modify on the initialization value of the array without changing its size. As mentioned before, the init value of the DemEventAvailable may be changed dynamically using the API Dem_SetEventAvailable from the Application Software.

DemOperationCycleRef

The DemOperationCycleRef, as the already described DemEventAvailable, is a parameter part of the Dem_AllEventParamFlags array. Every entry of the array is associated to an Event. The bit shall be changed with the corresponding id value associated to the OperationCycle you want to configure, for every Event you want to calibrate.

The ID associated to the configured operation cycles is defined in the file "DemCfgOperationCycle.h". For example, with four operation cycle configured, you will find the following:

#define DemConf_DemOperationCycle_DemOperationCycle_0      0u
#define DemConf_DemOperationCycle_DEM_OPCY_OBD_DCY         1u
#define DemConf_DemOperationCycle_DEM_OPCY_IGNITION        2u
#define DemConf_DemOperationCycle_DEM_OPCYC_WARMUP         3u

The Dem Operation Cycles IDs are generated according to the BSW configuration, and it depends on the configured OperationCycles.

As shown in the picture before "Bit position meaning for Dem_AllEventsParamFlags", in the file DemCfgEvents.h is indicated which bits are dedicated to the OperationCycle ID (see define DEMEVTBPPARAMOPERATIONCYCLEID). According to what is contained in this file, you shall calibrate the entry of the array Dem_AllEventParamFlags setting the bits with the Id value of the OperationCycle.

DemAgingCycleRef

Also he DemDebounceCounterDecrementStepSize, as the parameters already analyzed, is part of the DemAllEventParamFlags. As explained for the previous cases, the array DemAllEventParamFlags contains an entry for every Event configured in the BSW. Every entry has bits dedicated to a specific parameter part of the Event configuration. For what concerns the DemAgingCycleRef, the bits dedicated to this paremter shall be changed with the corresponding id value associated to the Aging cycle you want to configure. The IDs are the same as the ones defined for the parameter DemOperationCycleRef since the reference to the Operation Cycles are always the same.

As shown in the picture before "Bit position meaning for Dem_AllEventsParamFlags", in the file DemCfgEvents.h is indicated which bits are dedicated to the OperationCycle ID. According to what is contained in this file, you shall calibrate the entry of the array Dem_AllEventParamFlags setting the bits with the Id value of the OperationCycle. In the example of the picture, the bits dedicated to the OperationCycle ID are the 11th and 12th ones.

DemEventFailureCycleCounterThreshold

The Dem provides a DemEventFailureCycleCounterThreshold parameter for each event. This parameter defines the maximum number of tested and failed cycles, before the event becomes “confirmed”,i.e. enters the confirmed state. The DemEventFailureCycleCounterThreshold statement is contained in DemEvents.c, part of the DemAllEventsParam array:

#define DEM_START_SEC_ROM_CONST
#include "Dem_Cfg_MemMap.h"
.
.
.
DEM_ARRAY_DEFINE_CONST(Dem_EvtParam, 
                       Dem_AllEventsParam, 
                       DEM_EVENTID_ARRAYLENGTH, 
                       DEM_CFG_EVENTPARAMS);
.
.
.
#define DEM_STOP_SEC_ROM_CONST
#include "Dem_Cfg_MemMap.h"

The following screenshot shows the content of the Dem_AllEventsParam. Every entry of the array represent an Event. In order to calibrate the value of the failure threshold for every parameter, the highlighted parameters shall be calibrated:

Since the statement is inside the Dem ROM Const section, in order to make the parameter possible to calibrate, you can follow the same procedure indicated in the previous chapter "Diagnostic Calibration". Once also the A2L is up to date, you can calibrate the value of every item of the array using INCA as shown in chapter "Testing". Since INCA does not support the type definition in the A2L, the followed strategy to calibrate this parameter is to add to the A2L directly the calibration item with the address of every "failureThreshold" for every event. You can use your A2L generator tools to eventually create automatically the content and the characteristics needed in the A2L.

Also in this case it is not possible to add or remove items from the array Dem_AlEventsParam but only change the values of the failureThreshold for every event.

DemDTCPriority

In Dem, each supported event shall have a priority assigned to it,using the DemDTCPriority in DemDTCAttributes container. As for the previous analyzed parameter, the Dem provides a DemDTCPriority parameter for each event. Also the DemDTCPriority is part of the Dem_AllEventsParam array.

Figure 4.4: Content of Dem_AllEventsParam after initialization - Event Priority 

The same calibration strategy of previous parameter can be used. See how to calibrate DemEventFailureCycleCounterThreshold for details. The only difference will be the address of the parameter to calibrate that will be generated by the A2L gen tool.

DemAgingCycleCounterThreshold

According to Dem specifications, the parameter DemAgingCycleCounterThreshold defines the number of completed aging cycles, after which the event memory entry shall be deleted (aged) from the event memory. As for the previous parameter, the DemAgingCycleCounterThreshold is part of the Dem_AllEventsParam array:

Figure 4.5: Content of Dem_AllEventsParam after initialization - aging Threshold 

The same calibration strategy of previous parameter can be used. See how to calibrate DemEventFailureCycleCounterThreshold for details. It is not possible to add or remove items from the array Dem_AlEventsParam but only change the aging threshold value for every event.

DemDtcValue

The DemDtcValue parameter defines the Unique Diagnostic Trouble Code values. The DemDtcValue statement is contained in Dem_AllDTCsParam32 array:

#define DEM_START_SEC_ROM_CONST
#include "Dem_Cfg_MemMap.h"
.
.
.
DEM_ARRAY_DEFINE_CONST(Dem_DtcParam32, 
                       Dem_AllDTCsParam32, 
                       DEM_DTCID_ARRAYLENGTH, 
                       DEM_CFG_DTCPARAMS32);
.
.
.
#define DEM_STOP_SEC_ROM_CONST
#include "Dem_Cfg_MemMap.h"

#define DEM_CFG_DTCPARAMS32 \
{ \
    DEM_DTCS_INIT32(0         )/* No DTC Assigned */ \
    ,DEM_DTCS_INIT32(0xC10010 )/*DemDTC_LostComm_SEN*/ \
    ,DEM_DTCS_INIT32(0xC10020 )/*DemDTC_LostComm_MPDU*/ \
    ,DEM_DTCS_INIT32(0xC10030 )/*DemDTC_LostComm_SEN_1*/ \
    ,DEM_DTCS_INIT32(0xC10040 )/*DemDTC_MCAL_Error*/ \
    ,DEM_DTCS_INIT32(0xC10050 )/*DemDTC_MCU_Error*/ \
}

Since the statement is inside the Dem ROM Const section, in order to make the parameter possible to calibrate, you can follow the same procedure indicated in the previous chapter "Diagnostic Calibration". In order to calibrate the DemDtcValue parameter, you may change the last bit of every item of the parameter array. Once also the A2L is up to date, you can calibrate the value of every item of the array using INCA as shown in chapter "Testing".

Figure 4.6: Content Dem_AllDTCParam32 - Configured DTC values

It is not possible to add or remove events from the configuration but just act on the initialization value of the array without changing its dimension.

Please note that the DTCs are ordered by values. This means that it is not possible to calibrate a DTC with a value greater/lower than the value assigned to the following/previous DTC. For example, if you consider the configuration shown in the previous figure, the DTC = 0xC10020 may be configured only in the range [0xC10011 - 0xC1001F].

DemPidIdentifier

The DemPidIdentifier is a parameter OBD related. The PID Identifier is contained in an array of the following typedef:

typedef struct
{
    uint8 dataElementIndex;
    uint8 identifier;
} rba_DemObdBasic_PidType;

The array name is "rbaDemObdBasicPid" and it is contained in the Dem ROM Const section:

#define DEM_START_SEC_ROM_CONST
#include "Dem_Cfg_MemMap.h"
.
.
static DEM_ARRAY_DEFINE_CONST(rba_DemObdBasic_PidType, 
                              rba_DemObdBasic_Pid, 
                              DEM_CFG_OBD_PID_ARRAY_LENGTH, 
                              RBA_DEMOBDBASIC_CFG_PID);
.
.
#define DEM_STOP_SEC_ROM_CONST
#include "Dem_Cfg_MemMap.h"

You can notice that the rbaDemObdBasicPid is declared as static constant. Depending to the compiler settings, may happens that the level of optimization is too high and for this reason the symbol associated to the array is not created in the map file. If this is the case, to find more easily the RAM address of the array and use it in the linker script in order to create a new characteristic, you can reduce the level of the compiler optimization.

How to specify the level of compiler optimization is compiler dependent. For example, for the tricore Hightec compiler, you can specify the wished optimization using the compiler flag:

-O<level>

Where "level" indicates the level of optimization that will be adopted. With this solution it may be simpler to find out the RAM address of the static const array.

in order to make possible the calibration of the rbaDemObdBasicPid identifier, it is needed to change the statement of the array and remove the "static" keyword. Otherwise, it would not be possible to correctly map the array in the memory and generate the correct map file.

Independently with the solution adopted, since the statement is inside the Dem ROM Const section, in order to make the parameter possible to calibrate, you can follow the same procedure indicated in the previous chapter "Diagnostic Calibration" and update your A2L to get the array possible to calibrate.

DemPidDataElement

The DemPidDataElement is also an OBD related parameter and it is placed into the container DemPidClass.

For this parameter, the same considerations done for the DemPidIdentifier paremeter are valid.The DemPidDataElement are represented by the array rbaDemObdBasicPid2DataElement. Every element of this array represent the mapping between the PID and the Data Element Class.

For example, consider the case in which you have only the PID 0x0D configured for OBD Mode $02 and a mapping to a DataElementClass called DataElementClass_OBD. The initialization values for the array will be generated as:

#define RBA_DEMOBDBASIC_CFG_PID2DATAELEMENT \
{ \
   /* 0xD */		DEM_DATAELEM_DEMEXTERNALCSDATAELEMENTCLASS_OBD,  \
                     0 \
}

As for the DemPidIdentifier, the statement is contained in the DEM SEC ROM CONST, and it is normally initialized with the define RBADEMOBDBASICCFG_PID2DATAELEMENT.

To check the ID values of the DataElementClass to use for the calibration of this parameter, please look to the content of the generated header file: DemCfgEnvDataElement.h. For example, in the screenshot below you can see the case where four DataElementClass are defined.

Figure 4.7: Definition of the DataElementClasses contained in Dem_Cfg_EnvDataElement.h 

#define DEM_START_SEC_ROM_CONST
#include "Dem_Cfg_MemMap.h"

static const uint8 rba_DemObdBasic_Pid2DataElement[] = RBA_DEMOBDBASIC_CFG_PID2DATAELEMENT;
.
.
#define DEM_STOP_SEC_ROM_CONST
#include "Dem_Cfg_MemMap.h"

For example, if you wish to calibrate the DemPidDataElement of the PID 0xD, you should calibrate the first element of the rbaDemObdBasicPid2DataElement and change it value from 1 (corresponding to the DEMDATAELEMDEMEXTERNALCSDATAELEMENTCLASSOBD) to another value (e.g. 2 if you want to refer to DEMDATAELEMDEMDATAELEMENTCLASSENGINESPEED instead).

As for the previous parameter, in order to make possible the calibration of the rbaDemObdBasicPid2DataElement array, you can follow the solutions already proposed for DemPidIdentifier.

DemIndicatorHealingCycleCounterThreshold

According to the AUTOSAR specifications, the Dem module shall provide the configuration parameter DemIndicatorHealingCycleCounterThreshold per indicator per event to define the maximum number of tested and passed healing cycles, before the respective indicator is deactivated.

In order to configure the value of the healing cycle counter threshold, the values of the array Dem_AllEventsIndicatorParam shall be calibrated. This array contains an element for every Event, and for each Event contains the configuration for the Indicator associated to that particular Event.

Similarly to parameter "DemEventAvailable", the bit position corresponding to the threshold shall be checked in the file DemEventIndicatorsCfg.h. Please notice that also in this case the file is generated according to the BSW configuration. Therefore, to understand which bits in the Dem_AllEventsIndicatorParam are related to the healing cycle threshold, you have to check in the mentioned configuration file.

Figure 4.8: Content of Dem_EventIndicators_Cfg.h 

In the example above, you can see that the Healing Threshold is placed in position of the sixth bit (DEMEVTINDICATORBPPARAMHEALTHRESHOLD).

Since the statement of the array is inside the Dem ROM Const section, in order to make the parameter possible to calibrate, you can follow the same procedure indicated in the previous chapter "Diagnostic Calibration". In order to calibrate the DemAllEventsIndicatorParam array and consequently also the DemIndicatorHealingCycleCounterThreshold, you shall calibrate the correspondent item of the array changing the value according to the configuration you want. Once also the A2L is up to dated and you added the DemAllEventsParamFlags to the list of the characteristics, you can calibrate the value of the threshold using INCA as shown in chapter "Testing".

DemIndicatorRef

The DemIndicatorRef is a parameter configurable into the container DemIndicatorAttribute and contains the reference to a defined Indicator.

As the previously analyzed parameter DemIndicatorHealingCycleCounterThreshold, the DemIndicatorRef value is contained in the DemAllEventsIndicatorParam array. Therefore, also in this case, the bit position correspondent to the DemIndicatorRef shall be checked in the generated file DemEventIndicators_Cfg.h.

Also in this case, you can follow the same procedure indicated in the previous chapter "Diagnostic Calibration" for setting the Dem_AllEventsIndicatorParam as characteristic in the A2L and to ensure it is mapped correctly in memory. Once also the A2L is up to dated, you can calibrate the parameter using INCA.

DemDebounceCounterDecrementStepSize

This Dem parameter defines the step size for decrementation of the internal debounce counter. In order to configure this debounce counter value, the initialization value of the DemCfgDebCounterBaseClass_Paramsets shall be changed.

The DemCfgDebCounterBaseClass_Paramsets is array which contains an array for every DemDebounceCounterBasedClass container configured in the BSW. Every entry contains a DemDebounceCounterDecrementStepSize that may be configured. The name of the parameter in the structure is the "stepDown".

The statement of DemCfgDebCounterBaseClassParamsets parameter is into the DEMSTARTSECROMCONST and DEMSTOPSECROM_CONST defines. Since the statement is inside the Dem ROM Const section, in order to make the parameter possible to calibrate, you can follow the same procedure indicated in the previous chapter "Diagnostic Calibration".

Once also the A2L is up to date, you can calibrate the value of the debounce step parameter in the array using INCA as shown in chapter "Testing".

Since INCA does not support the type definition in the A2L, the followed strategy to calibrate this parameter is to add to the A2L directly the calibration item with the address of every "DemCfgDebCounterBaseClass_Paramsets .stepdown" for every entry of the array.

In the following screenshot the structure of the DemCfgDebCounterBaseClass_Paramsets is shown. Please notice that this structure may change according to the BSW configuration and may contain more or less parameters than the one shown.

Figure 4.9: Dem_Cfg_DebCounterBaseClass_Paramsets structure 

DemDebounceCounterFailedThreshold

This Dem parameter defines the value of the internal debounce counter, which indicates the failed status. As for the already explained DemDebounceCounterDecrementStepSize, the DemDebounceCounterFailedThreshold is contained in the structure DemCfgDebCounterBaseClass_Paramsets and the name of the parameter in the structure is "failedThreshold".

As mentioned for the previous parameter, since INCA does not support the type definition in the A2L, the followed strategy to calibrate this parameter is to add to the A2L directly the calibration item with the address of every "DemCfgDebCounterBaseClass_Paramsets.failedThreshold" for every entry of the array.

DemDebounceCounterIncrementStepSize

This Dem parameter defines the step size for incrementation of the internal debounce counter. As for the already explained DemDebounceCounterDecrementStepSize, the DemDebounceCounterIncrementStepSize is contained in the structure DemCfgDebCounterBaseClass_Paramsets and the name of the parameter in the structure is "stepUp".

As mentioned for the previous parameter, since INCA does not support the type definition in the A2L, the followed strategy to calibrate this parameter is to add to the A2L directly the calibration item with the address of every "DemCfgDebCounterBaseClass_Paramsets.stepUp" for every entry of the array.

DemDebounceCounterPassedThreshold

This Dem parameter defines the value of the internal debounce counter, which indicates the passed status.. As for the already explained DemDebounceCounterDecrementStepSize, the DemDebounceCounterPassedThreshold is contained in the structure DemCfgDebCounterBaseClass_Paramsets and the name of the parameter in the structure is "passedThreshold".

As mentioned for the previous parameter, since INCA does not support the type definition in the A2L, the followed strategy to calibrate this parameter is to add to the A2L directly the calibration item with the address of every "DemCfgDebCounterBaseClass_Paramsets.passedThreshold" for every entry of the array.

Conclusion

The samples and advice provided with this AN are provided to inform and guide and should not be assumed to be universally applicable. It is your responsibility to interpret the content and apply it to your specific use case.