Patent ID: 12260198

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

A processing unit in the form of a control unit of a (motor) vehicle is schematically illustrated inFIG.1and identified by100, for example an engine control unit or a control unit for carrying out safety-critical vehicle functions, for example, during the course of autonomous driving.

Control unit100includes a processor unit or CPU110including a multiplicity of processor cores111,112,113,114. Control unit100further includes volatile memory units120, in particular a multiplicity of RAM memories or RAM modules121,122,123,124. Each of these memory units121,122,123,124may include a multiplicity of memory areas, the particular memory unit121,122,123,124or its memory capacity being able to be divided or grouped into a multiplicity of individual memory areas. Control unit100further includes a non-volatile memory unit130, for example, a flash memory.

The number of processor units and processor cores as well as the memory units are selected as examples inFIG.1for reasons of clarity. It is understood that control unit100may also include further processor units or processor cores as well as further memory units. It is also understood that control unit100may include further elements, for example a memory protection unit (MPU), a memory management unit (MMU), connections for a network or a field bus, data inputs, data outputs, etc.

An executable code140is stored in flash memory130, for example, a computer program for carrying out functions of control unit100, for example, during the course of an engine control or during the course of safety-critical vehicle functions.

During the course of the execution of code140, different applications of code140access different memory areas of RAM memory120with the aid of corresponding physical memory addresses.

Executable code140is based on a source code, which may be converted into executable code140during the course of a generation process by compiling and linking. Symbolic addresses of functions, variables, constants, etc. in the corresponding compiled code are converted by a linker code into specific physical memory addresses.

During the course of one preferred specific embodiment of a method according to the present invention, a linker code of this type is automatically generated to be able to convert the corresponding source code into executable code140, as explained below, based onFIG.2.

FIG.2schematically shows one preferred specific embodiment of the method according to the present invention as a block diagram.

The method may be computer-implemented as a script or code generator script, e.g., based on Java. RAM initialization routines and pieces of linker information may be generated with the aid of this script for the purpose of ensuring a consistency therebetween. A complexity of the linker code or the linker computer program may be reduced by an abstraction of the linker code syntax or linker syntax in the form of preprocessor macros. An effort for manually generating the linker code may be reduced, and an error probability due to an inconsistency between RAM initialization routines and the linker code may be minimized.

In a first step210, pieces of information relating to the memory areas of RAM memory units120of control unit100are determined.

In particular, a list of all supported RAM modules and their properties is transferred to the code generator script. This list is, in particular, specific to the control unit. For example, lists of this type may be provided for each supported microcontroller or microprocessor. The corresponding list of requested hardware variants is used during the build process.

For example, these pieces of information relate to the number, size and physical memory addresses of the memory areas. Physical properties of the individual RAM modules include, in particular, a start address and an end address. This information is used in the linker code to generate the memory areas.

The pieces of information further relate to an initialization type of the individual memory areas. A further property of a RAM module is the support of the possible reset or initialization types. These may relate to, for example, a regular power-on (“power-on reset,” “PoRst”), an initialization or a reset in the case of a detected software error (“software reset,” “SwReset”) as well as an initialization or a reset in the case of a detected hardware error (“trap reset,” “TrapRst”).

RAM modules often facilitate specific RAM addressing methods, e.g., a so-called small or Abs18 addressing. This information may, for example, also be transferred to the code generator script.

In addition, the pieces of information may relate to which processor core carries out the RAM initialization. To reduce a startup time, it may be more efficient to distribute the RAM initialization to different processor cores.

For example, hardware-specific extensions of the addressing methods may also be managed in the list of the pieces of information.

For example, the list containing the pieces of information relating to the memory areas may have the following appearance:

// CoreNumber(for Init)RamInitGenerationRamAddressMethod// -----------------------------------------------// 0-5 Core0-50x00 No Init0x01 Normal(absolute)addressing// 16 each Core0x01 SwReset0x02Small addressing// 255 not relevant0x02 SwReset, Trap0x03Absl8 addressing//0x03 SwReset, Trap,PowerOn//public List<RbaMemLayExport> getRAM ( ) {exportArray.add(new RbaMemLayRAM(“RAM0”,0x70004000, 0x7003BFFF,0,0x02,0x1));exportArray.add(new RbaMemLayRAM(“RAM1”,0x60004000, 0x6003BFFF,1,0x02,0x1));exportArray.add(new RbaMemLayRAM(“RAM2”,0x50004000, 0x50017FFF,2,0x02,0x1));}

The list may advantageously be arbitrarily expanded, in particular, based on the hardware properties of the RAM modules as well as control unit-specific or project-specific requirements.

A configuration is now carried out, depending on this list. This configuration may be divided, for example, into two parts, a resource configuration, which is carried out in a step220, and a macro configuration, which is carried out in a step230, as explained below.

