Memory Mapping (MemMap)

For each build scenario (e.g. Boot loader, ECU Application) an own set of memory mapping files has to be provided.

The memory mapping file name shall be {Mip}_MemMap.h for basic software modules and {componentTypeName}_MemMap.h for software components where {Mip} is the Module implementation prefix and {component- TypeName} is the name of the software component type.

Each AUTOSAR basic software module and software com- ponent shall wrap declaration and definition of code, variables and constants using the following mechanism: 1. Definition of start symbol for module memory section 2. Inclusion of the memory mapping header file 3. Declaration/definition of code, variables or constants belonging to the specified section 4. Definition of stop symbol for module memory section 5. Inclusion of the memory mapping header file Note: In between 1 to 5 there shall be no other preprocessor code added. This would prevent correct interpretation of source code and cause later preprocessor errors. Note: For code which is invariably implemented as inline function the wrapping with Memory Allocation Keywords is not required.

The memory mapping header files shall provide a mech- anism to select different code, variable or constant sections by checking the defini- tion of the module specific Memory Allocation Key Words for starting a section (see [SWS_MemMap_00038]). Code, variables or constants declared after this selection shall be mapped to this section.

The memory mapping header files shall provide a mech- anism to deselect different code and variable sections by checking the definition of the module specific Memory Allocation Key Words for stopping a section (see [SWS_MemMap_00038]). The selected section shall be deactivated if the section macro is defined before in- clude of the memory mapping header file. Code or variables declared after this se- lection shall be mapped to an section collecting those inaccurate non-handled ob- jects from BSW Module or software component implementation. 1

The memory mapping header files shall check if they have been included with a valid memory mapping symbol and in a valid sequence (no START preceded by a START, no STOP without the corresponding START). This shall be done by a preprocessor check.

If a compiler/linker does not require specific commands to implement the functionality of SWS Memory Mapping, the Memory Allocation Keyword defines might be undefined without further effect.

The memory mapping header files shall undefine the mod- ule or software component specific Memory Allocation Key Words for starting or stop- ping a section.

The memory mapping header files shall use if-else struc- tures to reduce the compilation effort.

The selected section shall be activated, if the section macro is defined before include of the memory mapping header file.

The selection of a section shall only influence the linker's behavior for one of the three different object types code, variables or constants con- currently.

Each AUTOSAR basic software module and software com- ponent shall support, for all C-objects, the configuration of the assignation to one of the memory types (code, variables and constants).

The SWS Memory Mapping is applicable for each AUTOSAR basic software module and software component. Therefore the imple- mentation of memory mapping files shall fulfill the implementation and configura- tion specific needs of each software module in a specific build scenario. See also [SWS_MemMap_00038], [SWS_MemMap_00003], [SWS_MemMap_00018] and [SWS_MemMap_00001].

or a Software Component Description (case sensitive) if the MemorySection has no symbol attribute defined. OR • <NAME> is the symbol of the MemorySection described in Basic Software Mod- ule Description or a Software Component Description (case sensitive) if the Mem- orySection has a symbol attribute defined.

Memory mapping header files shall not be included inside the body of a function.

Each BSW memory mapping header file shall support the Memory Allocation Keywords to start and to stop a section for each belonging Memory- Section defined in a BswImplementation which is part of the input configuration.

The software component type specific memory mapping header file {componentTypeName}_MemMap.h shall support the Memory Allocation Keywords to start and to stop a section for each MemorySection defined in a SwcIm- plementation associated of this software component type.

The Memory Mapping shall provide a BSW memory map- ping header file if any of the BSW Module Descriptions is describing a Depen- dencyOnArtifact as requiredArtifact . DependencyOnArtifact . category = MEMMAP In this case the file name of the BSW memory mapping header file name is defined by the attribute value requiredArtifact . DependencyOnArtifact . ar- tifactDescriptor . shortLabel in the BSW Module Description.

For each software component type which is part of the input configuration a software component type specific memory mapping header file {com- ponentTypeName}_MemMap.h shall be provided by the Memory Mapping.

which is part of the input configuration a basic software module specific memory mapping header file {Mip}_MemMap.h shall be provided by the Memory Mapping if the BSW Module Descriptions is NOT describing a DependencyOnArtifact as requiredArtifact . DependencyOnArtifact . category = MEMMAP . Hereby {Mip} is composed accord- ing <Msn>[_<vi>_<ai>] for basic software modules where • <Msn> is the shortName (case sensitive) of the BswModuleDescription • <vi> is the vendorId of the BSW module • <ai> is the vendorApiInfix of the BSW module The sub part in squared brackets [_<vi>_<ai>] is omitted if no vendorApiInfix is defined for the Basic Software Module which indicates that it does not use multiple in- stantiation.

