RTA Knowledge Base

Table of Content

Introduction

Scope

This application note describes the procedure for porting an RTA-CAR (RTA Classic AUTOSAR) project from one target to another. The guide describes a generic process, that will inevitably require additional target-specific actions to be taken. 

This guide should be followed through fully before attempting to rebuild the project. It is also inevitable that you will not catch all the required changes in this first pass through the guide. Additional issues can then be solved in an iterative process: by examining the build issues (e.g. compiler/linker), correcting the configuration, regenerating the code, and finally rebuilding the project.

The example used here is porting a Virtual (VRTA) RTA-CAR project to the TriCore TC275 (HighTec toolchain). 

Definitions and Abbreviations

BSW: AUTOSAR Basic Software, Hardware independent service layer

RTE: AUTOSAR Real Time Environment

OS: AUTOSAR Operating System

SWC: Software Component

Toolchain

It is assumed you are using RTA-CAR 12.0.1 or newer.

RTA-CAR 12.0.1

ISOLAR-A/Bv12.0.1
RTA-RTEv12.0.1
RTA-BSWv12.0.1
RTA-OSv12.0.1

Prerequisites

This application note assumes you have a working RTA-CAR project that you wish to port to a different target.

MCAL Configuration and Generation

Regenerating the MCAL (Microcontroller Abstraction Layer) early on in the porting procedure will expose a number of issues, allowing them to be fixed as the rest of the procedure is carried out.

The MCAL (Microcontroller Abstraction Layer) must be regenerated using an MCAL generation tool supporting the new target. The MCAL configuration may also need updating if there are target differences, for example Dio/Port layout, or if MCAL generation tools differ in their configuration requirements.

The steps required to regenerate the MCAL (Microcontroller Abstraction Layer) for the new target are dependent on the MCAL configuration tool, so are not detailed here.

The two most common use cases are the following:

  1. You want to create a new RTA-SK Porting for a new family of Microcontroller
  2. You want to create a new RTA-SK Porting for a different Microcontroller variant but in the same Family (for example, porting from Infineon Tricore TC275 to Infineon Tricore TC264)

The first use case will be more complicated since you will need to configure the MCAL from scratches. In the second case, we suggest to take the MCAL project of the micro variant that is already configured for the RTA-SK and use that as a reference. Even in this second case, there will be differences but you will find a lot of similiarities that could help you in the configuration process.

In general, the process to follow in order to get the MCAL configured and generated is the following:

  1. Download and install the MCAL generator and configuration tools of the Microcontroller Family you want to configure
  2. Create a new MCAL project
  3. Consult the User Guide and the Datasheet of the micro in order to understand how the MCAL must be configured
  4. Generate the MCAL code
  5. Take care of the integration code (for example, startup code, errorhooks, shutdown hooks)

Once you have the MCAL code generated, you might need to adjust the BSW configuration. This is explained more in detail in the following chapters.

Update OS Config


The Os configuration the following target specific parameters that need updating:

  • 'OsRTATarget' parameters (described in the respective RTA-OS Port Guide):
    • OsRTATargetName,
    • OsRTATargetVersion
    • OsRTATargetVariant
  • OsIsrs parameters (at least the System Clock ISR):
    • OsIsrAddress

After updating the configuration, regenerate the OS.

Update BSW Module Configurations

As mentioned, regeneration of the MCAL will likely result in a number of incompatibilities with the existing BSW configuration. These can be identified by viewing the changes to the MCAL header files.

In particular, the BswM module and the EcuM module have the references to MCAL header files and callouts for initialization. Hence, the configuration of these modules shall be updated (for example changing the name of the init functions needed for the driver initialization).

For example, when migrating from a virtual (VRTA MCAL) to TriCore (Infineon MCAL) target, the CAN Config structures are different, and the InitList actions which use these structures require updating from 'Can_Init(&Can_Config)' to 'Can_Init(&Can_17_MCanP_ConfigRoot[0])'.

In the screenshot below, you can see the an example of change needed to move from the VRTA target to the TC275 target. In the VRTA target (on the right) the Fls init function was not requiring any pointer to configuration as parameter. In the left side, in the TC275 target, it was needed to add the reference to the Fls Config array to proceed with the correct initialization.


Other common causes of errors are:

  • BswM ActionItem UserCallouts (such as the example Can_Init)
  • BswM ActionItem 'RteTimerStart' UserCallout.

If moving from a virtual to physical target, update the FeeRbMachineType to MCU_RB_MANUAL_CFG.

Changes to the peripherals on the target, such as different Can Controller or Flash memory properties, will require updates to be made to the respective BSW module configurations. For example:

  • The FeeGeneral configuration (e.g. FeeRbSectorSizes)
  • The CanConfigSet configuration, (e.g. CanController HardwareName & CanControllerBaudrateConfig)

Once the BSW module configurations are updated as far as possible, regenerate the BSW code.