In step220, the existing memory areas are configured as to which applications are assigned to which memory areas, as a function of these pieces of information. In particular, the existing memory areas are configured in such a way that partitions are created and individual memory areas are each assigned to a partition.

To facilitate the division into different partitions, the available areas of the RAM modules are partially or entirely exclusively assigned to one partition and removed for other partitions.

It is possible for the user to specify the configuration for each RAM area as to whether and to what extent a reduction is to take place. If a RAM area is not contained in this part of the configuration, the entire area is unavailable. For example, a different processor core may be necessary for the RAM initialization, which may also be configured in step220.

A so-called safeguard method may be used to divide specific software parts within a partition. This means that, in particular, multiple operating system applications may be carried out in parallel within one partition. For this purpose, for example, the number of available sections is multiplied by the number of configured applications (e.g., according to the ASIL level or from different suppliers) for each RAM area. The sections of the applications may be configured without a resource limitation and be easily arranged one after the other. The shielding from other applications takes place, for example, with the aid of a linker nomenclature or so-called linker labels, which are generated by macros. These linker labels are flexible, since the linker labels may be used in the code, and the absolute values are received only after the link run. A monitoring of the delimitation of the RAM areas of the applications may take place with the aid of hardware, e.g., with the aid of an MPU and/or MMU, or also with the aid of software methods. The sequence in which the applications are relatively situated one after the other may be configured, for example in that each application configures one index per RAM area. The code generator script sorts the individual applications in the memory area according to this index.

Macros are configured in step230, which describe accesses of applications to memory areas according to specific properties. In particular, a nomenclature or corresponding linker labels are defined. The macros may be configured as a function of pragmas, and pragma extensions may furthermore be configured in the macros.

The macros contain linker code for locating variables based on their pragmas, which are appended by the compiler. The macros use a fixed name rule for filtering the pragmas, which may be made up, for example, of the following:

<RAM name>.<application name>.<reset type>.<variable type>