All MemorySection s defined in a BswImplementation belong to the {Mip}_MemMap.h memory mapping header file if the BswImplementa- tion does NOT contain a DependencyOnArtifact as requiredArtifact . De- pendencyOnArtifact . category = MEMMAP

All MemorySection defined in a BswImplementation belong to the memory mapping header file defined by the attribute requiredArti- fact . artifactDescriptor . shortLabel if the BswImplementation does con- tain exactly one DependencyOnArtifact as requiredArtifact . Dependency- OnArtifact . category = MEMMAP

All MemorySection defined in a BswImplementation and associated with the identical SectionNamePrefix belong to the memory map- ping header file defined by the attribute requiredArtifact . artifactDescrip- tor . shortLabel of the DependencyOnArtifact which is referenced by the Sec- tionNamePrefix with a implementedIn reference.

If a compiler/linker does not support mandatory functionality for the kind of MemorySection used by the BSW module or software component the Memory Allocation Keyword shall be defined to raise an error.

The part <NAME> from [SWS_MemMap_00022] may con- tain the following ASIL keywords to indicate the restriction/qualifications: {safety} = QM , ASIL_A , ASIL_B , ASIL_C , ASIL_D The {safety} tag is optional and indicates the maximum possible safety level. Down- scaling in the project is possible inside memory mapping header files. If no {safety} keyword is added the default shall be treated as QM (without any ASIL qualification).

