Revision as of 19:42, 22 May 2019

Introduction

This manual describes the porting details of the ERIKA Enterprise v3 kernel(s) for Renesas RH850 E2x-FCC2 microcontroller.

RH850 features supported

The following are the main features currently supported by the RH850 port:

• Compilers
  • Wind River Diab Evaluation (v5.9.6)
  • Wind River Diab 5.9.6.6 Licensed
• Debuggers/Trace tools
  • Lauterbach TRACE32
• CPUs
  • RH850G4
• Microcontrollers
  • R7F702Z17
• Evaluation boards
  • Y-RH850-E2FCC2-468-EVAL-V2
• External Libraries
  • Renesas Embark E2x Software

N.B. ERIKA currently support Floating Point Unit Coprocessor (FPU), Extended Floating Point Unit Coprocessor (FXU) is not supported yet.

Integration with Renesas Embark E2X Software

This ERIKA's porting relies on Renesas Embark Software for all the low-level startup activity needed to bring up an RTOS environment, like: boot from reset vector, general purpose and special registers initialization, C data initialization, pll ramp-up (CLK), eventual FPU initialization etc. All these procedures plus most of the other low-level drivers (e.g. PORT, SCI, ADCH, CAN etc) are configured and executed in exactly the the same way as what is typically done in a native Renesas Embark application (i.e. without an external RTOS).

Interrupt Controller Initialization (INTC) and OS Timer Module (OSTM) initialization (when the system timer is configured) are done inside the StartOS call, always relying on Embark E2x library. The configuration of these features is automatically generated by RT-Druid, starting from OIL file. The generated configuration file is out/ee_r_embark_g4mh_cfg.c.

Module Standby for OSTM is internally handled by ERIKA3 when the System Timer is configured, all other peripherals stand-by have to be handled by the application.

Currently, only the low-level drivers of the Embark library are automatically compiled by ERIKA's build system (i.e. those contained in Drivers/RH850 sub-folder).

Any driver inside the Embark/SourceCode/Drivers can be added to the build through OIL provided that it follows the Embark Driver Software Layout Convention.

IMPORTANT: In case of a multicore application, the application MUST NOT call directly the Embark R_BOOT_SetPeActive function (this will break the ERIKA3 startup procedure), but it should rely on the standard kernel API StartCore.

Obviously, Embark Scheduler Module (SCHD) is not compatible with ERIKA.

Details for the Embark configuration are provided below, in the specific paragraph dedicated to the Embark library.

Tutorials

The following tutorials are available for this architecture:

• Renesas RH850 E2X-FCC2 build with RT-Druid

Configuration and Programming

ERIKA Enterprise is configured through RT-Druid and an OIL file and some other properties.

The following sections describe the properties and OIL fields customized for the Renesas RH850 Architecture.

Wind River Diab Compiler Path

It is possible to choose the path in three different ways:

• Specific environment variable: WIND_DIAB_PATH (this is the same environment variable that Wind River configuration scripts generate and use)
  • E.g.: WIND_DIAB_PATH=C:\WindRiver\compilers\diab-5.9.6.6
• RT-Druid Eclipse IDE Property.
• RT-Druid Configuration File Entry: preference_tricore__path_for_hightec_gcc_compiler
  • E.g.: preference_rh850__path_for_windriver_diab_compiler=C:\\WindRiver\\compilers\\diab-5.9.6.6

Here is an example of RT-Druid configuration file.

Renesas Embark Software

It is possible to choose the path in two different ways:

• RT-Druid Eclipse IDE Property.
• RT-Druid Configuration File Entry: preference_rh850__path_for_embark_g4mh_software
  • E.g.: preference_rh850__path_for_embark_g4mh_software=C:\\Renesas\\EmbarkE2x_V2.5\\EmbarkE2xFCC1

Lauterbach TRACE32 Path

It is possible to choose the path in two different ways:

• RT-Druid Eclipse IDE Property.
• RT-Druid Configuration File Entry: preference_lauterbach__path_for_trace32
  • E.g.: preference_lauterbach__path_for_trace32=C:\T32