To be able to provide individual extensions for different projects, mechanisms may be provided in the form of preprocessor hooks (#defines) and additional pragma name rules.

Each macro is generated, in particular, including a fixed preprocessor hook, which follows a fixed name rule and may be made up, for example, of the following:

RELOCATION_<RAM name>_<application name>_<reset type>_<variable type>

Each macro may be defined in a header file in a control unit-specific or project-specific manner. Moreover, extensions may be added to the linker syntax in the header file.

Since the linker code or the linker computer program and its macros are preprocessed in the build process, the exchange of the preprocessor hooks with the control unit-specific or project-specific contents then takes place. In this way, different extensions may be introduced for each macro. In particular, the macros are limited only by the linker syntax of the compiler used.

If global extensions are to be introduced, in particular for all macros, additional pragma extensions may be configured. In this way, further pragma filters may be inserted into the macros. The corresponding name rule may be made up, for example, of the following:

<RAM name>.<application name>.<extension>.<reset type>.<variable type>.

For this purpose, corresponding linker labels may be generated before and after the locating, so that they may also be handled separately (e.g., initialized, shielded, etc.).

Steps210,220,230may be carried out, for example, by a user. In these steps, pieces of information relating to the memory areas of the control unit are thus predefined for the code generator script and also a configuration of the existing memory areas as to which applications are assigned to which memory areas, and a configuration of macros, which describe accesses of applications to memory areas according to specific properties.

RAM initialization routines are generated in a step240. In step240, data arrays are generated as a function of the predefined pieces of information relating to the memory areas of the control unit, as a function of the predefined configuration of the existing memory areas and as a function of the predefined configuration of the macros, in particular as a function of the defined nomenclature, according to which an initialization of the memory areas takes place. In particular, different data arrays for different initialization types are generated for each processor core of the control unit. Moreover, different data arrays for different initialization values are generated for each initialization type.

Based on steps210,220and230, the code generator script includes, in particular, a list of the available RAM areas and their properties as well as a list of which applications were configured in which RAM area.

With the aid of these pieces of information, the script generates arrays for each core and each different initialization behavior. These arrays are used, in particular, by a routine for initializing the RAM. Linker labels are used in the arrays, which result depending on the RAM area and the name of the application. In particular, start and size labels are stored in the array. The absolute addresses of each section may thus be shifted, without the array content having to be changed, since linker labels are replaced by the values after the link run in the ELF or hex file.

These arrays are used, in particular, by static functions to describe the corresponding areas with initialization values. The assigned array including linker labels is used for this purpose according to the reset or initialization types. In particular, two arrays are provided for each reset or initialization type, a first array for an initialization using zero, and a second array for an initialization using a specific value not equal to zero. In the latter case, a start address of the specific value, which is stored in a flash memory, is transferred together with a linker label. Static functions of this type are provided for each processor core and for each of the initialization types. The corresponding static function is carried out to start the system.

The macros are generated in steps250and260. Generic macros are initially generated in step250and final macros in step260.

In particular, all macros are generated according to the same principle, in particular, according to a fixed name rule, which is made up, for example, of the initialization behavior of the variables, the reset property, the RAM module and the application name. Hooks and RAM initialization code may be advantageously generated thereby, which fit these linker code macros.

In step250, generic macros, which each describe accesses of a specific application to a specific memory area according to specific properties, in particular, the reset or initialization type and/or the initialization value, are generated as a function of the pieces of information relating to the memory areas of the control unit, as a function of the configuration of the available memory areas and as a function of the configuration of the macros, in particular, as a function of the defined nomenclature.

Generic macros or default macros for the location in the RAM memory are thus generated for the two initialization variants (zero or specific value). For example, the RAM module name, the application name and reset property are transferred as parameters in these generic default macros, and are thus generic. The contents of the generic macros include, in particular, a start linker label, a generic preprocessor hook, a pragma filter as well as an end linker label.

For example, a generic macro for a variable initialized with the value zero may be generated as follows:

#define TEMPLATE_LINK_BSS (RamName, Reset, AppName)\.bss. <RamName>.<AppName>_<Reset> : {\__<RamName>_<AppName>_<Reset>_BSS_START = .;\RELOCATION_,<RamName>,<AppName>_<Reset>_BSS)\“(*(.bss. <RamName>.<AppName>.<Reset>))”\_<RamName>_<AppName>_<Reset>_BSS_END = .;\} > <RamName>

For example, if further hooks are configured, they are, in particular, inserted into the generic macros. In addition to manually introducing linker syntax, one application of a second hook could be, for example, to introduce machine-generated linker syntax, e.g., to optimize runtime. The configured pragma extensions may also be inserted into the generic macro. A specific additional area may represent an application, e.g., specific protected variables in this area. In particular, additional start and end linker labels may be generated for each pragma extension.

For example, a generic macro for a variable initialized with zero may be generated as follows:

#define TEMPLATE_LINK_BSS (RamName, Reset, AppName)\.bss. <RamName>. <AppName>_<Reset> : {\__<RamName>_<AppName>_<Reset>_BSS_START = .;\RELOCATION_,<RamName>,_,<AppName>_<Reset>_BSS)\RELOCATION_,<RamName>,_,<AppName>_HOOK1_<Reset>_BSS)\“(*(.bss. <RamName>.<AppName>.<Reset>))” \__<RamName>_<AppName>_ Pragma_Extension1_<Reset>_BSS_START = ..\“(*(.bss. <RamName>.<AppName>.Pragma_Extension1.<Reset>))” \__<RamName>_<AppName>_ Pragma_Extension1_<Reset>_BSS_END = .. \__<RamName>_<AppName>_ Pragma_Extension2_<Reset>_BSS_START = ..\“(*(.bss. <RamName>.<AppName>.Pragma_Extension2.<Reset>))” \__<RamName>_<AppName>_ Pragma_Extension2_<Reset>_BSS_ END = .. \__<RamName>_<AppName>_<Reset>_BSS_END = .;\} > <RamName>

In step260, final macros are generated as a function of the generic macros. A final macro is generated in each case for each memory unit, which includes the generic macros which relate to the memory areas of the particular memory unit.

A further macro is thus generated for each RAM module, where the generic macros are called for all applications belonging to this RAM. The macros are advantageously expanded accordingly, depending on which reset behavior the particular RAM memory unit supports.

For RAM modules which are not used by any application, final macros are advantageously also generated, in particular, without contents.

An example of a control unit including four RAM memory units and two applications is examined below:

RAM1 with App1; ResetType: SwReset. TrapRst, PoRst

RAM2 with App1 and App2; ResetType: SwReset.

RAM3 with App1; ResetType: SwReset.

RAM4 is not used.

For example, the following final macros may be generated in this case:

#define TEMPLATE_LINK_BSS_RAM1\TEMPLATE_LINK_BSS (RAM1, SwReset, App1)\TEMPLATE_LINK_BSS (RAM1, TrapRst, App1)\TEMPLATE_LINK_BSS (RAM1, PoRst, App1)#define TEMPLATE_LINK_BSS_RAM2\TEMPLATE_LINK_BSS (RAM2, SwReset, App1)\TEMPLATE_LINK_BSS (RAM2, SwReset, App2)#define TEMPLATE_LINK_BSS_RAM3\TEMPLATE_LINK_BSS (RAM3, SwReset, App2)#define TEMPLATE_LINK_BSS_RAM4

To reduce, in particular minimize, an effort for manually generating the preprocessor hooks, the script also generates, for example, default hooks, which are necessary due to the generated macros. These default hooks, in particular, do not contain any linker code and are needed, in particular, so that the preprocess does not abort if a hook is not defined.

In particular, at most only the macros are thus generated manually, into which a project-specific extension is to be introduced. To avoid a double definition of the hooks, it is first checked for the default hook, in particular, whether a corresponding manually generated preprocessor hook already exists. The hook is generated only if this is not the case.

For example, hooks may be generated as follows:

#ifndef RELOCATION_RAM1_APP1_SWRESET_BSS

#define RELOCATION_RAM1_APP1_SWRESET_BSS #endif

The generated hooks are stored, for example, in a separate file, since, in particular, an include sequence in the linker code is relevant here. In particular, the manually generated preprocessor hooks are integrated before the generated hooks, since the #ifndef check may otherwise be removed, which may result in a double definition.

In step270, macros characterizing the memory units are furthermore generated as a function of the pieces of information relating to the memory areas of the control unit. These macros each describe a start address, an end address and a size of the individual memory units.

If a partitioning is activated, a corresponding reduction takes place for the RAM modules, based on the configuration of the partitioning.

For example, a macro of this type may be generated as follows for a RAM memory unit:

/* MemLay layout configuration of RAM1 */#define RBA_MEMLAY_RAM1_START0x60000000#define RBA_MEMLAY_RAM1_END0x60010000#define RBA_MEMLAY_RAM1_SIZE0x10000

In step280, the linker code is generated as a function of the final macros, the data arrays and the macros characterizing the memory units.

For example, the linker code may be generated according to two different possibilities. For example, a superset of all macros may be stored in the linker code, so that the linker code does not have to be regenerated each time the configuration is changed. The code generator script may also generate the linker code, based on the internal data, and employ only the macros which are actually used. In the first case, the development effort is slightly lower. In the second case, the linker code or the linker computer program is reduced to basic necessity and is clearer.

For example, the linker code or its computer program may be generated as follows.

#include “GeneratedMakrosFile.h”#include “ManualHooksFile.h”#include “GeneratedHooksFile.h”MEMORY {RAM1 : ORIGIN = RBA_MEMLAY_RAM1_START, LENGTH =RBA_MEMLAY_RAM1_SIZERAM2 : ORIGIN = RBA_MEMLAY_RAM2_START, LENGTH =RBA_MEMLAY_RAM2_SIZERAM3 : ORIGIN = RBA_MEMLAY_RAM3_START, LENGTH =RBA_MEMLAY_RAM3_SIZERAM4 : ORIGIN = RBA_MEMLAY_RAM4_START, LENGTH =RBA_MEMLAY_RAM4_SIZE}SECTIONS{TEMPLATE_LINK_BSS_RAM1TEMPLATE_LINK_DATA_RAM1TEMPLATE_LINK_BSS_RAM2TEMPLATE_LINK_DATA_RAM2TEMPLATE_LINK_BSS_RAM3TEMPLATE_LINK_DATA_RAM3TEMPLATE_LINK_BSS_RAM4TEMPLATE_LINK_DATA_RAM4}

The above example relates to a multi-core system including six processor cores and a partitioning, which is implemented on the first four cores. Each RAM module supports, for example, different reset types. Multiple operating system applications are supported with safeguard. The RAM initialization is distributed, for example, to the first four cores. The linker code uses the macros including the most important pieces of information with regard to the supported RAM modules. Further implementations of the configuration take place, for example, in macros which are replaced by the preprocessor having the linker syntax.

A consistency between the final macros and the data arrays is checked in a step290.

For this purpose, the code generator script generates, for example, a file including linker commands, based on the available resources and configuration, for the purpose of checking whether all expected linker labels are present and that the linker code and the RAM initialization are thus consistent.

The code generator script advantageously uses the same data sets for initializing the RAM and for safeguarding the linker codes. A security prompt is generated in the linker syntax for all available RAM areas and their properties or features as well as with the aid of a list as to which applications were configured in which RAM area. The script generates, for example, a linker check code with the aid of these pieces of information. This code checks all linker labels used for the RAM initialization according to the configuration. In particular, it is checked whether these linker labels were created and whether they have the correct alignment. In the case of an inconsistency, the linker code may abort the build process, for example, using a corresponding error message.

In a step300, the executable code to be executed on the control unit is generated from the source code with the aid of the generated linker code. This source code is compiled for this purpose, and symbolic memory addresses in the compiled code are converted into physical memory addresses. As a function of the final macros or as a function of the generic macros, symbolic memory addresses are converted into corresponding physical memory addresses for accesses by specific applications to specific memory areas according to specific properties. The executable code is generated as a function of these physical memory addresses and the compiled code.

In a step400, the executable code is carried out in the control unit, so that functions of control unit100are carried out, for example, during the course of an engine control or during the course of safety-critical vehicle functions. During the course thereof, corresponding applications are carried out by the executable code, which access different memory areas of the RAM memory of the control unit with the aid of the corresponding assigned physical memory addresses.