Linker Scripts

The linker script must be replaced with one suitable for the new target/toolchain. This process is highly project dependent.

The RTA-OS Configuration Tool can generate example projects (e.g. HelloWorld) that include example linker scripts which are good starting point. These are accessed in the Builder → Setup → Samples tab within the RTA-OS Configuration Tool.

For simple projects (e.g. without AUTOSAR MemorySections) this example file may be enough, however a more complex project will require a more complex linker scripts to be developed.

CMake Configuration

The CMake build configuration in an RTA Starter Kit is split into two parts: A generated 'CMakeList.txt' file, and a target specific 'CMake<TargetName>.txt' file. The generated 'CMakeList.txt' file includes the target specific file.

The target specific file must be updated to include:

  • COMPILER_ROOT : Path to the toolchain bin directory
  • TOOLCHAIN_PREFIX : Optional, prefix for all binary tools. 
  • CMAKE_<BIN_TOOL> : Path to any required binary tools, for example:
    • CMAKE_C_COMPILER
    • CMAKE_CXX_COMPILER
    • GCC_COMPILER
    • CMAKE_LINKER
    • CMAKE_AR
    • CMAKE_RANLIB
    • CMAKE_NM
    • CMAKE_STRIP
  • CMAKE_CROSSCOMPILING : Set to ON for physical targets
  • CMAKE_C_FLAGS : Compiler flags for the project
  • CMAKE_EXE_LINKER_FLAGS : Linker flags for the project
  • CMAKE_EXECUTABLE_SUFFIX_C : Desired output suffix (e.g. '.elf')
  • CMAKE_STATIC_LIBRARY_SUFFIX  : Format of RTA-OS and any other libraries. (e.g. ".a")

Additional options specific to the target and toolchain will likely be required. An example target specific file for the TC275 is attached.

The Python script 'genCMake.py' must then be updated if the name of the target .txt file has changed. 

The 'genCMake.py' 'bannedlist' can also be updated if there are any generated files that are in the source directories of the project, that should not be built.

Integration Code

Within the project there is a number of 'Integration' source files. These are located in either the 'src/integration' directory, or the many 'src/<BswModule>/integration' directories. These files are for user maintained source code, often specific to the target.

Changes required to these files include:

  • Due to changes in the MCAL source code, integration code may require a different set of #includes. For issues within the generated RTE source code (e.g. Rte code no longer compiles due to missing Fls function declarations) the 'src/integration/Rte_UserCfg.h' file should be updated (e.g. to #include "Fls.h"). 
  • If moving from VRTA to physical target, remove the 'src/integration/MemMap.h' file as this should be generated by the MCAL generation tool.
  • If moving from VRTA to physical target, implement the InitTask body as a file in  'src/integration/', as this will no longer be part of the MCAL. See example 'ECU_StartupTask.c' file.
  • The integration file 'src/bsw/EcuM/EcuM_User.h' may require additional configuration for mapping between RTA-BSW and the MCAL. See example file EcuM_User.h for the TriCore TC275 target.

As with the Bsw Module Configuration section, fixing all the integration code issues will be an experimental/iterative process.


ECU_StartupTask.c

EcuM_User.h

Debugger Scripts

The Flash/Debug scripts in the 'Debug' directory are target specific, therefore need replaced.

Replacement Trace32 scripts can be found in the relevant T32 directory, e.g. C:\T32\demo\tricore\flash for the TriCore scripts.

These scripts may require further modification depending on the project.

Licensing

Message someone in the FAE team or create ticket in relevant hotline

Build & Summary

This guide has detailed all the steps of the porting process, you will now be able to attempt to build the project for the new target. As mentioned, there will inevitable be additional issues - 

This guide should be followed through fully before attempting to rebuild the project. It is also inevitable that you will not catch all the required changes in this first pass through the guide. Additional issues can then be solved in an iterative process: by examining the build issues (e.g. compiler/linker), correcting the configuration, regenerating the code, and finally rebuilding the project.

Additional Hints

Porting the RTA-SK could be quite complicated if you are exploring a completely new target for you, and you don't have any previous RTA-SK made for that specific target before to take as example.

Here some general advice that might be useful if you are facing a porting procedure for the first time:

  • Use the existing RTA-SK projects as references: take your time to check to check what is contained in the RTA-SK package. It could be useful to make comparisons among the different RTA-SK portings. For example you can compare the RTA-SK VRTA with the RTA-SK TC275 and take some time detecting what changes has been made to port from the virtual to the real target. It is very likely that you will need to make similar changes to port to a new target
  • Remember to update your integration code: when you generate the MCAL and the BSW for the new target, changes might be needed in the integration code. You can experience issues in the initialization phase, and this could be caused by wrong/missing calls in the Init Task, Startup Code, or it might even caused by wrong order of the calls of the init functions (some drivers/bsw modules might need to be initialized before/after some other modules)