Each AUTOSAR basic software module and software component should support the configuration of at least the following different memory types as described in • Table 7.3: Section Type VAR • Table 7.4: Section Type VAR_FAST • Table 7.5: Section Type VAR_SLOW • Table 7.6: Section Type INTERNAL_VAR • Table 7.7: Section Type VAR_SAVED_ZONE • Table 7.8: Section Type CONST_SAVED_RECOVERY_ZONE • Table 7.9: Section Type CONST • Table 7.10: Section Type CALIB • Table 7.11: Section Type CONFIG_DATA • Table 7.12: Section Type CODE • Table 7.13: Section Type CALLOUT_CODE • Table 7.14: Section Type CODE_FAST • Table 7.15: Section Type CODE_SLOW It is allowed to add module specific sections as they are mapped and thus are config- urable within the module's configuration file. The shortcut {ALIGNMENT} means the typical variable alignment. In order to avoid memory gaps variables are allocated separately according their size for the kind of memory sections where a high amount of variables is expected, e.g. VAR. Hereby it is the task of the implementer to ensure the proper granularity by defining memory sections with different {ALIGNMENT} postfixes for variables of different element sizes as described below. It is the integrator's job to ensure via appropriate memory mapping configuration (i.e. using the proper alignment #pragmas or omitting them at all to let the compiler decide) that the platform specific alignment requirements of objects of the respective size are honored. Thereby the effective alignment can deviate from the {ALIGNMENT} post-fix. BOOLEAN , used for variables and constants of size 1 bit 8 , used for variables and constants which typically have to be aligned to 8 bit. For instance used for variables and constants of size 8 bit or used for composite data types: arrays, structs and unions containing elements of maximum 8 bits. 16 , used for variables and constants which typically have to be aligned to 16 bit. For instance used for variables and constants of size 16 bit or used for composite data types: arrays, structs and unions containing elements of maximum 16 bits. 32 , used for variables and constants which typically have to be aligned to 32 bit. For instance used for variables and constants of size 32 bit or used for composite data types: arrays, structs and unions containing elements of maximum 32 bits. 64 , used for variables and constants which typically have to be aligned to 64 bit. For instance used for variables and constants of size 64 bit or used for composite data types: arrays, structs and unions containing elements of maximum 64 bits. PTR , used for variables and constants whose value is the address of another variable, so called pointers. UNSPECIFIED , used for variables, constants, structure, array and unions when size (alignment) does not fit the criteria of 8,16, 32, 64 bit or PTR. For instance used for variables and constants of unknown size In case structures and unions, it shall be allowed to use an alignment larger than the bit size of the elements. For instance to facilitate copy instruction a structure may have minimum 2 byte alignment, even if members are byte aligned. In this case, it should be possible to use alignment 16 bit instead of 8 bit for this structure. Note: The (embedded) application binary interface ((E)ABI) of some target architec- tures (e.g., TriCore) imposes additional alignment requirements on aggregate types type (e.g., structs) depending on the size of the structure. Those additional constraints do not need to be taken in consideration when selecting the {ALIGNMENT} post-fix of the Memory Allocation Keyword for variables and constants of those aggregate types. The shortcut {INIT_POLICY} means the initialization policy of variables. Possible INIT_POLICY postfixes are: • CLEARED , used for not explicitly initialized variables. • INIT , used for initialized variables. This are typically explicitly initialized vari- ables, but it can be also used for not explicitly initialized variables to be able to mix up both types to deal with legacy code. • POWER_ON_CLEARED , used for variables that are not explicitly initialized (cleared) during normal start-up. Instead these are cleared only after either a power on reset of the microcontroller or a power on reset of a battery backup memory itself after battery loss. For more details and examples please refer to the table below. Note: The postfixes NO_INIT and POWER_ON_INIT are still supported but deprecated and will be removed in one of the next releases. Use INIT or CLEARED also for those variables which might be initialized at a later time in the program flow, e.g. by an initialization routine. POWER_ON_CLEARED shall be used for variables which shall survive resets only. For optimizing the initialization at start-up, it is possible for any software vendor to apply an initialization policy refinement inside the SwAddrMethod name, e.g.: • <PREFIX>_SEC_VAR_POWER_ON_CLEARED_RSTSAFE_QM_8 , used to express reset safe variables. • <PREFIX>_SEC_VAR_POWER_ON_CLEARED_NVRAM_QM_8 , used to express that the section contains NVRAM buffers. • <PREFIX>_SEC_VAR_POWER_ON_CLEARED_BATTERY_BACKUP_QM_8 , used to express that the memory is a special battery backup device. • <PREFIX>_SEC_VAR_INIT_INDETERMINATE_QM_8 , used to express that the section contains NVRAM buffers. • <PREFIX>_SEC_VAR_INIT_SELFINIT_QM_8 , used to express that the mem- ory is a special battery backup device. Depending on the used SwAddrMethod one can derive options to map to individual ModeSets and so to different memory devices in the target project. Note 1: For microcontrollers / processors which are equipped with Error Correction Codes (ECC), the hardware needs to initialize the according memory in case of under voltage due to lost ECC. This includes: • Any 'normal' system RAM without external supply, which needs to be initialized when the microcontroller voltage drops below a threshold as the ECC codes be- come invalid. This usually happens in case of a cold power on reset. • Any 'standby' supplied RAM, which needs to be initialized when the standby volt- age drops below a threshold and the ECC codes become invalid. As a consequence POWER_ON_CLEARED symbols cannot be stored inside of those memory areas. Note 2: Please consider that microcontrollers / processors with embedded LBIST (Log- ical Build In Self Test), MBIST (Memory Build In Self Test) will initialize a specified amount of memory when those tests are executed. So these memory devices shall not be used for POWER_ON_CLEARED.

The part <NAME> from [SWS_MemMap_00022] shall con- tain the following core scope keywords to indicate the restriction/qualifications: {coreScope} = • GLOBAL is code/data which can be executed/accessed by any core in case of multi-core ECUs. • LOCAL code/data must be mapped by the integrator to a specific core (Core 0, Core 1, ...) in case of multi-core ECUs. The {coreScope} tag can be considered optional in case it is GLOBAL . Means in case no {coreScope} keyword is added the default shall be treated as GLOBAL . Instead the {coreScope} tag LOCAL shall be considered as mandatory. Background: Scope of LOCAL SwAddrMethod is visible and can not be mixed up with GLOBAL SwAddrMethods.

When a BSW module is split into allocatable memory parts the <PREFIX> as described in [SWS_MemMap_00022] shall be build up according to [constr_4103] of [5].

When a BSW module is split into allocatable memory parts all belonging MemorySection s. prefix needs to reference a SectionNamePre- fix .

For all section types, the part <NAME> from [SWS_MemMap_00022] may contain an optional vendor specific {refinement} tag. It shall be used to refine the allocation or initialization behavior (variables only). The used values are vendor specific and free of choice.

These requirements are not applicable to this specifica- tion.

These requirements are not applicable to this specifica- tion.