Here is an example of RT-Druid configuration file.

Lauterbach Emulator Interface

It is possible to choose the path in two different ways:

• RT-Druid Eclipse IDE Property.
• RT-Druid Configuration File Entry: preference_lauterbach__emulator_usb_interface
  • E.g.: preference_lauterbach__emulator_usb_interface=true

Here is an example of RT-Druid configuration file.

CPU

CPU_DATA object must be set to RH850.

Example of a CPU_DATA section:

   CPU_DATA = RH850 {
     ...
   };

ID

On multicore systems, one CPU_DATA instance exists for each core. They must have different IDs to be considered really distinct cores (all the CPU_DATA block with the same ID are merged together during generation and this may or may not cause validation errors if this happens due to a misconfiguration).

ID is a numeric value starting from 0 (default value). The ID value corresponds to the core physical ID, so the ID=0 (corresponding to the master core), MUST be configured always as it is requested by the AUTOSAR specifications, the other ID values are free to be configured or not.

In RH850 GM4H MCU family this number can be 5 at most since this family is equipped with 6 cores.

COMPILER

COMPILER attribute of CPU_DATA supports for now the DIAB value only. Deafult value is DIAB.

Example of a COMPILER attribute of CPU_DATA section:

   CPU_DATA = RH850 {
     COMPILER = DIAB;
     ...
   };

MINIMAL_OPTS

MINIMAL_OPTS boolean property of COMPILER attribute of CPU_DATA configures the build system with minimal compiling and linking options. The default value is set to FALSE.

Example of a MINIMAL_OPTS property of COMPILER attribute of CPU_DATA section:

   CPU_DATA = RH850 {
     COMPILER = DIAB {
          MINIMAL_OPTS = TRUE;
     };
     ...
   };

LINKER_SCRIPT =

LINKER_SCRIPT attribute of CPU_DATA is a String attribute that as to contains a path to a valid Linker Script. It has to be provided for a non-supported derivative (currently any derivative that is not r7f702z04)

MCU

The MCUs support for the RH850 is configured correctly by simply specifying the MCU_DATA.

Valid configurations

The following are valid configurations for the MCU_DATA setting:

• RH850_G4MH

   MCU_DATA = RH850_G4MH {
     DERIVATIVE     = "r7f702z04"; /* <-- Default Value */
     EIINT_CHANNELS = 512; /* <-- Default Value */
   };

MCU_DATA

MCU_DATA currently supports RH850_G4MH value only.

Example of a MCU_DATA section:

   MCU_DATA = RH850_G4MH {
     ...
   };

DERIVATIVE

DERIVATIVE attribute of MCU_DATA is an OIL attribute of type String. This field is used to select linker files (currently only the linker script for r7f702z04 is provided by ERIKA, linker script for any other derivative that is not r7f702z04 has to be provided through CPU_DATA.LINKER_SCRIPT field) and to generate Lauterbach scripts.

Example of DERIVATIVE attribute of a MCU_DATA section:

   MCU_DATA = RH850_G4MH {
     DERIVATIVE = "r7f702z04";
     ...
   };

EIINT_CHANNELS

EIINT_CHANNELS attribute of MCU_DATA is an OIL attribute of type UINT32. This field is used to quantifaicate the number of entries of interrupt vector. There is no consistency check between DERIVATIVE and EIINT_CHANNELS values.

Example of DERIVATIVE attribute of a MCU_DATA section:

   MCU_DATA = RH850_G4MH {
     ...
     EIINT_CHANNELS = 512;
   };

Interrupt Handling

Since there is no naming convention enforced by Renesas to identify a specific external interrupt source, the numeric approach has been chosen for this porting, mimicking what is done in native Embark E2X application. Valid values for the SOURCE field are strings representing numbers from "0" to "EIINT_CHANNELS" value for MCU_DATA RH850_G4MH.

Additional details:

