R20UT3752EJ0101-AUTOSARs

AUTOSAR Modules Overview
User’s Manual

Version 1.0.10

Target Device:
RH850/P1x

All information contained in these materials, including products and product specifications,
represents information on the product at the time of publication and is subject to change by
Renesas Electronics Corp. without notice. Please review the latest information published by
Renesas Electronics Corp. through various means, including the Renesas Electronics Corp.
website (http://www.renesas.com).

Renesas Electronics
www.renesas.com
Rev.1.01 Feb 2017

Notice

1.
Descriptions of circuits, software and other related information in this document are provided only to illustrate the operation of

semiconductor products and application examples. You are fully responsible for the incorporation or any other use of the circuits,

software, and information in the design of your product or system. Renesas Electronics disclaims any and all liability for any losses and

damages incurred by you or third parties arising from the use of these circuits, software, or information.

2.
Renesas Electronics hereby expressly disclaims any warranties against and liability for infringement or any other disputes involving patents,

copyrights, or other intellectual property rights of third parties, by or arising from the use of Renesas Electronics products or technical information

described in this document, including but not limited to, the product data, drawing, chart, program, algorithm, application examples.

3.
No license, express, implied or otherwise, is granted hereby under any patents, copyrights or other intellectual property rights of Renesas

Electronics or others.

4.
You shall not alter, modify, copy, or otherwise misappropriate any Renesas Electronics product, whether in whole or in part. Renesas Electronics

disclaims any and all liability for any losses or damages incurred by you or third parties arising from such alteration, modification, copy or

otherwise misappropriation of Renesas Electronics products.

5.
Renesas Electronics products are classified according to the following two quality grades: "Standard" and "High Quality". The intended

applications for each Renesas Electronics product depends on the product’s quality grade, as indicated below.

"Standard":          Computers; office equipment; communications equipment; test and measurement equipment; audio and visual equipment;

home electronic appliances; machine tools; personal electronic equipment; and industrial robots etc.

"High Quality":   Transportation equipment (automobiles, trains, ships, etc.); traffic control (traffic lights); large-scale communication

equipment; key financial terminal systems; safety control equipment; etc.

Renesas Electronics products are neither intended nor authorized for use in products or systems that may pose a direct threat to human life or

bodily injury (artificial life support devices or systems, surgical implantations etc.), or may cause serious property damages (space and undersea

repeaters; nuclear power control systems; aircraft control systems; key plant systems; military equipment; etc.). Renesas Electronics disclaims any

and all liability for any damages or losses incurred by you or third parties arising from the use of any Renesas Electronics product for which the

product is not intended by Renesas Electronics.

6.
When using the Renesas Electronics products, refer to the latest product information (data sheets, user’s manuals, application notes, "General

Notes for Handling and Using Semiconductor Devices" in the reliability handbook, etc.), and ensure that usage conditions are within the ranges

specified by Renesas Electronics with respect to maximum ratings, operating power supply voltage range, heat radiation characteristics,

installation, etc. Renesas Electronics disclaims any and all liability for any malfunctions or failure or accident arising out of the use of Renesas

Electronics products beyond such specified ranges.

7.
Although Renesas Electronics endeavors to improve the quality and reliability of Renesas Electronics products, semiconductor products have

specific characteristics such as the occurrence of failure at a certain rate and malfunctions under certain use conditions. Further, Renesas

Electronics products are not subject to radiation resistance design. Please ensure to implement safety measures to guard them against the

possibility of bodily injury, injury or damage caused by fire, and social damage in the event of failure or malfunction of Renesas Electronics

products, such as safety design for hardware and software including but not limited to redundancy, fire control and malfunction prevention,

appropriate treatment for aging degradation or any other appropriate measures by your own responsibility as warranty for your products/system.

Because the evaluation of microcomputer software alone is very difficult and not practical, please evaluate the safety of the final products or

systems manufactured by you.

8.
Please contact a Renesas Electronics sales office for details as to environmental matters such as the environmental compatibility of each Renesas

Electronics product. Please investigate applicable laws and regulations that regulate the inclusion or use of controlled substances, including

without limitation, the EU RoHS Directive carefully and sufficiently and use Renesas Electronics products in compliance with all these applicable

laws and regulations. Renesas Electronics disclaims any and all liability for damages or losses occurring as a result of your noncompliance with

applicable laws and regulations.

9.
Renesas Electronics products and technologies shall not be used for or incorporated into any products or systems whose manufacture, use, or sale

is prohibited under any applicable domestic or foreign laws or regulations. You shall not use Renesas Electronics products or technologies for (1)

any purpose relating to the development, design, manufacture, use, stockpiling, etc., of weapons of mass destruction, such as nuclear weapons,

chemical weapons, or biological weapons, or missiles (including unmanned aerial vehicles (UAVs)) for delivering such weapons, (2) any purpose

relating to the development, design, manufacture, or use of conventional weapons, or (3) any other purpose of disturbing international peace and

security, and you shall not sell, export, lease, transfer, or release Renesas Electronics products or technologies to any third party whether directly

or indirectly with knowledge or reason to know that the third party or any other party will engage in the activities described above. When

exporting, selling, transferring, etc., Renesas Electronics products or technologies, you shall comply with any applicable export control laws and

regulations promulgated and administered by the governments of the countries asserting jurisdiction over the parties or transactions.

10.  Please acknowledge and agree that you shall bear all the losses and damages which are incurred from the misuse or violation of the terms and

conditions described in this document, including this notice, and hold Renesas Electronics harmless, if such misuse or violation results from your

resale or making Renesas Electronics products available any third party.

11.  This document shall not be reprinted, reproduced or duplicated in any form, in whole or in part, without prior written consent of Renesas

Electronics.

12.  Please contact a Renesas Electronics sales office if you have any questions regarding the information contained in this document or Renesas

Electronics products.

(Note 1)   "Renesas Electronics" as used in this document means Renesas Electronics Corporation and also includes its majority-owned

subsidiaries.

(Note 2)   "Renesas Electronics product(s)" means any product developed or manufactured by or for Renesas Electronics.



3

2

Abbreviations and Acronyms

Abbreviation / Acronym
Description
ADC
Analog to Digital Converter
API
Application Programming Interface
ANSI
American National Standards Institute
AUTOSAR
AUTomotive Open System ARchitecture
CAN
Controller Area Network
DEM
Diagnostic Event Manager
DET/Det
Development Error Tracer
DIO
Digital Input Output
FEE
Flash EEPROM Emulation
FLS
FLaSh Driver
FSL
Flash Self programming Library
FR
Flex-Ray
GPT
General Purpose Timer
ICU
Input Capture Unit
LIN
Local Interconnect Network
MCAL
MicroController Abstraction Layer
MCU
MicroController Unit
PWM
Pulse Width Modulation
SPI
Serial Peripheral Interface
TAU
Timer Array Unit
WDG
WatchDog driver

Definitions

Term
Represented by
Sl. No.
Serial Number

5

3.2
RH850 Macros Definition: .............................................................................................. 41
3.3
ICxxx Registers Setting for TBxxx-Bit .......................................................................... 43
3.4
Deviation List .................................................................................................................. 43

9

INTRODUCTION
Chapter 1
Chapter 1
INTRODUCTION

The users for module overview, module dependencies, source code
dependencies and configuration parameter dependencies, shall use this
document as reference.

Ap
plication
Actuator
Sensor
Application
S
oftware
Software
Software
Software
AUTOSAR
AUTOSAR
Component
Component
Component
Component

Software

Software

AUTOSAR
AUTOSAR
AUTOSAR
AUTOSAR
Component
Interface
Interface
Interface

Interface

Interface

AUTOSAR Runtime Environment (RTE)
Standard

Software

AUTOSAR

Standardized
Standardized
Standardized
AUTOSAR
Interface
AUTOSAR
Interface
Interface
Interface

API 2
VFB & RTE

Interface

relevant

Services
Communication
ECU

Abstraction

API 1

RTE
Standardized
Standardized
Standardized

relevant
Interface
Interface
Interface

Operating
S
Complex
API 0
t

System
I
a
Device

nt
ndard
e
Drivers

rf

a
Standardized

API 3 Private
c
i
e
z
Interface
Interfaces inside

e
Basic Software

d

Basic Software

Microcontrolle

possible

r

Abstraction
ECU-Hardware


Figure 1-1  : System Overview of the AUTOSAR Architecture Layer

11

Chapter 1
INTRODUCTION

1.1.
Document Overview

The document has been segmented for easy reference. The table below
provides user with an overview of the contents of each section:

Section
Contents
Section1
Explains the purpose of this document.
(Introduction)
Section2
Lists the documents referred for developing this
(Reference Documents) document.
Section3
Provides the list of modules developed in the MCAL
(MCAL Modules)
layer. Brief information about the Module overview,
Modules dependency, Configuration parameter
dependency, source code dependency and stubs.

12

REFERENCE DOCUMENTS
Chapter 2
Chapter 2
REFERENCE DOCUMENTS

Sl. No.
Title For Autosar Version R4.0.3
Version
1.
Specification of ADC Driver (AUTOSAR_SWS_ADCDriver.pdf)
4.2.0
2.
Specification of CAN Driver (AUTOSAR_SWS_CANDriver.pdf)
4.0.0
3.
Specification of PWM Driver (AUTOSAR_SWS_PWMDriver.pdf)
2.5.0
4.
Specification of PORT Driver (AUTOSAR_SWS_PortDriver.pdf)
3.2.0
5.
Specification of Flash EEPROM Emulation
2.0.0
(AUTOSAR_SWS_Flash_EEPROMEmulation.pdf)
6.
Specification of DIO Driver (AUTOSAR_SWS_DIODriver.pdf)
2.5.0
7.
Specification of Module Flash Driver (AUTOSAR_SWS_FlashDriver.pdf)
3.2.0
8.
Specification of SPI Handler/Driver
3.2.0
(AUTOSAR_SWS_SPI_HandlerDriver.pdf)
9.
Specification of ICU Driver (AUTOSAR_SWS_ICUDriver.pdf)
4.2.0
10.
Specification of MCU Driver (AUTOSAR_SWS_MCUDriver.pdf)
3.2.0
11.
Specification of GPT Driver (AUTOSAR_SWS_GPTDriver.pdf)
3.2.0
12.
Specification of Watchdog Driver (AUTOSAR_SWS_WatchdogDriver.pdf)
2.5.0
13.
Specification of LIN Driver (AUTOSAR_SWS_LINDriver.pdf)
1.5.0

13

Chapter 2
REFERENCE DOCUMENTS

14

AUTOSAR MODULES
Chapter 3
Chapter 3
AUTOSAR MODULES

3.1
MCAL Module

The MicroController Abstraction layer is the lowest software layer of the Basic
Software. It contains internal drivers, which are software modules with direct
access to the μC internal peripherals and memory mapped μC external
devices. Make higher software layers independent of μC.

The modules developed for MCAL layer are as follows:
ADC
PWM
PORT
FEE
DIO
FLS
SPI
ICU
MCU
GPT
WDG
CAN
LIN
FR
FLSTST

3.1.1.  ADC Driver Component

3.1.1.1.  Module Overview

The ADC driver shall initialize and control the internal Analog Digital Converter
unit of the microcontroller. The driver is equipped with a set of basic
functionalities with single value result access mode and streaming access
mode.

A software trigger or a hardware event shall start a One Shot conversion
whereas a software trigger only shall start a Continuous conversion. An ADC
read service shall return the ADC conversion results. This service shall return
the last converted result from an external result buffer.

The ADC Driver software component shall provide the following main features:

•
Single value results access mode supports One-Shot conversion and
Continuous conversion

•
Streaming access mode supports linear buffer conversion and circular
buffer conversion

•
Various API services for functionalities like initialization, de-
initialization, starting and stopping of ADC channels

•
Notifications services for ADC channels

15

Chapter 3
AUTOSAR MODULES
•
Hardware Trigger services for ADC channels
•
Channel group priority mechanism

3.1.1.2.  Module Dependency

The dependency of ADC Driver on other modules and the required
implementation is briefed as follows:

DET

In development mode, the Development Error Tracer (DET) will be called
whenever this module encounters a development error.

PORT driver

Port pins used by the ADC Driver shall be configured using the PORT module.
Both analog input pins and external trigger pins have to be considered.

IO Hardware Abstraction Layer

The ADC driver depends on the IO Hardware Abstraction Layer, which invokes
the APIs and receives the callback notifications. If IO Hardware Abstraction
Layer Module is not available, then the required functionality shall be stubbed.

RTE

The Run time Environment (RTE) module will be called whenever a critical
section protection function is called.

OS

The ADC driver uses interrupts and therefore there is a dependency on the
OS, which configures the interrupt sources. If OS is not available, then the
configuration of interrupt sources shall be stubbed.

3.1.1.3.  Configuration Parameter Dependency

The ADC Driver Depends on the MCU Driver for clock value. Hence the
parameter ‘AdcClockRef’ in the ‘AdcHwUnit’ container refers to the path “/
Renesas/Mcu0/McuModuleConfiguration0/McuClockSettingConfig0”.

3.1.1.4.  Source Code Dependency

The following are the common dependent used files by the ADC Driver
module:

Det.h,
MemMap.h,
Platform_Types.h,
Std_Types.h,
SchM_Adc.h
Rte.h and

Os.h
rh850_Types.h

3.1.1.5.  Stubs

Stubs are categorized as common stub.

The common stubs are common for all the X1X family and are available in the
path

“X1X\common_platform\generic\stubs\<Autosar Version>\”
16

  AUTOSAR MODULES
Chapter 3

The tables below will provide the common and port specific stubs to be used
for ADC Driver component

Table 3-1  : ADC Driver Component Common Stubs

Common Stubs
Path
Det
X1X\common_platform\generic\stubs\<Autosar
Version>\Det
SchM
X1X\common_platform\generic\stubs\<Autosar
Version>\SchM
Os
X1X\common_platform\generic\stubs\<Autosar
Version>\Os

3.1.2.  PWM Driver Component

3.1.2.1.  Module Overview

The PWM Driver Component provides services for PWM Driver Component
initialization, De-initialization, Setting the Period and Duty Cycle for a PWM
channel, Reading the internal state of PWM Output signal and Setting the
PWM Output to idle state and Disabling or Enabling the PWM signal edge
notification. The PWM Driver Component is part of the Microcontroller
Abstraction Layer (MCAL), the lowest layer of Basic Software in the AUTOSAR
environment.

The PWM Driver Component is divided into PWM High Level Driver and PWM
Low Level Driver to minimize the effort and to optimize the reuse of developed
software on different platforms.

The PWM High Level Driver exports the APIs to the upper modules. All the
references to specific microcontroller features and registers are provided in
PWM Low Level Driver.

Timers TAUA, TAUB, TAUC and TAUJ are used in PWM Driver Component to
generate variable PWM output. These timers can operate in Master mode as
well as Slave mode depending on the configuration.

The channel level notifications are provided for the rising edge, falling edge
and both edges. Any of these notifications will be active only when these are
configured for the corresponding channel and enabled by using PWM Driver
Component APIs.

The PWM Driver component should provide following services based on the
functions performed by the PWM Driver:

•
Initialization

•
De-Initialization

•
Set the channel output to Idle

•
Get the channel output state

•
Set Duty Cycle

•
Set Duty Cycle and Period

•
Notification services (at the beginning, at the end and on both edged of
a period)

•
Get Version information

17

Chapter 3
AUTOSAR MODULES

3.1.2.2.  Module Dependency

The dependency of PWM Driver on other modules and the required
implementation is briefed as follows:

DET

In development mode, the Development Error Tracer (DET) will be called
whenever this module encounters a development error.

MCU Driver

The Microcontroller Unit Driver (MCU Driver) is primarily responsible for
initializing and controlling the chip’s internal clock sources and clock
pre-scalars.

PORT driver

Port pins used by the PWM Driver shall be configured using the PORT module.

IO Hardware Abstraction Layer

The PWM driver depends on the IO Hardware Abstraction Layer, which
invokes the APIs and receives the callback notifications. If IO Hardware
Abstraction Layer Module is not available, then the required functionality shall
be stubbed.

OS

The PWM driver uses interrupts and therefore there is a dependency on the
OS, which configures the interrupt sources. If OS is not available, then the
configuration of interrupt sources shall be stubbed.

RTE

The Run time Environment (RTE) module will be called whenever a critical
section protection function is called.

3.1.2.3.  Configuration Parameter Dependency

None

3.1.2.4.  Source Code Dependency

The following are the common dependent used files by the PWM Driver
module:

Det.h,
MemMap.h,
Platform_Types.h,
Std_Types.h,
SchM_Pwm.h
Rte.h and
Os.h
rh850_Types.h

3.1.2.5.  Stubs

Stubs are categorized as common stub.
18

  AUTOSAR MODULES
Chapter 3

The common stubs are common for all the X1X family and are available in the
path

“X1X\common_platform\generic\stubs\<Autosar Version>\”

The table below will provide the common stubs to be used for PWM Driver
component

Table 3-2  : PWM Driver Component Common Stubs

Common Stubs
Pat
h
Det
X1X\common_platform\generic\stubs\<Autosar
Version>\Det
SchM
X1X\common_platform\generic\stubs\<Autosar
Version>\SchM
Os
X1X\common_platform\generic\stubs\<Autosar
Version>\Os

3.1.3.  PORT Driver Component

3.1.3.1.  Module Overview

The PORT Driver Component access the hardware features directly. The
upper layers call the functionalities provided by these components.

The PORT Driver Component provides services for:

•
Initialization of every port pins to configured functionality.

•
Changing the port pin direction during run time.

•
Refreshing the port pin directions.

•
Setting the port pin mode during runtime.

•
Reading module version

3.1.3.2.  Module Dependency

The dependency of PORT Driver on other modules and the required
implementation is briefed as follows:

DET

In development mode, the Development Error Tracer (DET) will be called
whenever this module encounters a development error.

DEM

The Diagnostic Event manager (DEM) will be called whenever PORT module
encounters a production relevant error.

RTE

The Run time Environment (RTE) module will be called whenever a critical
section protection function is called.

3.1.3.3.  Configuration Parameter Dependency

None.

3.1.3.4.  Source Code Dependency

The following are the common dependent used files by the PORT Driver
module:
19

Chapter 3
AUTOSAR MODULES

Det.h,
MemMap.h,
Platform_Types.h,
Std_Types.h,
SchM_Port.h
Rte.h and
Dem.h

3.1.3.5.  Stubs

Stubs are categorized as common stub.

The common stubs are common for all the X1X family and are available in the
path

“X1X\common_platform\generic\stubs\<Autosar Version>”

The table below will provide the common stubs to be used for PORT Driver
component
Table 3-3
:  PORT Driver Component Common Stubs

Common Stubs
Pat
h
Det
X1X\common_platform\generic\stubs\<Autosar
Version>\Det
SchM
X1X\common_platform\generic\stubs\<Autosar
Version>\SchM
Dem
X1X\common_platform\generic\stubs\<Autosar
Version>\Dem

3.1.4.  FEE Software Component

3.1.4.1.  Module Overview

The FEE software component of the Memory Hardware Abstraction interface
provides the emulation access to flash driver. The FEE software component
layer provides the wrapper for the FEE EEPROM Emulation library, which
comprises of EEPROM emulation layer, Data Flash Access layer and Flash
control hardware. The FEE software component provides services for reading
from and writing to flash memory, erasing and invalidating the flash memory.

The FEE Software Component provides services for:

•
Initialization

•
Reading and Writing to the memory

•
Invalidating the memory

•
Cancellation of request

•
Reading status and result information

•
Module version information

3.1.4.2.  Module Dependency

The dependency of FEE software component on other modules and the
required implementation is briefed as follows:

DET
20

  AUTOSAR MODULES
Chapter 3

In development mode, the Development Error Tracer (DET) will be called
whenever FEE module encounters a development error.

DEM

The Diagnostic Event manager (DEM) will be called whenever FEE module
encounters a production relevant error.

RTE

The Run time Environment (RTE) module will be called whenever a critical
section protection function is called.

3.1.4.3.  Configuration Parameter Dependency

None

3.1.4.4.  Source Code Dependency

The following are the common dependent used files by the FEE Software
Component module:
Det.h,
Dem.h,
MemIf.h,
NvM.h,
MemMap.h,
Platform_Types.h,
Std_Types.h,
SchM_Fee.h and
Rte.h
rh850_Types.h

3.1.4.5.  Stubs

Stubs are categorized as common stub.

The common stubs are common for all the X1X family and are available in the
path

“X1X\common_platform\generic\stubs\<Autosar Version>”

The table below will provide the common stubs to be used for FEE Software
component.

Table 3-4
: FEE Driver Component Common Stubs

Common Stubs
Pa
th
Det
X1X\common_platform\generic\stubs\<Autosar
Version>\Det
Dem
X1X\common_platform\generic\stubs\<Autosar
Version>\Dem
NvM
X1X\common_platform\generic\stubs\<Autosar
Version>\NvM
MemIf
X1X\common_platform\generic\stubs\<Autosar
Version>\MemIf
21

Chapter 3
AUTOSAR MODULES
SchM
X1X\common_platform\generic\stubs\<Autosar
Version>\SchM

3.1.5.  DIO Driver Component

3.1.5.1.  Module Overview

The DIO Driver Component access the hardware features directly. The upper
layers call the functionalities provided by these components.

The DIO Driver Component provides services for:

•
Reading from / writing to DIO Channel

•
Reading from / writing to DIO Ports

•
Reading from / writing to DIO Channel Groups

•
Reading module version.

3.1.5.2.  Module Dependency

The dependency of DIO Driver on other modules and the required
implementation is briefed as follows:

DET

In development mode, the Development Error Tracer (DET) will be called
whenever this module encounters a development error.

PORT driver

Port pins used by the DIO Driver shall be configured using the PORT module.

3.1.5.3.  Configuration Parameter Dependency

None

3.1.5.4.  Source Code Dependency

The following are the common dependent used files by the DIO Driver module:
Det.h,
MemMap.h,
Platform_Types.h and
Std_Types.h

3.1.5.5.  Stubs

The DIO driver uses Stubs, which is categorized as common stubs
and available in the path

“X1X\common_platform\generic\stubs\<Autosar Version>”

The table below provides the common stubs to be used for DIO Driver
component:

Table 3-5
: DIO Driver Component Common Stubs

Common Stubs
P
a
Det
X1X\common_platform\generic\stubs\<Autosar
t
Version>\Det
h

22

  AUTOSAR MODULES
Chapter 3

3.1.6.  FLS Software Component

3.1.6.1.  Module Overview

The FLS software component provides services for reading, writing, comparing
and erasing flash memory. The FLS Component layer provides the wrapper for
the Renesas Self Programming Library, which comprises of API for erase/write
data to on-chip flash memory of the device. This means the FLS component
makes use of the FSL, which is an underlying software library contains FSL
functions to perform the activities like accessing and programming the on-chip
flash hardware. FSL offers all functions and commands necessary to
reprogram the application in a user-friendly C language interface. The FSL
consists of wrapper functions to the FLS routines.

The FLS Component conforms to the AUTOSAR standard and is implemented
mapping to the AUTOSAR FLS Software Specification.

The FLS Driver Software Component provides services for:

•
Initialization

•
Erasing the flash memory

•
Reading from the flash memory

•
Writing to the flash memory

•
Validating contents of flash memory

•
Cancellation of Request

•
Job result and status information

•
Background job processing

•
Module version information

•
Job Processing

3.1.6.2.  Module Dependency

The dependency of FLS software component on other modules and the
required implementation is briefed as follows:

DET
In development mode, the Development Error Tracer (DET) will be called
whenever this module encounters a development error.

DEM

The Diagnostic Event manager (DEM) will be called whenever this module
encounters a production relevant error.

RTE

The Run time Environment (RTE) module will be called whenever a critical
section protection function is called.

3.1.6.3.  Configuration Parameter Dependency

None

3.1.6.4.  Source Code Dependency

The following are the common dependent used files by the FLS Software
23

Chapter 3
AUTOSAR MODULES
Component module:
Det.h,
Dem.h,
MemMap.h,
Platform_Types.h,
Std_Types.h,
SchM_Fls.h,
Rte.h
rh850_Types.h

3.1.6.5.  Stubs

Stubs are categorized as common stub.

The common stubs are common for all the X1X family and are available in the
path

“X1X\common_platform\generic\stubs\<Autosar Version>”

The tables below will provide the common stubs to be used for FLS Software
component.

Table 3-6
:  FLS Software Component Common Stubs

Common Stubs
Pa
th
Det
X1X\common_platform\generic\stubs\<Autosar
Version>\Det
Dem
X1X\common_platform\generic\stubs\<Autosar
Version>\Dem
SchM
X1X\common_platform\generic\stubs\<Autosar
Version>\SchM

3.1.7.  SPI Driver Component

3.1.7.1.  Module Overview

The SPI driver is split as High Level Driver and Low Level Driver. The High
Level Driver exports the AUTOSAR API towards upper modules and it will be
designed to allow the compilation for different platforms without or only slight
modifications, i.e. that no reference to specific microcontroller features or
registers will appear in the High Level Driver. All these references are moved
inside a µC specific Low Level Driver. The Low Level Driver interface extends
the High Level Driver types and methods in order to adapt it to the specific
target microcontroller.

The SPI Driver Component provides services for:

•
Initialization and De-initialization

•
Buffer Management

•
Communication

•
Status information

•
Module version information

24

  AUTOSAR MODULES
Chapter 3
•
Memory mapping

•
Compiler abstraction

3.1.7.2.  Module Dependency

The dependency of SPI Driver on other modules and the required
implementation is briefed as follows:

DET

In development mode, the Development Error Tracer (DET) will be called
whenever this module encounters a development error.

PORT

The CSIG HW Units uses port lines as external chip selects. In this case, the
chip select is realized using microcontroller pins and hence the SPI module
has a relationship with PORT module for initializing appropriate mode and
direction of the port lines.

The basic SPI functionality for both CSIG and CSIH has to be configured as an
alternate functionality by the PORT module.

MCU Driver

The configuration of SPI module for jobs contains the references to the MCU
module for the input clock frequency for the SPI HW Unit. Hence, SPI baud
rate depends on the frequency set in the MCU module.

IO Hardware Abstraction Layer

The IO Hardware Abstraction Layer invokes APIs of the SPI module and
receives the callback notifications.

Memory Hardware Abstraction Layer

The Memory Hardware Abstraction Layer invokes APIs of the SPI module in
case driver for any external memory devices (for example, external EEPROM)
are implemented through the SPI module.

Onboard Device Abstraction Layer
The Onboard Device Abstraction Layer invokes APIs of the SPI module in
case driver for any external devices (for example, external watchdog) are
implemented through the SPI module.

RTE

The functions related to critical section protection area of the SPI module are
invoked by the Run time Environment (RTE) module.

DEM

The SPI module uses the DEM module for getting the reference for all
production errors.

3.1.7.3.  Configuration Parameter Dependency

The SPI Driver Depends on the MCU Driver for clock value. Hence, the
parameter ‘SpiClockFrequencyRef’ in the ‘SpiExternalDevice’ container refers
to the path
“/Renesas/Mcu0/McuModuleConfiguration0/McuClockSettingConfig0”.

3.1.7.4.  Source Code Dependency

The following are the common dependent used files by the SPI Driver module:
Det.h,
25

Chapter 3
AUTOSAR MODULES
Dem.h,
MemMap.h,
Platform_Types.h,
Std_Types.h,
SchM_Spi.h
Rte.h and

Os.h
rh850_Types.h

3.1.7.5.  Stubs

Stubs are categorized as common stub.

The common stubs are common for all the X1X family and are available in the
path

“X1X\common_platform\generic\stubs\<Autosar Version>”

The tables below will provide the common and port specific stubs to be used
for SPI Driver component

Table 3-7
: SPI Driver Component Common Stubs

Common Stubs
         Path
Det
X1X\common_platform\generic\stubs\<Autosar
Version>\Det
Dem
X1X\common_platform\generic\stubs\<Autosar
Version>\Dem
SchM
X1X\common_platform\generic\stubs\<Autosar
Version>\SchM
Os
X1X\common_platform\generic\stubs\<Autosar
Version>\Os

Table 3-8
:  SPI Driver Component Port Specific Stubs

Common Stubs
       Path
Mcu
X1X\common_platform\generic\stubs\<Autosar
Version>\Mcu

3.1.8.  ICU Driver Component

3.1.8.1.  Module Overview

The ICU Driver Component provides following services:

•
Signal Edge detection and notification

•
Services for Driver initialization and de-initialization

•
Signal time measurement like period and duty cycle

•
Signal Edge time stamping and edge counting

•
Support post-build configurations

The ICU Driver Component is part of the Microcontroller Abstraction Layer
(MCAL), the lowest layer of Basic Software in the AUTOSAR environment.
26

AUTOSAR MODULES
Chapter 3
Different applications require different number of ICU channels in different
modes. Therefore, the timer, timer operation modes and external
interrupts have to be selected depending on ICU measurement mode. For
the X1X microcontroller generation following concepts will be considered:

•
Using TAU A and TAU B for Edge Counting Measurement mode

•
Using TAU A, TAU B and TAU J for Time Stamping Measurement mode

•
Using TAU A, TAU B and TAU J for Signal Measurement mode

•
Using External Interrupts for Edge Detection mode

Either the ICU channel can be configured to a timer channel or an external
interrupt based on the required measurement mode. The configuration for
Edge Detection measurement mode will be made only for an external interrupt
channel and not for any of the Timer channels. The remaining three-
measurement modes viz. Edge Counting, Time Stamping and Signal
Measurement should be configured only for the timer channels. The
configuration of Timer in different operating modes will be taken care by the
software itself.

The ICU Driver component can be divided into following sections based on the
functions performed by the ICU Driver:

•
Initialization

•
De-Initialization

•
Wakeup

•
Notification

•
Signal Measurement

•
Signal Activation and State Information

•
Version Information

Various timers can be started at the same time by setting the related enable
bits. The input signal can be split from one port pin to two consecutive TAU
inputs, which allows the signal for period or duty cycle measurement to be fed
into only one port pin.

3.1.8.2. Module Dependency

The dependency of ICU Driver on other modules and the required
implementation is briefed as follows:

MCU Driver

The ICU Driver depends on MCU for the setting of system clock and PLL and
the length of the timer ticks depends on the clock settings made in MCU
module. If MCU module is not available, the functionality of system clock and
PLL settings shall be stubbed.

OS

The ICU driver uses interrupts and therefore there is a dependency on the
OS, which configures the interrupt sources. If OS is not available, then the
configuration of interrupt sources shall be stubbed.

PORT Module

The PORT driver does the configuration of port pins used for the ICU as
inputs. Hence, the PORT driver has to be initialized prior to the use of ICU
functions. If the PORT Driver is not available, then the configuration of port
pins used for the ICU shall be stubbed.

27

Chapter 3
AUTOSAR MODULES
In order to use the external interrupt functionality, port filter of respective
external interrupt needs to be enabled in PORT component. ICU can override
edge detection settings and PORT can do as well. ICU uses the registers
FCLAxCTLx and PORT at the same time and the order of calling APIs is
important.

EcuM Module

The ICU driver shall do the reporting of wakeup interrupts to the EcuM. If the
EcuM is not available, and then the required functionality shall be stubbed.

DET Module

If the Development Error Tracer is not available, stubs need to be used to the
interfaces for those modules.

IO Hardware Abstraction Layer Module

The ICU driver depends on the I/O Hardware Abstraction Layer, which invokes
the APIs and receives the call-back notifications. If I/O Hardware Abstraction
Layer Module is not available, then the required functionality shall be stubbed.

RTE Module

The ICU driver shall perform data protection using SchM APIs. If the SchM is
not available, then the required functionality shall be stubbed.

3.1.8.3.  Configuration Parameter Dependency

The ICU Driver Depends on EcuM. Hence the parameter
‘IcuChannelWakeupInfo’ in the ‘IcuWakeup’ container of each channel refers
to the path “/AUTOSAR/Ecudefs_EcuM/EcuMConfiguration_1/
EcuMWakeupSource_1”.

3.1.8.4.  Source Code Dependency

The following are the common dependent used files by the ICU Driver module:
Det.h,
MemMap.h,
Platform_Types.h,
Std_Types.h,
SchM_Icu.h,
Rte.h,
EcuM.h
EcuM_Cfg.h
EcuM_Cbk.h and
Os.h
rh850_Types.h

3.1.8.5.  Stubs

Stubs are categorized as common stub.

The common stubs are common for all the X1X family and are available in the
path

“X1X\common_platform\generic\stubs\<Autosar Version>”

The table below will provide the common to be used for ICU Driver component.
28

  AUTOSAR MODULES
Chapter 3

Table 3-9
: ICU Driver Component Common Stubs

Common Stubs
P
a
Det
X1X\common_platform\generic\stubs\<Autosar
t
Version>\Det
h
Dem
X1X\common_platform\generic\stubs\<Autosar
Version>\Dem
EcuM
X1X\common_platform\generic\stubs\<Autosar
Version>\EcuM
Os
X1X\common_platform\generic\stubs\<Autosar
Version>\Os

3.1.9.  MCU Driver Component

3.1.9.1.  Module Overview

The MCU Driver accesses the hardware features directly. The upper layers call
the functionalities provided by the Driver. MCU component has functionalities
related PLL Initialization, Clock Initialization & Distribution, RAM sections, Pre-
Scaler Initializations, MCU Reduced Power Modes Activation and MCU Reset
Activation & Reason.

The MCU Driver component is divided into the following sub modules based
on the functionality required:

•
Initialization

•
Clock Initialization

•
PLL Clock Distribution

•
MCU Reduced Power Modes Activation

•
RAM sections Initialization

•
MCU Reset Activation & Reason

•
Module Version Info

3.1.9.2.  Module Dependency

DET

In development mode the Development Error Tracer (DET) will be called
whenever this module encounters a development error.

DEM

Production errors will be reported to the Diagnostic Event Manager (DEM).

EcuM

The reference for the type of reset will be provided by the Mcu driver to the
ECU State manager module.

OS

The MCU driver uses interrupts and therefore there is a dependency on the
OS which configures the interrupt sources. If OS is not available, then the
configuration of interrupt sources shall be stubbed.

29

Chapter 3
AUTOSAR MODULES
3.1.9.3.  Configuration Parameter Dependency

None

3.1.9.4.  Source Code Dependency

The following are the common dependent used files by the MCU Driver
module:

Det.h,
Dem.h
MemMap.h,
Platform_Types.h,
Std_Types.h,
Rte.h,
SchM_Mcu.h
Os.h
rh850_Types.h

3.1.9.5.  Stubs

Stubs are categorized as common stub.

The common stubs are common for all the X1X family and are available in the
path

“X1X\common_platform\generic\stubs\<Autosar Version>”

The table below will provide the common stubs to be used for MCU Driver
component.

Table 3-10
:  MCU Driver Component Common Stubs

Common Stubs
Pat
h
Det
X1X\common_platform\generic\stubs\<Autosar
Version>\Det
Dem
X1X\common_platform\generic\stubs\<Autosar
Version>\Dem
SchM
\X1X\common_platform\generic\stubs\<Autosar
Version>\SchM
Os
X1X\common_platform\generic\stubs\<Autosar
Version>\Os

3.1.10. GPT Driver Component

3.1.10.1. Module Overview

The GPT Driver Component provides services for GPT Driver Component
Initialization, De-initialization, Setting starting and stopping a timer, getting
elapsed and remaining time, setting GPT mode (one shot, continuous) and
Disabling or Enabling the GPT notification. The GPT Driver Component is part
of the Microcontroller Abstraction Layer (MCAL), the lowest layer of Basic
Software in the AUTOSAR environment.

The GPT Driver Component is divided into GPT High Level Driver and GPT
Low Level Driver to minimize the effort and to optimize the reuse of developed
30

AUTOSAR MODULES
Chapter 3
software on different platforms.

The GPT High Level Driver exports the APIs to the upper modules. All the
references to specific microcontroller features and registers are provided in
GPT Low Level Driver.

The GPT channel can be configured to either as continuous mode or one-shot
mode. In continuous mode, the timers keep operating even after the target
value is reached and it has multiple notifications (if enabled).

Timers OSTM, TAUA TAUB, TAUC and TAUJ are used in GPT Driver
Component to generate timeout periods.

The GPT Driver component should provide following services based on the
functions performed by the GPT Driver:

•
Initialization: Provides the service to initialize the timer control registers and
interrupt registers De-Initialization: Provides the service to reinitialize the timer
registers and to stop the channels that are running

•
Reading of timer values: Provides services for reading the elapsed time after the
timer is started or Service for reading the remaining time before the next
timeout

•
Start/Stop timer: Provides the service to start/stop the requested timer
channel

•
Set mode for GPT(continuous, one shot): Provides services for the user to
select the mode

•
Notification services: Provides services for the user to enable or disable the
notification for every timeout

•
Wakeup Services: Provides services for the user to enable or disable the
wakeup notification.

•
Get version information: Provides the service for the user to read module
version

3.1.10.2. Module Dependency

The dependency of GPT Driver on other modules and the required
implementation is briefed as follows:

DET

In development mode the Development Error Tracer will be called whenever
this module encounters a development error.

IO Hardware Abstraction Layer

The GPT driver depends on the IO Hardware Abstraction Layer, which invokes
the APIs and receives the callback notifications. If IO Hardware Abstraction
Layer Module is not available, then the required functionality shall be stubbed

MCU Driver

The GPT Driver component depends on MCU module for the setting of system
clock, prescaler(s) and PLL. Thus any change in the system clock (For
example, PLL On -> PLL Off) also affects the clock settings of GPT hardware.
If MCU module is not available, the functionality of system clock prescaler(s)
and PLL settings shall be stubbed.

EcuM

The GPT driver shall do the reporting of wakeup interrupts to the EcuM. If the
EcuM is not available, then the required functionality shall be stubbed.
31

Chapter 3
AUTOSAR MODULES

RTE

The Run time Environment (RTE) module will be called whenever a critical
section protection function is called.

OS

The GPT driver uses interrupts and therefore there is a dependency on the
OS which configures the interrupt sources. If OS is not available, then the
configuration of interrupt sources shall be stubbed.

3.1.10.3. Configuration Parameter Dependency

The GPT Driver Depends on EcuM. Hence the parameter
‘GptWakeupSourceRef’ in the ‘GptWakeupConfiguration’ container of each
channel refers to the path “/AUTOSAR/EcuDefs_EcuM/
EcuMConfiguration_1/ EcuMWakeupSource_1”.

The GPT Driver Depends on the MCU Driver for clock value. Hence the
parameter GptTauUnitClkRefPoint in the container GptTaUnit refers to the
path “/Renesas/Mcu0/McuModuleConfiguration0/McuClockSettingConfig0”.

3.1.10.4. Source Code Dependency

The following are the common dependent used files by the GPT Driver
module:

Det.h,
MemMap.h,
Platform_Types.h,
Std_Types.h,
SchM_Gpt.h,
Rte.h,
Os.h
EcuM_Cfg.h,
EcuM.h and
EcuM_Cbk.h
rh850_Types.h

3.1.10.5. Stubs

Stubs are categorized as common stub.

The common stubs are common for all the X1X family and are available in the
path

“X1X\common_platform\generic\stubs\<Autosar Version>”

The table below will provide the common stubs to be used for GPT Driver
component.

Table 3-11  :  GPT Driver Component Common Stubs

Common Stubs
         Path
Det
X1X\common_platform\generic\stubs\<Autosar
Version>\Det
32

AUTOSAR MODULES
Chapter 3
Dem
X1X\common_platform\generic\stubs\<Autosar
Version>\Dem
EcuM
X1X\common_platform\generic\stubs\<Autosar
Version>\EcuM
Os
X1X\common_platform\generic\stubs\<Autosar
Version>\Os

3.1.11. WDG Driver Component

3.1.11.1. Module Overview

To minimize the effort and to optimize the reuse of developed software, the
Watchdog interface will invoke the corresponding drivers in case when multiple
drivers exist.
In case of more than one Watchdog device and Watchdog Driver (both internal
software Watchdog and external hardware Watchdog) is used on an ECU,
Watchdog Interface module allows the upper layer to select the correct
Watchdog Driver and Watchdog device while retaining the API and
functionality of the underlying driver.

The Watchdog Driver architectural design is shown in the above Figure. The
Watchdog Driver accesses the microcontroller hardware directly and Interface
communicates with the application.

The Watchdog Driver component is composed of following modules:

•
Watchdog Driver Initialization module

•
Watchdog Driver SetMode module

•
Watchdog Driver Trigger module

•
Watchdog Driver Version info module

3.1.11.2. Module Dependency

DET

In development mode the Development Error Tracer (DET) will be called
whenever this module encounters a development error.

DEM

Production errors will be reported to the Diagnostic Event Manager (DEM).

RTE

The Run time Environment (RTE) module will be called whenever a critical
section protection function is called.

MCU Driver

The count which indicates the number of times the watchdog should be
triggered for a trigger condition’s timeout value depends on WDTATCLKI,
hence MCU reference path will be provided in the parameter definition file.

OS

The WDG driver uses interrupts and therefore there is a dependency on the
OS which configures the interrupt sources. If OS is not available, then the
configuration of interrupt sources shall be stubbed.

3.1.11.3. Configuration Parameter Dependency

None
33

Chapter 3
AUTOSAR MODULES

3.1.11.4. Source Code Dependency

The following are the common dependent used files by the WDG Driver
module:

Det.h,
Dem.h
WdgIf_Types.h
MemMap.h,
Platform_Types.h,
Rte.h
Std_Types.h
Os.h
rh850_Types.h

3.1.11.5. Stubs

Stubs are categorized as common stub.

The common stubs are common for all the X1X family and are available in the
path

“X1X\common_platform\generic\stubs\<Autosar Version>”

The table below will provide the common stubs to be used for WDG Driver
component.

Table 3-12
:  WDG Driver Component Common Stubs

Common Stubs
       Path
Det
X1X\common_platform\generic\stubs\<Autosar
Version>\Det
Dem
X1X\common_platform\generic\stubs\<Autosar
Version>\Dem
WdgIf
X1X\common_platform\generic\stubs\<Autosar
Version>\WdgIf
Os
X1X\common_platform\generic\stubs\<Autosar
Version>\Os

3.1.12. CAN Driver Component
3.1.12.1. Module Overview

The CAN driver is part of the microcontroller abstraction layer (MCAL),
performs the hardware access and offers hardware independent API to the
upper layer. The only upper, which has access to the CAN driver, is the CAN
interface. Several CAN Controllers can be controlled by the CAN Driver as
long as they belong to the same CAN Hardware Unit.

The CAN Driver software component shall provide the following main features:

The CAN Driver Component fulfills requirements of upper layer
communication components with respect to Initialization, Transmit
confirmation, Receive indication, BusOff to CAN Interface layer and Wakeup
34

AUTOSAR MODULES
Chapter 3
notification to ECU State Manager.

3.1.12.2. Module Dependency

The dependency of CAN Driver on other modules and the required
implementation is briefed as follows:

DET
In development mode the Development Error Tracer (DET) will be called
whenever this module encounters a development error.

MCU Driver

CAN driver depend on MCU Driver for the setting of channel clock.

CAN Interface

The CAN Driver Component provides the following functionalities to the CAN
Interface layer

•
To change the operation mode of the controllers.

•
To Enable/Disable the Controller Interrupts

•
To process the L-PDU Transmission

ECU State Manager

If controller wake-up event is detected CAN Driver Component provides the
call out notification functionality to the EcuM.

OS

The CAN driver uses interrupts and hence there is a dependency on the OS,
which configures the interrupt sources. If OS is not available, then the
configuration of interrupt sources shall be stubbed.

3.1.12.3. Configuration Parameter Dependency

The CAN Driver Depends on the MCU Driver for clock value. Hence the
parameter ‘CanControllerClock’ in the ‘CanController’ container refers to the
path “/Renesas/Mcu0/McuModuleConfiguration0/McuClockSettingConfig0”.

3.1.12.4. Source Code Dependency

The following are the common dependent used files by the CAN Driver
module:

Det.h,
CanIf_Cbk.h,
EcuM_Cfg.h,
EcuM_Cbk.h,
Dem.h
MemMap.h,
Platform_Types.h,
Std_Types.h,
35

Chapter 3
AUTOSAR MODULES
Rte.h and

SchM_Can.h
rh850_Types.h

3.1.12.5. Stubs

Stubs are categorized as common stub.

The common stubs are common for all the X1X family and are available in the
path

“X1X\common_platform\generic\stubs\<Autosar Version>”

The tables below will provide the common and port specific stubs to be used
for CAN Driver component

Table 3-13
:  CAN Driver Component Common Stubs

Common Stubs
         Path
Det
\X1X\common_platform\generic\stubs\<Autosar
Version>\Det
EcuM
\X1X\common_platform\generic\stubs\<Autosar
Version>\EcuM
SchM
\X1X\common_platform\generic\stubs\<Autosar
Version>\SchM
Dem
\X1X\common_platform\generic\stubs\<Autosar
Version>\Dem
CanIf
\X1X\common_platform\generic\stubs\<Autosar
Version>\CanIf
Os
\X1X\common_platform\generic\stubs\<Autosar
Version>\Os

Table 3-14
: CAN Driver Component Port Specific Stubs

Port Specific Stubs             Path
Mcu
\X1X\common_platform\generic\stubs\<Autosar
Version>\Mcu

3.1.13. LIN Driver Component

3.1.13.1.
Module Overview

The LIN driver is part of the microcontroller abstraction layer (MCAL),
performs the hardware access and offers hardware independent API to the
upper layer. Several LIN Controllers is controlled by the LIN Driver as long as
they belong to the same LIN Hardware Unit.

The LIN Driver software component shall provide the following main features:

The LIN Driver Component fulfills requirements of upper layer
communication components with respect to Initialization, Transmit and
Receive confirmation and Wakeup notification to ECU State Manager.

36

  AUTOSAR MODULES
Chapter 3
3.1.13.2.
Module Dependency

The dependency of LIN Driver on other modules and the required
implementation is briefed as follows:
DET

In development mode the Development Error Tracer (DET) will be called
whenever this module encounters a development error.

DEM

The Diagnostic Event manager (DEM) will be called whenever LIN module
encounters a production relevant error.

MCU Driver

LIN driver depend on MCU Driver for the setting of channel clock.

ECU State Manager

If controller wake-up event is detected LIN Driver Component provides the
call out notification functionality to the EcuM.

OS

The LIN driver uses interrupts and hence there is a dependency on the OS,
which configures the interrupt sources. If OS is not available, then the
configuration of interrupt sources shall be stubbed.

3.1.13.3.
Configuration Parameter Dependency

The LIN Driver Depends on the MCU Driver for clock value. Hence the
parameter ‘LinChannelClockRef’ in the ‘LinChannel’ container refers to the
path

For RLIN2:
“/Renesas/EcucDefs_Mcu/Mcu0/McuModuleConfiguration0/McuClockSettin
gConfig0/McuIsoLin0”

For RLIN3:
“/Renesas/EcucDefs_Mcu/Mcu0/McuModuleConfiguration0/McuClockSettin
gConfig0/McuIsoLin30”

3.1.13.4.
Source Code Dependency

The following are the common dependent used files by the LIN Driver
module:

Det.h,
EcuM.h,
EcuM_Cfg.h,
EcuM_Cbk.h,
EcuM_Types.h,
Dem.h
MemMap.h,
Platform_Types.h,
Std_Types.h,
Rte.h and

37

Chapter 3
AUTOSAR MODULES
SchM_Lin.h
rh850_Types.h
3.1.13.5.
Stubs

Stubs are categorized as common stub.

The common stubs are common for all the X1X family and are available in the
path

“X1X\common_platform\generic\stubs\<Autosar Version>”

The tables below will provide the common and port specific stubs to be used
for LIN Driver component

Table 3-15
:  LIN Driver Component Common Stubs

Common Stubs
Path
Det
\X1X\common_platform\generic\stubs\<Autosar
Version>\Det
EcuM
\X1X\common_platform\generic\stubs\<Autosar
Version>\EcuM
SchM
\X1X\common_platform\generic\stubs\<Autosar
Version>\SchM
Dem
\X1X\common_platform\generic\stubs\<Autosar
Version>\Dem
Os
\X1X\common_platform\generic\stubs\<Autosar
Version>\Os

Table 3-16
:  LIN Driver Component Port Specific Stubs

Port Specific Stubs
Path
Mcu
\X1X\common_platform\generic\stubs\<Autosar
Version>\Mcu

3.1.14. FR Driver Component

3.1.14.1.  Module Overview

The FR driver provides services for FlexRay communication.

The FR driver component provides the following functionalities:

•
To initialize the FlexRay communication controllers

•
To start, halt or abort the communication

•
To  configure  the  channel for  sending the  wakeup pattern  and  to  transmit
the wakeup pattern on the configured FlexRay channel

•
To get the current POC status of CC

•
To  get  the  synchronization state  of  CC  and  to  adjust  the  global  time  of
a FlexRay CC to an external clock source

•
To transmit the frames on the FlexRay channels

•
To receive the frames transmitted on the FlexRay channels

38

  AUTOSAR MODULES
Chapter 3
•
To get the current cycle and macrotick offset value of CC

•
To set the value for absolute timer interrupt  and to stop the absolute timer

•
To enable/disable the absolute timer interrupt.  To   reset   the   interrupt
condition  of    absolute  timer  interrupt  and  to  get  the  status  of  absolute
timer interrupt

•
To  get  the  Channel  status,  Clock  Correction,  Number  of  startup  frames,
Clock Correction, Sync frame list and wakeup Rx status of CC

•
To get the Nm Vector Information received on CC

•
To send CC to ALLSLOTS and ALLOW_COLDSTART modes

•
To reconfigure or disable an Lpdu in run time.

3.1.14.2.  Module Dependency

The dependency of FR Driver on other modules and the required
implementation is briefed as follows:

DET

In development mode the Development Error Tracer (DET) will be called
whenever this module encounters a development error.

DEM

The Diagnostic Event manager (DEM) will be called whenever FR module
encounters a production relevant error.

OS

The FR driver uses interrupts and hence there is a dependency on the OS,
which configures the interrupt sources. If OS is not available, then the
configuration of interrupt sources shall be stubbed.

3.1.14.3.  Configuration Parameter Dependency

None

3.1.14.4.  Source Code Dependency

The following are the common dependent used files by the FR Driver
module:

Det.h,
Dem.h
MemMap.h,
Platform_Types.h,
Std_Types.h,
Rte.h and

SchM_Fr_59_Renesas.h

rh850_Types.h

3.1.14.5.  Stubs

Stubs are categorized as common stub.

The common stubs are common for all the X1X family and are available in the
39

Chapter 3
AUTOSAR MODULES
path

“X1X\common_platform\generic\stubs\<Autosar Version>”

The tables below will provide the common and port specific stubs to be used
for FR Driver component

Table 3-17
:  FR Driver Component Common Stubs

Common Stubs
Path
Det
\X1X\common_platform\generic\stubs\<Autosar
Version>\Det
SchM
\X1X\common_platform\generic\stubs\<Autosar
Version>\SchM
Dem
\X1X\common_platform\generic\stubs\<Autosar
Version>\Dem
Os
\X1X\common_platform\generic\stubs\<Autosar
Version>\Os

3.1.15. FLSTST Driver Component

3.1.15.1. Module Overview

The FLSTST Driver Component provides the following services:

• FLSTST Driver Component initialization

• De-initialization

• Reading the internal state of FLSTST Output signal

• Setting the FLSTST Output to Idle state

• Disabling/Enabling the FLSTST signal edge notification

3.1.15.2. Module Dependency

The dependency of FLSTST Driver on other modules and the
required implementation is briefed as follows:

DET

In development mode the Development Error Tracer (DET) will be called
whenever this module encounters a development error.

DEM

The Diagnostic Event manager (DEM) will be called whenever FLSTST module
encounters a production relevant error.

RTE

The Run time Environment (RTE) module will be called whenever a critical
section protection function is called.

3.1.15.3. Configuration Parameter Dependency

None

40

  AUTOSAR MODULES
Chapter 3
3.1.15.4. Source Code Dependency

The following are the common dependent used files by the FLSTST
Driver module:

Det.h,
Dem.h
MemMap.h,
Platform_Types.h,
Std_Types.h,
Rte.h and

SchM_FlsTst.h
rh850_Types.h

3.1.15.5. Stubs

Stubs are categorized as common stub.

The common stubs are common for all the X1X family and are available in the
path

“X1X\common_platform\generic\stubs\<Autosar Version>”

The tables below will provide the common and port specific stubs to be used
for FLSTST Driver component

Table 3-18
:  FLSTST Driver Component Common Stubs

  Common Stubs
                 Path
Det
\X1X\common_platform\generic\stubs\<Autosar
Version>\Det
SchM
\X1X\common_platform\generic\stubs\<Autosar
Version>\SchM
Dem
\X1X\common_platform\generic\stubs\<Autosar
Version>\Dem

3.2
RH850 Macros Definition:
  The file rh850_Types.h shall be modified by the user if the driver has to
be run in user mode.
  If the macros are modified then the user has to ensure the correct
context switching happens through the OS and this will be at the user's
responsibility.
  If the user can guarantee that the correct context switch happens and
the only restriction that the driver has is the access of IMR/ICR registers,
then this should work.
The driver supports both Supervisor mode and User mode.
To provide the provision to the user, to adapt the Driver to operate either in
Supervisor/User Mode the IMRx/ICxxx register is moved to OS Module.

41

Chapter 3
AUTOSAR MODULES
The macros provided in Table 3-17, available in rh850_types.h, should be
used as mentioned below to switch modes.

To operate the driver in User Mode: User must modify these macros.

To operate the driver in Supervisor Mode: No modification is required.

Table   3-19
:  Macros to perform write operation on write enabled
Register.
Macro Name
Description
Input Parameter
RH850_SV_
This Macro performs
SIZE : Register
MODE_ICR_
supervisor mode (SV) write
Access Size
OR
enabled Register ICxxx
ADDR : Register
register writing which involves
address
an OR operation.
VAL  : Value to be
written to the
register
RH850_SV_
This Macro performs
SIZE : Register
MODE_ICR_
supervisor mode(SV) write
Access Size
AND
enabled Register ICxxx
ADDR : Register
register writing which
address
involves an AND operation.
VAL  : Value to be
written to the
register
RH850_SV_
This Macro performs
SIZE : Register
MODE_ICR_
supervisor mode(SV) write
Access Size
WRITE_ONL
enabled Register ICxxx
ADDR : Register
Y
register direct writing
address
VAL  : Value to be
operation.
written to the
register
RH850_SV_
This Macro performs
SIZE : Register
MODE_IMR
supervisor mode(SV) write
Access Size
_OR
enabled Register IMR
ADDR : Register
register writing which
address
involves an OR operation
VAL  : Value to be
written to the
register
RH850_SV_
This Macro performs
SIZE : Register
MODE_IMR
supervisor mode(SV) write
Access Size
_AND
enabled Register IMR
ADDR : Register
register writing which
address
involves an AND operation
VAL  : Value to be
written to the
register
RH850_SV_
This Macro performs
SIZE : Register
MODE_IMR
supervisor mode (SV) write
Access Size
_WRITE_ON
enabled Register IMR
ADDR : Register
LY
register direct writing
address
operation.
VAL  : Value to be
written to the
register

42

  AUTOSAR MODULES
Chapter 3

3.3
ICxxx Registers Setting for TBxxx-Bit
  The ICxxx register’s TBxxx-Bit is used to select the way to determine the
interrupt vector.
0: Direct jumping to an address determined from the level of priority
1: Reference to a table.

  MCAL Driver does not set TBxxx bit. Hence user has to take care of
setting TBxxx-Bit before initializing MCAL driver.

3.4
Deviation List
  Autosar requirement ‘ecuc_sws_1014’ is violated in the PDF files across
all the MCAL modules.

43

Chapter 3
AUTOSAR MODULES

44

Revision History

Sl.No.  Description
Version
Date
1.
Initial Version
1.0.0
31-Jan-2013
2.
Following changes are made:
1.0.1
24-Jan-2014
1. On front page F1L is replaced by X1x.
3.
Following changes are made:
1.0.2
29-Jan-2014
1. New section 3.1.13 is added for LIN driver component.
2. Alignment is done in throughout the file.
4.
Following change is made:
1.0.3
30-Jan-2014
1. Canif stub is removed from table 13-15 and accordingly
description is updated in section 13.1.13.1.
5.
Following changes are made:
1.0.4
08-Apr-2014
1. R-number is updated for document.
2. Alignment is updated as per template.
6.
Following changes are made:
1.0.5
17-Jun-2014
1. Section 3.1 is updated for source code dependency files
2. New Section 3.2 is added for RH850 Macro definition
7.
Following changes are made:
1.0.6
17-Jul-2014
1. New Section 3.3 is added for adding information about ICxxx
registers.
8.
Following changes are made:
1.0.7
09-Aug-2014
1. Copyright information is updated.

2. Document is updated as per template.

9.
Following changes are made:

1.0.8
31-Mar-2016
1. Copyright information is updated.

2. Added FR and FLSTST

10
Following changes are made:

1.0.9
14-Jul-2016
   1. R-Number has been update.
2. Table 3-12 alignment is corrected.
11
Following changes are made:
1.0.10
17-Feb-2017
1. New section 3.4 added for Deviation List.
2. Updated section 3.2 ‘RH850 Macros Definition’ for adding
explanation regarding usage and modification of macros.
3. Updated R-Number.
4. Updated notice and copyright information.
5. Removed 3.2.2 related information from Chapter 2 ‘Reference
Documents’ and ‘Definitions’.
6. Corrected page numbers

45

AUTOSAR Modules Overview User’s Manual
Version 1.0.10

Publication Date: Rev.1.01, February 17, 2017

Published by: Renesas Electronics Corporation

SALES  OFFICES

http://www.renesas.com
Refer  to "http://www.renesas.com/" for the latest  and  de  tailed  information.
Renesas Electronics America Inc.
2801 Scott Boulevard Santa Clara, CA 95050-2549, U.S.A.
Tel: +1-408-588-6000, Fax: +1-408-588-6130
Renesas Electronics Canada Limited
9251 Yonge Street, Suite 8309 Richmond Hill, Ontario Canada L4C 9T3
Tel: +1-905-237-2004
Renesas Electronics Europe Limited
Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, U.K
Tel: +44-1628-585-100, Fax: +44-1628-585-900
Renesas Electronics Europe GmbH
Arcadiastrasse 10, 40472 Düsseldorf, Germany
Tel: +49-211-6503-0, Fax: +49-211-6503-1327
Renesas Electronics (China) Co., Ltd.
Room 1709, Quantum Plaza, No.27 ZhiChunLu Haidian District, Beijing 100191, P.R.China
Tel: +86-10-8235-1155, Fax: +86-10-8235-7679
Renesas Electronics (Shanghai) Co., Ltd.
Unit 301, Tower A, Central Towers, 555 Langao Road, Putuo District, Shanghai, P. R. China 200333
Tel: +86-21-2226-0888, Fax: +86-21-2226-0999
Renesas Electronics Hong Kong Limited
Unit 1601-1611, 16/F., Tower 2, Grand Century Place, 193 Prince Edward Road West, Mongkok, Kowloon, Hong Kong
Tel: +852-2265-6688, Fax: +852 2886-9022
Renesas Electronics Taiwan Co., Ltd.
13F, No. 363, Fu Shing North Road, Taipei 10543, Taiwan
Tel: +886-2-8175-9600, Fax: +886 2-8175-9670
Renesas Electronics Singapore Pte. Ltd.
80 Bendemeer Road, Unit #06-02 Hyflux Innovation Centre, Singapore 339949
Tel: +65-6213-0200, Fax: +65-6213-0300
Renesas Electronics Malaysia Sdn.Bhd.
Unit 1207, Block B, Menara Amcorp, Amcorp Trade Centre, No. 18, Jln Persiaran Barat, 46050 Petaling Jaya, Selangor Darul Ehsan, Malaysia
Tel: +60-3-7955-9390, Fax: +60-3-7955-9510
Renesas Electronics India Pvt. Ltd.
No.777C, 100 Feet Road, HAL II Stage, Indiranagar, Bangalore, India
Tel: +91-80-67208700, Fax: +91-80-67208777
Renesas Electronics Korea Co., Ltd.
12F., 234 Teheran-ro, Gangnam-Gu, Seoul, 135-080, Korea
Tel: +82-2-558-3737, Fax: +82-2-558-5141

© 2006-2017 Renesas  Electronics  Corporation.  All rights reserved.
Colophon  4.1

AUTOSAR Modules Overview

User’s Manual

R20UT3752EJ0101

Document Outline

Last modified October 12, 2025: Initial commit (af72ad2)