• The Renesas interrupt controller (INTC) is a two-level interrupt controller.
• The first 32 entries are handled privately for each core, while all the entries after 32 are global for the entire system.
• It is legal to have multiple ISR with SOURCE 18 as long as they belong to different cores.
• IMPORTANT: in multicore environments, SOURCE = "0"; correspond to Channel 0, mapped to the Inter-processor interrupt function (IPIR). This source is reserved for Kernel internal communication.

System Timer

The OSEK/VDX standard provides support for a System Counter (a counter that is automatically linked to a hardware timer).

In ERIKA Enterprise, this special counter has been named System Timer. To use it, you need to set a specific attribute in a Counter definition. Please note that only one counter for each core can be the System Timer.

A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive IncrementCounter.

The following is an example OIL definition for a System Counter:

 COUNTER SystemTimer {
   CPU_ID = 0;
   MINCYCLE = 1;
   MAXALLOWEDVALUE = 2147483647;
   TICKSPERBASE = 1;
   TYPE = HARDWARE {
     DEVICE = "18";
     SYSTEM_TIMER = TRUE;
     PRIORITY = 1;
   };
   SECONDSPERTICK = 0.001;
 };

The meaning of the various attributes is as follows:

• COUNTER/CPU_ID is used to tie the counter to a specific core (you do not need to declare the CPU_ID in case the value is 0)
• COUNTER/TYPE must be set to HARDWARE, and SYSTEM_TIMER must be set to true.
• COUNTER/TYPE/DEVICE must be a valid device that can be used as system timer. Currently, for RH850 only 18 and 19 (OS Timer Module) MCU peripheral are valid devices for system timer. DEVICE = "18" correspond to OSTM0 peripheral, that can broadcast its interrupt to all the cores (this is a nice feature which ensures a synchronized timebase for all cores). DEVICE = "19" correspond to a core private OSTM unit, from OSTM1 for Core0 to OSTM6 for Core5.
• COUNTER/TYPE/PRIORITY By default SYSTEM_TIMER is tied to smallest ISR priority (i.e. PRIORITY = 1;), but it can be overwritten.
• COUNTER/SECONDSPERTICK is used to declare the wanted time duration of one hardware tick in seconds.

  IMPORTANT: SECONDSPERTICK needs to have the same value for all system timers are driven by DEVICE = 18 (OSTM0 unit), otherwise some temporal misbehavior will happen in some core. The OSTM0 unit configuration is physically done by the first core reaching the system timer initialization routine. A multicore "atomic" boolean grants a single initialization.

The System Timer can be attached to ALARMs as usual, as in the following example:

 ALARM AlarmExample {
   COUNTER = SystemTimer;
   ACTION  = ACTIVATETASK{
      TASK = TaskExample;
   };
 };

LIB

LIB object supports for now the EMBARK_E2X value only.

Example of a LIB section:

   LIB = EMBARK_G4MH {
      DRIVER = "GTM"; "Extra drivers folder from which getting source for libembark_g4mh.a";
      DRIVER = "FPE"; "Extra drivers folder from which getting source for libembark_g4mh.a";
   };

EMBARK_G4MH

The following sections describe the OIL fields of the LIB object customized for the official Renesas EMBARK software support.

VERSION

STAND_ALONE

The STAND_ALONE boolean attribute of EMBARK_G4MH configures the build system to generate or not a libembark_e2x.a stand-alone binary library. Otherwise, all the sources will be added to ERIKA library libee.a. The default value is set to TRUE.

Example of STAND_ALONE attribute of EMBARK_E2X:

   LIB = EMBARK_E2X  {
     STAND_ALONE = TRUE;
   };

DRIVER

This is a list of extra sub-folder of Embark/Drivers that have to be added to the build of libembark_g4mh.a

   LIB = EMBARK_G4MH {
      DRIVER = "GTM"; "Extra drivers folder from which getting source for libembark_g4mh.a";
      DRIVER = "FPE"; "Extra drivers folder from which getting source for libembark_g4mh.a";
   };