Renesas Mcal Support
Renesas Mcal Support
Component Documentation
1 - GettingStarted_MCAL_Drivers_X1x
AUTOSAR MCAL R3.2 and R4.0 User's Manual3 - GettingStarted_MCAL_Drivers_X1xs
Getting Started Document for
X1x MCAL Driver
User’s
Manual
Version 1.0.5
Target Device:
RH850/X1x
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). www.renesas.com Rev.0.01 Aug 2014
2
Notice
1.
All information included in this document is current as of the date this document is issued. Such information, however, is
subject to change without any prior notice. Before purchasing or using any Renesas Electronics products listed herein, please
confirm the latest product information with a Renesas Electronics sales office. Also, please pay regular and careful attention to
additional and different information to be disclosed by Renesas Electronics such as that disclosed through our website.
2.
Renesas Electronics does not assume any liability for infringement of 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.
No license, express, implied or otherwise, is granted hereby under any patents, copyrights or other intellectual property rights
of Renesas Electronics or others.
3.
You should not alter, modify, copy, or otherwise misappropriate any Renesas Electronics product, whether in whole or in part.
4.
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 of these circuits, software,
and information in the design of your equipment. Renesas Electronics assumes no responsibility for any losses incurred by
you or third parties arising from the use of these circuits, software, or information.
5.
When exporting the products or technology described in this document, you should comply with the applicable export control
laws and regulations and follow the procedures required by such laws and regulations. You should not use Renesas
Electronics products or the technology described in this document for any purpose relating to military applications or use by
the military, including but not limited to the development of weapons of mass destruction. Renesas Electronics products and
technology may 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.
6.
Renesas Electronics has used reasonable care in preparing the information included in this document, but Renesas Electronics
does not warrant that such information is error free. Renesas Electronics assumes no liability whatsoever for any damages
incurred by you resulting from errors in or omissions from the information included herein.
7.
Renesas Electronics products are classified according to the following three quality grades: "Standard", "High Quality", and
"Specific". The recommended applications for each Renesas Electronics product depends on the product's quality grade, as
indicated below. You must check the quality grade of each Renesas Electronics product before using it in a particular
application. You may not use any Renesas Electronics product for any application categorized as "Specific" without the prior
written consent of Renesas Electronics. Further, you may not use any Renesas Electronics product for any application for
which it is not intended without the prior written consent of Renesas Electronics. Renesas Electronics shall not be in any way
liable for any damages or losses incurred by you or third parties arising from the use of any Renesas Electronics product for an
application categorized as "Specific" or for which the product is not intended where you have failed to obtain the prior written
consent of Renesas Electronics. The quality grade of each Renesas Electronics product is "Standard" unless otherwise
expressly specified in a Renesas Electronics data sheets or data books, etc.
"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.
"High Quality": Transportation equipment (automobiles, trains, ships, etc.); traffic control systems; anti-disaster systems; anti-
crime systems; safety equipment; and medical equipment not specifically designed for life support.
"Specific":
Aircraft; aerospace equipment; submersible repeaters; nuclear reactor control systems; medical equipment or
systems for life support (e.g. artificial life support devices or systems), surgical implantations, or healthcare
intervention (e.g. excision, etc.), and any other applications or purposes that pose a direct threat to human life.
8.
You should use the Renesas Electronics products described in this document within the range specified by Renesas Electronics,
especially with respect to the maximum rating, operating supply voltage range, movement power voltage range, heat radiation
characteristics, installation and other product characteristics. Renesas Electronics shall have no liability for malfunctions or
damages arising out of the use of Renesas Electronics products beyond such specified ranges.
9.
Although Renesas Electronics endeavors to improve the quality and reliability of its 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 be sure to implement safety measures to
guard them against the possibility of physical injury, and injury or damage caused by fire in the event of the failure of a
Renesas Electronics product, 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. Because
the evaluation of microcomputer software alone is very difficult, please evaluate the safety of the final products or system
manufactured by you.
10.
Please contact a Renesas Electronics sales office for details as to environmental matters such as the environmental
compatibility of each Renesas Electronics product. Please use Renesas Electronics products in compliance with all applicable
laws and regulations that regulate the inclusion or use of controlled substances, including without limitation, the EU RoHS
Directive. Renesas Electronics assumes no liability for damages or losses occurring as a result of your noncompliance with
applicable laws and regulations.
11.
This document may not be 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, or if you have any other inquiries.
(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 3
4
Abbreviations and Acronyms Abbreviation / Acronym Description ARXML/arxml
AUTOSAR xml
AUTOSAR
Automotive Open System Architecture
BSWMDT
Basic Software Module Description Template
<MSN>
Module Short Name
ECU
Electronic Control Unit
GUI
Graphical User Interface
MB
Mega Bytes
MHz
Mega Hertz
RAM
Random Access Memory
xml/XML
eXtensible Markup Language
<MICRO_VARIANT>
F1x, R1x, P1x, E1x etc.
<MICRO_SUB_VARIANT>
F1L, R1L, P1L, E1L, E1MS etc.
AUTOSAR_VERSION
3.2.2 or 4.0.3
DEVICE_NAME
Example :701205EAFP
Definitions Terminology Description .xml
XML File.
.one
Project Settings file.
.arxml
AUTOSAR XML File.
.trxml
Translation XML File.
ECU Configuration
The ECU Configuration Parameter Definition is of type XML, which contains the
Parameter Definition File
definition for AUTOSAR software components i.e. definitions for Modules,
Containers and Parameters. The format of the XML File will be compliant with
AUTOSAR ECU specification standards.
ECU Configuration
The ECU Configuration Description file in XML format, which contains the
Description File
configured values for Parameters, Containers and Modules. ECU Configuration
Description XML File format will be compliant with the AUTOSAR ECU
specification standards.
BSWMDT File
The BSWMDT File in XML format, which is the template for the Basic Software
Module Description. BSWMDT File format will be compliant with the AUTOSAR
BSWMDT specification standards.
Translation XML File
Translation XML File is in XML format which contains translation and device
specific header file path.
Configuration XML File
Configuration XML File is in XML format which contains command line options
and options for input/output file path.
5
6
Table Of Contents
Chapter 1 Introduction ..................................................................... 11 Chapter 2 ECU Configuration Editor (ECU Spectrum) .................. 13 2.1. Installation Of ECU Configuration Editor (ECU Spectrum) ................................................ 13 2.2. ECU Spectrum Input and Output Files .................................................................................. 20 Chapter 3 Configuration Using ECU Configuration ....................... 21 Editor (ECU Spectrum) ....................................................................... 21 3.1. Creating New Project .............................................................................................................. 21 3.2. Configuration ........................................................................................................................... 22 3.2.1. Parameter Configuration ............................................................................................... 24
3.2.2. Distinguish Between Containers ................................................................................... 24
3.2.3. Save Project.................................................................................................................. 25
3.2.4. Validation ...................................................................................................................... 25 3.3. Generate ECU Configuration Description ............................................................................ 26 Chapter 4 Generation Tool ............................................................... 29 4.1. Translation XML File ................................................................................................................ 29 4.1.1. Translation Header File ................................................................................................ 30
4.1.2. Device Specific Header File .......................................................................................... 30 4.2. Configuration XML File ........................................................................................................... 30 4.3. Usage ........................................................................................................................................ 31 4.4. Sample Usage .......................................................................................................................... 32 4.5. Tool Installation Requirements .............................................................................................. 34 4.5.1. Hardware Requirements ............................................................................................... 34
4.5.2. Software Requirements ................................................................................................. 34
4.5.3. Limitations ..................................................................................................................... 34 4.6. Tool Installation ....................................................................................................................... 34 4.6.1. Pre Requisite ................................................................................................................ 35
4.6.2. Installation Steps .......................................................................................................... 35 4.7. Tool Un-Installation ................................................................................................................. 35 4.8. Common Messages ................................................................................................................ 35 4.8.1. Error Messages ............................................................................................................. 35
4.8.2. Warning Messages ....................................................................................................... 39
4.8.3. Information Messages .................................................................................................. 39 4.9. R3.2.2 Messages...................................................................................................................... 40 4.9.1. Error Messages ............................................................................................................ 40
4.9.2. Warning Messages ....................................................................................................... 40
4.9.3. Information Messages .................................................................................................. 40 4.10. R4.0.3 Messages...................................................................................................................... 40 4.10.1. Error Messages ............................................................................................................ 41
4.10.2. Warning Messages ....................................................................................................... 41
4.10.3. Information Messages .................................................................................................. 41 4.11. BSWMDT File ........................................................................................................................... 41 7
Chapter 5 Application Example ....................................................... 43 5.1. Folder Structure....................................................................................................................... 43 5.2. Makefile Description ............................................................................................................... 43 5.2.1. App_<Msn>_<variant>_Sample.mak ........................................................................... 43 5.3. Integrating The <MSN> Driver Component With Other Components .............................. 49 5.4. Building The <MSN> Driver Component .............................................................................. 50 5.4.1. Targets Supported By The Sample Base Makefile ....................................................... 51 Chapter 6 Support For Different Interrupt Categories ................... 53 Chapter 7 GNU MAKE Environment ................................................ 55 7.1. Build Process With GNUMAKE .............................................................................................. 55 7.2. Build Process Without GNUMAKE ........................................................................................ 55 Chapter 8 Load Binaries .................................................................. 59 Chapter 9 Appendix.......................................................................... 61 9.1. Translation XML File ................................................................................................................ 61 9.2. Configuration XML File ................................................................................................................. 61
8
List Of Figures Figure 2-1 Installation Initiation ........................................................................................................... 14 Figure 2-2 Splash Screen .................................................................................................................... 14 Figure 2-3 ECU Spectrum installation step 1....................................................................................... 15 Figure 2-4 ECU Spectrum installation step 2....................................................................................... 15 Figure 2-5 ECU Spectrum installation step 3 ...................................................................................... 16 Figure 2-6 ECU Spectrum installation step 4 ...................................................................................... 16 Figure 2-7 ECU Spectrum installation step 5....................................................................................... 17 Figure 2-8 ECU Spectrum installation step 6....................................................................................... 18 Figure 2-9 ECU Spectrum installation step 7....................................................................................... 18 Figure 2-10 ECU Spectrum installation step 8....................................................................................... 19 Figure 2-11 ECU Spectrum installation step 9....................................................................................... 19 Figure 2-12 ECU Spectrum Overview ................................................................................................... 20 Figure 3-1 Creating New Project ......................................................................................................... 22 Figure 3-2 Adding New Module Instance ............................................................................................ 23 Figure 3-3 GUI for Configuration ......................................................................................................... 23 Figure 3-4 Parameter Configuration .................................................................................................... 24 Figure 3-5 Distinguish Between Containers ........................................................................................ 25 Figure 3-6 Validation ........................................................................................................................... 26 Figure 3-7 Description File Generation ............................................................................................... 27 Figure 4-1 Generation Tool Overview ................................................................................................. 29 List Of Tables
Table 4-1 Options and Description .................................................................................................... 31 Table 4-2 Mandatory Parameters ...................................................................................................... 40 Table 4-3 Mandatory Parameters ...................................................................................................... 41 Table 6-1 CAT1 and CAT2 Naming Convention ................................................................................ 53 Table 6-2 List of ISR Names that need to be configured and published in Os.h ................................ 54 (CAT2) or used in the interrupt vector table (CAT1) for <MSN> Driver ...................................................... 54
9
10
Introduction Chapter 1 Chapter 1 Introduction The document describes the information about installation, usage of ECU
Configuration Editor (ECU Spectrum), Generation Tool and references to
Sections in the Component User Manuals that the user needs to refer to build
the executable.
ECU Spectrum is a tool that dynamically generates GUI controls for specified
AUTOSAR components according to ECU Configuration Parameter Definition
File and generates ECU Configuration Description file complying with
AUTOSAR standards.
Generation Tool is a command line tool that accepts ECU Configuration
Description File(s), BSWMDT File, Translation XML File and Configuration
XML File as input and generates the C source and header files based on the
configuration of the module.
11
Chapter 1 Introduction 12
ECU Configuration Editor (ECU Spectrum) Chapter 2 Chapter 2 ECU Configuration Editor (ECU Spectrum) 2.1. Installation Of ECU Configuration Editor (ECU Spectrum) The Following procedure is to be followed for proper installation of the
software:
Copy all the files from the installation disk to a separate folder on to the hard
disk of the computer on which the application is to be installed (recommended
but not mandatory). Initialize the ‘setup.exe’ file (This can also be done by
directly clicking on the same file in the installation disk).
An Install Shield application is invoked which guides the user throughout the
installation of the software.
The ECU Spectrum installation Disk1 consists of the following files:
•
data1.cab
•
data1.hdr
•
data2.cab
•
engine32.cab
•
layout.bin
•
setup.bmp
•
setup.exe
•
setup.ibt
•
setup.ini
•
setup.inx
•
setup.skin
The user is recommended to take backup of the installation disk before
proceeding with the actual installation. Due to certain reasons if the installation
procedure is aborted, the backup can be used.
The installation procedure is divided into ten steps. The details of all the steps
are given below.
13
Chapter 2 ECU Configuration Editor (ECU Spectrum) Step 1: Figure 2-1 Installation Initiation Run ‘setup.exe’ by double clicking on the setup.exe icon. This operation shows
the progress indication dialog as shown in the above Figure 2-1. After
displaying above Figure 2-1, for few minutes ECU Spectrum splash screen will
appear.
Figure 2-2 Splash Screen 14
ECU Configuration Editor (ECU Spectrum) Chapter 2 After displaying splash screen for few seconds following 'Preparing Setup'
dialog box appears (Refer Figure 2-3).
Figure 2-3 ECU Spectrum installation step 1 Step 2: Figure 2-4 ECU S pectrum installation step 2 After completion of the above operation, another dialog box is displayed (Refer
Figure 2-4) in order to get confirmation from the user to proceed with the
installation. The user can cancel the installation of software by selecting
‘Cancel’ button’. To proceed with the installation select ‘Next’ button.
15
Chapter 2 ECU Configuration Editor (ECU Spectrum) Step 3: Figure 2-5 ECU Spectrum installation step 3 On selecting ‘Next’ button in Step 2, a dialog box is invoked displaying the
license agreement. If the terms and conditions of the agreement are
acceptable then select ‘Yes’ button else select ‘No’ button to abort the
installation. The user can select ‘Back’ button in order to modify previously
made settings. (Refer Figure 2-5)
Step 4: Figure 2-6 ECU Spectrum installation step 4 16
ECU Configuration Editor (ECU Spectrum) Chapter 2 Step 5: ‘Customer Information’ dialog is displayed. Enter the User Name, Company
Name and Serial Number and click on ‘Next’ button to proceed for further
installation procedure. (Refer Figure 2-6)
Figure 2-7 ECU Spectrum installation step 5 Dialog box is displayed for user registration confirmation. Check the appeared
user registration information, if yes click on ‘Yes’ button. (Refer Figure 2-7). If
not click on ‘No’ and re-enter the user registration information.
Step 6: 17
Chapter 2 ECU Configuration Editor (ECU Spectrum) Figure 2-8 ECU Spectrum installation step 6 Next, a dialog box allowing the user to select the destination folder is
displayed (Refer Figure 2-8). The default directory for installation selected by
the Install shield is C:\Program Files\ECU Spectrum R3.0. However the user
can select the folder for installation of his/her choice using the ‘Browse’
button. The user can cancel the installation of software by selecting 'Cancel'
button and click on 'Next' button to proceed for further installation procedure.
Step 7: Figure 2-9 ECU Spectrum installation step 7 Next, a dialog box allowing the user to select the program folder is displayed.
By default, the name of the folder is ‘ECU Spectrum R3.0’ and the user is
allowed to change the folder name. (Refer Figure 2-9)
Select ‘Next’ button to continue the installation and ‘Cancel’ button to abort the
installation.
18
ECU Configuration Editor (ECU Spectrum) Chapter 2 Step 8: Figure 2-10 ECU Spectrum installation step 8 After selecting the appropriate folder for installation, the install wizard will
display a dialog box displaying the status of the files being copied. (Refer
Figure 2-10).
The user is allowed to abort the installation by pressing ‘Cancel’ button.
Step 9: Figure 2-11 ECU Spectrum installation step 9 After confirmation from the user for copying the files mentioned in Step 8, the
install wizard will automatically install the ECU Spectrum application, based on
19
Chapter 2 ECU Configuration Editor (ECU Spectrum) the selections made by the user. After completion of the installation procedure,
a dialog gets displayed to intimating the user about completion of the
installation process. (Refer Figure 2-11).
Step 10: Click on ‘Finish’ button to complete the installation process.
2.2. ECU Spectrum Input and Output Files ECU Spectrum takes ECU Configuration Parameter Definition File(s) as input.
It reads the definitions, provides a generic interface to edit values for all the
configuration parameters and generates the ECU Configuration Description
file(s) in XML format. It resolves relatively simple dependencies explicitly
defined in the ECU Configuration Parameter Definition file. On the Plug-In
side, the user can choose the Generation Tool executable for the individual
components that takes ECU Configuration Description File as input and
generates the required ‘C’ source and header files.
. ONE AUTOSAR X LM AUTOSAR XML ECU SPECTRUM
PROJECT SETTING
ECU
FILE
CONFIGURATION
PARAMETER
DEFINITION
AUTOSAR X LM AUTOSAR
XML GENERATION ECU
TOOLS DESCRIPTION
C FILE C FILE HEADER AND
SOURCE FILES Figure 2-12 ECU Spectrum Overview 20
Configuration Using ECU Configuration Editor (ECU Spectrum) Chapter 3 Chapter 3 Configuration Using ECU Configuration Editor (ECU Spectrum) This section gives details about procedure for creating a new project,
configuring the parameters, saving a project, validating the current GUI
configuration and generating ECU Configuration Description file of ECU
Spectrum.
3.1. Creating New Project Creating a ‘New Project’ loads the modules from specified ECU Configuration
Parameter Definition File into the Software. New Project is created using “File -
> New Project” from the main menu.
Steps to be followed:
1. Select “File -> New Project”.
2. Select the AUTOSAR Version. Default AUTOSAR version is 4.0.x.
3. Browse a valid Project Settings file name (of type ‘.one’).
4. Browse a valid ECU Configuration Parameter Definition File name (of type
‘*.xml /*.arxml’).
5. Click on ‘OK’ button.
6. Follow step 4 to load more than one definition file.
The modules available in the selected files get loaded into the software and it
is saved in the specified Project Settings file location. Specified Project
Settings File name is displayed on the title bar of the ECU Spectrum along with
the respective AUTOSAR version.
21
Chapter 3 Configuration Using ECU Configuration Editor (ECU Spectrum) Figure 3-1 Creating New Project The modules available in the selected files get loaded into the Software and it
is saved in the specified Project Settings location. Specified Project Settings
file name is displayed on the Title bar of the Software.
3.2. Configuration Right click on the module in the 'Left Selection View', a popup menu having
'New Module’ option is displayed. On selecting this option, the instance of the
module is created. The ECU Spectrum will assign a short name to the newly
created module automatically. On selecting the newly created module, controls
are displayed in the 'Right Configuration View' for configuration. Edit the data
and validate the current GUI configuration. Errors/Warnings/Messages is
displayed in the ‘Message Info’ window, if any.
The user can configure any number of modules, containers, parameters, and
references depending on the Multiplicity specified in the ECU Configuration
Parameter Definition File.
Right clicking on the instance of the module in 'Left Selection View', a popup
menu having ‘Insert Copy’ ,‘Delete’ ,’Expand’ and ’Collapse’ option is
displayed. Using ’Insert Copy’, the copy of selected element with configured
values is inserted. ‘Insert Copy’ option is displayed in the pop up menu based
on the multiplicity. Using ‘Delete’, user can delete the selected element.
‘Expand’ is used to expand the selected element and ‘Collapse’ is used to
collapse the selected element.
Existing Project Settings can be configured in following ways:
1. Right Click on the module and add an instance of the module.
22
Configuration Using ECU Configuration Editor (ECU Spectrum) Chapter 3 Figure 3-2 Adding New Module Instance 2.Click on the instance of the module, user will find a grid on right view for
configuration.
Figure 3-3 GUI for Configuration 23
Chapter 3 Configuration Using ECU Configuration Editor (ECU Spectrum) 3.2.1. Parameter Configuration Short Name, Definition Type, Lower multiplicity, Upper multiplicity, Minimum
value, Maximum value, Implementation config class, Implementation config
variant, Default value and Long Name are displayed in ‘Attributes’ grid and
Description of the parameter is displayed in the ’Description’ display area on
click of the parameter in the ‘Right Configuration View’ as shown in the
following figure. Configure the parameter and press ‘ENTER’ button. Following
are the types of the parameters:
Figure 3-4 Parameter Configuration 3.2.2. Distinguish Between Containers On selecting the newly created module in the ‘Left Selection View’, controls are
displayed in the 'Right Configuration View' for configuration. Name of the
containers gets displayed at the top of the ‘Right Configuration View’ as shown
in the following figure. On selecting the container, Parameters and sub-
containers gets displayed in the grid control as shown in the following figure.
24
Configuration Using ECU Configuration Editor (ECU Spectrum) Chapter 3 Figure 3-5 Distinguish Between Containers 3.2.3. Save Project Using “File-> Save Project” menu item, current GUI configuration can be saved
with specified Project Settings file name.
3.2.4. Validation The modules configuration can be checked for correctness and completeness
in validation. Before generation of ECU Configuration Description, validate the
configured values of the modules. Select “Project -> Validate” or press ‘F8’ key,
25
Chapter 3 Configuration Using ECU Configuration Editor (ECU Spectrum) a current GUI configuration is validated and list of Errors/Warnings/Messages
is displayed in the ‘Message Info’ window, if any.
Figure 3-6 Validation 3.3. Generate ECU Configuration Description This generates the ECU Configuration Description File, which contains the
configured values for Parameters, Containers and Modules. The generated
ECU Configuration Description File format will be compliant with the
AUTOSAR ECU specification standards. After validation of the configured
values, to generate the ECU Configuration Description follow the below steps:
1. Select “Generate -> ECU Configuration Description”.
2. Check the ‘Select all’ Check box.
3. Specify the ECU Configuration Description File name (of type '*.xml/
*.arxml’).
4. Click ‘Generate’ button
26
Configuration Using ECU Configuration Editor (ECU Spectrum) Chapter 3 Figure 3-7 Description File Generation Successful generation message is displayed in the ‘Result’ display area. The
ECU Configuration Description data for all modules is generated at the
specified location.
27
Chapter 3 Configuration Using ECU Configuration Editor (ECU Spectrum) 28
Generation Tool Chapter 4 Chapter 4 Generation Tool Generation Tool is a command line tool that provides scalability and
configurability for the component. It accepts ECU Configuration Description
File(s), BSWMDT File, Translation XML File and Configuration XML File as
input and generates the C Header and C Source files. However Configuration
XML File is optional.
ECU Configuration
Output Folder -O or
Description Fil e(s )
-OUTPU T
(.arxml), BSWMDT
Generation Tool ‘Folder_Name’
File and Translation
XML Fi le (.trxml)
Label to be searched
inc
src
Configuration XML
Translation Header
File (.cfgxml)
File (.h)
*.h
*.c
Mapped Label to be searched
Address to be generated
Device Specific
Header File (.h)
Figure 4-1 Generation Tool Overview 4.1. Translation XML File Generation Tool accepts ECU Configuration Description File(s) (.arxml),
BSWMDT File (.arxml) and Translation XML File (.trxml) as an input.
Translation XML File is in XML format which contains translation and device
specific header file path. For the syntax of the contents of Translation XML
File, please refer the Chapter 8
Appendix.
If mapped device specific address label is changed/updated then only
respective mapping in Translation Header File needs to be updated. In this
case there will not be any impact on Generation Tool for the generation of
address in tool generated output file(s).
29
Chapter 4 Generation Tool 4.1.1. Translation Header File This file is look-up table (mapping in the form of definitions) for the device
specific address labels. Based on the configuration in ECU Configuration
Description File, the mapped device specific address labels will be searched
in Device Specific Header File by Generation Tool to generate associated
address in tool generated output file(s). For the Translation Header File path,
the value of ‘<Msn>DeviceName’ parameter from the container
‘<Msn>General’ container should be present as child tag of TRANSLATION-
FILE-PATH in Translation XML File. Both ‘Absolute’ and ‘Relative’ paths are
supported by generation tool however default path is ‘Relative’ path.
E.g.
<TRANSLATION-FILE-PATH>
<Value_Of_MsnDeviceName>..\DF_Timer.h
..\DF_Timer_ISR.h</ Value_Of_MsnDeviceName>
</TRANSLATION-FILE-PATH>
4.1.2. Device Specific Header File This file contains device specific labels and associated address. Based on the
configuration in ECU Configuration Description File, the mapped device
specific address labels will be used to generate associated address in tool
generated output file(s). For the Device Specific Header File path, the value of
‘<Msn>DeviceName’ parameter from the container ‘<Msn>General’ container
should be present as child tag of DEVICE-FILE-PATH in Translation XML File.
Both ‘Absolute’ and ‘Relative’ paths are supported by generation tool however
default path is ‘Relative’ path.
If multiple Device Specific Header Files need to be provided for the same
device (value of ‘<Msn>DeviceName’ parameter) in Translation XML File, then
each Device Specific Header File path should be separated with ‘space’.
E.g.
<DEVICE-FILE-PATH>
<Value_Of_MsnDeviceName>..\DF_Timer.h ..\DF_Timer_ISR.h</
Value_Of_MsnDeviceName>
</DEVICE-FILE-PATH>
Remark Generation Tool will searches the mapped labels in Device Specific Header
File by using Translation Header File for the respective address generation in
tool generated output file(s).
4.2. Configuration XML File Configuration XML File is in XML format which contains command line options
and input/output path. For the syntax of the contents of Configuration XML File,
please refer the Chapter 8
Appendix.
30
Generation Tool Chapter 4 E.g.
<LOG>ON/OFF</LOG>
<HELP>ON/OFF</HELP>
4.3. Usage This section provides the information regarding usage of the Generation Tool.
It also provides the syntax of the command line arguments (input filenames
and options).
Generation Tool executable is invoked as shown below.
{<Component_Name>_X1x.exe} <Options> <Input Filename(s)> Where,
<Component_Name>_X1x.exe: Name of the Generation Tool Executable
Options: [-H/-Help -C/-Config -O/-Output -Osrc -Oinc -L/-Log -D/-Dryrun]
Input Filename(s): {ECU Configuration Description File(s), BSWMDT File and
Translation XML File [optional]}
Notations: {data} represents compulsory data
<data> represents the actual data that will be specified on command line
during tool usage.
[data] represents optional data.
Table 4-1 Options and Description Option Description -H/-Help
To display help regarding usage of the tool. Gets the
highest priority when used with other options.
-C/-Config
To execute tool with the options provided in the
Configuration XML File. Command line options get the
higher priority than the options provided in Configuration
XML File.
31
Chapter 4 Generation Tool Table 4-1 Options and Description Option Description -O/-Output
By default, the tool generates output files in the
‘<Component_Name>_Output’ folder in the path where
executable is present. The user can use the -O option
followed by the folder name, to generate the output files in
the specified folder. Either absolute path or relative path
can be provided to specify the folder name.
The C Source and C Header files are generated in the sub
folders ‘src’ and ‘inc’ within the output folder.
-Osrc
The user can use the -Osrc option followed by the folder
name, to generate the C Source files in the specified
folder.
-Oinc
The user can use the -Oinc option followed by the folder
name, to generate the C Header files in the specified
folder.
–L/-Log
To log the output to the <Component_Name>.log file.
-D/-Dryrun
To execute tool in validation mode. The tool will not
generate output files even though the input file provided is
error free.
Remark • If Translation XML File is not provided on the command line then
‘<Component_Name>_X1x.trxml’ which is present in the same location of
‘<Component_Name>_X1x.exe’ is considered as ‘default’ Translation XML
File by the Generation Tool.
• If Configuration XML File is not provided on the command line then
‘<Component_Name>_X1x.cfgxml’ which is present in the same location of
‘<Component_Name>_X1x.exe’ is considered as ‘default’ Configuration
XML File by the Generation Tool.
• The Generation Tool should not be executed more than five times in parallel
4.4. Sample Usage Sample usage of the generation tool is given below. “<Msn>_X1x.exe” is taken
as example. Similar usage is applicable for other MCAL Generation Tools.
<Msn>_X1x <Msn> Driver Generation Tool usage is displayed on the terminal. Generation
Tool accepts Configuration XML File as default and performs the execution,
based on the settings provided in Configuration XML File.
<Msn>_X1x -H Displays <MSN> Driver Generation Tool help information on the terminal,
where <MSN> Driver Generation Tool executable is present.
<Msn>_X1x -L -O output Sample.arxml BSWMDT.arxml Generation Tool logs the output to the <Msn>.log file. <Msn>_PBcfg.c file is
generated in ‘src’ folder. <Msn>_Cfg.h file is generated in ‘include’ folder.
32
Generation Tool Chapter 4 <Msn>_X1x -D Sample.arxml BswMd.arxml Generation Tool validates an input file and displays error/warning/information
messages if any on the command line. Output files are not generated since –D
option is provided in the command line.
<Msn>_X1x -O output Sample.arxml BswMd.arxml Output files are generated in folder “output”. <Msn>_PBcfg.c is generated in
‘src’ folder. <Msn>_Cfg.h file is generated in ‘inc’ folder.
<Msn>_X1x C:\Input\Sample.arxml C:\Input\BswMd.arxml -O output Generation Tool accepts input file (Sample.arxml) from absolute directory path
“C:\Input”. Output files are generated in folder “output”. <Msn>_PBcfg.c is
generated in ‘src’ folder. <Msn>_Cfg.h file is generated in ‘inc’ folder.
<Msn>_X1x Sample.arxml BswMd.arxml -O C:\Output Output files are generated in folder “C:\Output”. <Msn>_PBcfg.c is generated
in ‘src’ folder. <Msn>_Cfg.h file is generated in ‘inc’ folder.
<Msn>_X1x Sample.arxml BswMd.arxml Sample.trxml Generation Tool accepts ECU Configuration Description File (Sample.arxml),
BSWMDT File (BswMd.arxml) and Translation XML File (Sample.trxml) from
the current working directory. Output files are generated in the default folder
“<Msn>_Output”, since –O option is not provided in the command line.
<Msn>_PBcfg.c is generated in ‘src’ folder. <Msn>_Cfg.h file is generated in
‘inc’ folder.
<Msn>_X1x -C Sample.cfgxml Generation Tool accepts ECU Configuration Description File (Sample.arxml),
BSWMDT File (BswMd.arxml) and Configuration XML File (Sample.cfgxml)
from the current working directory. Tool accepts options provided in the
Configuration XML File. If Configuration XML File name is not provided as
input with -C option, Generation Tool errors out.
Remark • If Translation XML File is not provided on the command line,
<Msn>_X1x.exe considers <Msn>_X1x.trxml as ‘default’ Translation
XML File from the same directory where the tool is located.
• If Configuration XML File is not provided on the command line,
<Msn>_X1x.exe considers <Msn>_X1x.cfgxml as ‘default’ Configuration
XML File from the same directory where the tool is located.
• If any filename/directory name related argument on the command line
contain the ‘space’, then the same argument on the command line should
be provided in double quotes “” as followed by standard command line
feature. E.g. if file name is ‘Sample Description.arxml’, then on the
command line the same name should be provided in double quotes “” as
“Sample Description.arxml”.
• The ‘include’ and ‘src’ directories are generated inside the output directory
provided on the command line or in the default output directory
33
Chapter 4 Generation Tool <Msn>_Output.\
• BSWMDT file should not be updated manually since it is “Static
Configuration” file.
4.5. Tool Installation Requirements The minimum hardware and software requirements for proper installation of
Module Specific Generation Tool are listed below. This ensures optimal
performance of the Tool.
4.5.1. Hardware Requirements Processor Pentium/equivalent processor @ 500 MHz or greater
Memory RAM 64MB or greater
Hard Disk Drive 500 MB or greater storage capacity
4.5.2. Software Requirements Operating System Microsoft Windows Platform
4.5.3. Limitations Command Line characters are limited to 128 depending upon the operating
system.
4.6. Tool Installation The installation procedure of Module Specific Generation Tool is provided in
the section below.
34
Generation Tool Chapter 4 4.6.1. Pre Requisite Module Specific Generation Tool executable runs on Windows platforms only.
4.6.2. Installation Steps Copy the Module Specific Generation Tool executable file to the local hard
disk.
Run the executable with -H option to get help on usage of the tool.
<Msn>_X1x.exe -H
This command generates usage of Module Specific Driver Generation Tool on
the command line.
4.7. Tool Un-Installation There is no specific method for un-installing the Module specific Generation
Tool. To un-install, delete the Module specific Generation Tool executable from
the existing directory.
4.8. Common Messages This section contains the list of error/warning/information messages
which is common for AUTOSAR Renesas R3.2.2 and R4.0.3 X1x MCAL Driver
module that will be generated by the Generation Tool.
4.8.1. Error Messages ERR000001: File <File_Name> does not exist. This error occurs, if the input <File_Name> is not found.
ERR000002: Name of the Generation Tool Configuration XML File is not
given along with <-C/-CONFIG> option. This error occurs, if the name of the Generation Tool Configuration XML File is
not given along with <-C/-CONFIG> option.
35
Chapter 4 Generation Tool ERR000003: File <File name> is not as per XML standard. This error will occur, if the input <File name> is not as per XML standard.
ERR000004: Cannot open the <Log file name> file. This error will occur, if unable to open the <Log file name> file.
ERR000005: Name of output directory is not given along with <-O/-
OUTPUT> option. This error will occur, if the output directory name is not given along with <-O/-
OUTPUT> option.
ERR000006: Name of output directory is not given in OUTPUT-PATH tag
in <File name>. This error will occur, if the output directory is not given in OUTPUT-PATH tag in
configuration file.
ERR000007: The Generation Tool expects inputs. This error will occur, if the no option is provided in the command line and none
of the option in the configuration file is set.
ERR000008: The option <option> is not supported by the Generation Tool. The Generation Tool supports <-O/-OUTPUT, -Osrc , -Oinc, -H/-HELP, -
L/-LOG, -C/-CONFIGFILE and -D/-DRYRUN>" options. This error will occur, if the invalid <option> is provided to the tool.
ERR000009: Invalid output directory name <output directory name> as
the file with same name exists. This error will occur, if the <output directory name> already exists.
ERR000010: Invalid output directory name <output directory name>
Directory name should not contain any of \*\?\"\|\: characters. This error will occur, if the <output directory name> path contains junk
character.
ERR000011: ECU Configuration Description File is not provided as input
to the Generation Tool. This error will occur, if the ECU Configuration Description File is not given in
the command line or in configuration file.
ERR000012: The input <File name> is not as per XML standard. Provide
the ECU Configuration Description File as input on the command line. This error will occur, if the ECU Configuration Description File is not as per
XML standard.
36
Generation Tool Chapter 4 ERR000013: <File name> should contain the TRANSLATION-FILE-PATH'
and 'DEVICE-FILE-PATH' tags. This error will occur, if the translation <File name> doesn’t have
‘TRANSLATION-FILE-PATH’ and 'DEVICE-FILE-PATH' tags.
ERR000014: 'TRANSLATION-FILE-PATH' tag in <File name> is empty. This error will occur, if the translation <File name> doesn’t have
‘TRANSLATION-FILE-PATH’ tags.
ERR000015: The 'device_name' tag should be present as child of 'TRANSLATION-FILE-PATH'' tag in <File name>. This error will occur, if the device mentioned in ECU Configuration Description
File is not present in
'TRANSLATION-FILE-PATH’ tag in the <File name>.
ERR000016: ‘DEVICE-FILE-PATH’ tag in <File name> is empty. This error will occur, if the translation file <File name> doesn’t have ‘DEVICE-
FILE-PATH’ tags.
ERR000017: The 'device_name’ tag should be present as child of ‘DEVICE-FILE-PATH' tag in <File name>. This error will occur, if the device mentioned in ECU Configuration Description
File is not present in
‘DEVICE-FILE-PATH’ tag.
ERR000018: Cannot create directory <output directory name>. This error will occur, if unable to create output directory <output directory
name>.
ERR000019: Cannot open <File name>. This error will occur, if unable to open <File name>.
ERR000020: The macro label <macro label> should be unique in
<translation file name> translation C Header File. This error will occur, if macro label is not unique in translation C Header File.
ERR000021: The macro definition for <macro label> macro is not found
in <translation file name> translation C Header File. The macro label
format should be <label format>. This error will occur, if macro definition is not found in translation C Header
File.
37
Chapter 4 Generation Tool
ERR000022: The macro value for <macro label> macro is empty in <translation file name> translation C Header File. This error will occur, if macro label value is empty in translation C Header File.
ERR000023: The macro definition for <macro value> macro is not found
in input device specific C Header File(s). This error will occur, if macro definition is not found in input device specific C
Header File(s).
ERR000024: The macro value for <macro value> macro is empty in input
device specific C Header File(s). This error will occur, if macro value is empty in input device specific C Header
File(s).
ERR000025: Path <Configured Reference Path> provided for Bsw Module
is incorrect. This error will occur, if the reference provided for Bsw Module Component is
incorrect.
ERR000026: BSWMDT content is not present in the input file(s) for ‘<Module Name>’ module. This error will occur, if the module specific BSWMDT content is not present in
the input files.
ERR000027: <MSN> BSWMDT File of either AUTOSAR R3.2 or R4.0
should be given as input. This error will occur, if the both R3.2 and R4.0 BSWMDT file given to the input
to the generation tool.
ERR000028: 'MODULE-DESCRIPTION-REF' element should be present in
the description file of '<Module Name>' module. This error will occur, if the MODULE-DESCRIPTION-REF element is not
present module specific description file.
ERR000029: AUTOSAR version of BSWMDT File and Module Description File is different. This error will occur, if the AUTOSAR version of the BSWMDT File and module
description file is different.
38
Generation Tool Chapter 4 4.8.2. Warning Messages
WRN000001: As per AUTOSAR ECU Configuration Description File
naming convention, the file extension should be '.arxml' for file. This warning will occur, if ECU Configuration Description file having an
extension other than ’.arxml’.
4.8.3. Information Messages INF000001: Tool Version: This is to display Tool Version for each execution of the tool.
INF000002: Command line arguments: This is to display the command line arguments for each execution of the tool.
INF000003: The valid inputs are provided below. This information will occur, if the command line option is not given.
INF000004: Opened file <filename> at <time>. This information will occur, during opening the file.
INF000005: Error(s) and Warning(s) detected. This information will display the number of errors and warnings.
INF000006: Execution completed successfully. This information will occur, if the execution completed successfully.
INF000007: Execution completed successfully with warnings. This information will occur, if the execution completed successfully with
warnings.
I
NF000008: Execution terminated due to command line errors. This information will occur, if the execution terminated due to command line
errors.
INF000009: Execution terminated due to error in the input file. This information will occur, if the execution terminated due to error in the input
file.
INF000010: Execution terminated due to error, during the structure
generation in the output file. This information will occur, if the execution terminated during structure
generation in output file.
39
Chapter 4 Generation Tool 4.9. R3.2.2 Messages This section contains the list of error/warning/information messages which is
specific to AUTOSAR Renesas R3.2.2 X1x MCAL Driver module that will be
generated by the Generation Tool.
4.9.1. Error Messages ERR000030: The 'parameter tag name' tag should be configured in BSWMDT File. This error will occur, if any of the configuration parameter(s) mentioned below
is (are) not configured in BSWMDT File.
The list of mandatory parameters with respect to container is listed below:
Table 4-2 Mandatory Parameters Container Parameters BswImplementation
SW-MAJOR-VERSION
SW-MINOR-VERSION
SW-PATCH-VERSION
AR-MAJOR-VERSION
AR-MINOR-VERSION
AR-PATCH-VERSION
VendorApiInfix
BswModuleDescription
ModuleId
Note: VendorApiInfix parameter is mandatory for only some modules. 4.9.2. Warning Messages None.
4.9.3. Information Messages None.
4.10. R4.0.3 Messages This section contains the list of error/warning/information messages which is
specific to AUTOSAR Renesas R4.0.3 X1x MCAL Driver module that will be
generated by the Generation Tool.
40
Generation Tool Chapter 4 4.10.1. Error Messages ERR000030: The 'parameter tag name' tag should be configured in BSWMDT File. This error will occur, if any of the configuration parameter(s) mentioned below
is (are) not configured in BSWMDT File.
The list of mandatory parameters with respect to container is listed below:
Table 4-3 Mandatory Parameters Container Parameters BswImplementation
SwVersion
VendorId
ArReleaseVersion
VendorApiInfix
BswModuleDescription
ModuleId
Note: VendorApiInfix parameter is mandatory for only some modules. 4.10.2. Warning Messages None.
4.10.3. Information Messages None.
4.11. BSWMDT File The BSWMDT File is the template for the Basic Software Module Description.
Module specific Generation Tool uses “Common Published Information” from
module specific BSWMDT file. BSWMDT file should not be updated manually
since it is “Static Configuration” file.
The required elements from BSWMDT File by module specific Generation
Tool are as follows:
BSW-MODULE-DESCRIPTION
•
MODULE-ID
41
Chapter 4 Generation Tool BSW-IMPLEMENTATION
•
SW-VERSION
•
•
VENDOR-ID
•
AR-RELEASE-VERSION
•
VENDOR-API-INFIX
In case of multiple driver support implementation, VENDOR-API-INFIX is
mandatory. In case of single driver support implementation, VENDOR-
API- INFIX is not used.
42
Application Example Chapter 5 Chapter 5 Application Example 5.1. Folder Structure Refer Section “Integration and Build Process” in the respective component
User Manuals.
5.2. Makefile Description Makefile is available in the folder “X1X\< MICRO_VARIANT
>\modules\<msn>\sample_application\< MICRO_SUB_VARIANT
>\make\<compiler>”.
The Makefiles with the guidelines provided in AUTOSAR BSW Makefile
Interface Specification, which enables easy integration with other components
and the application.
The files is:
• A p p _<Msn>_<MICRO_SUB_VARIANT>_<DEVICE_NAME>Sample.mak
(Contains the device specific instructions).
5.2.1. App_<Msn>_<variant>_Sample.mak ##############################################################
# Makefile to compile and build the Sample application with the AUTOSAR
<MSN> #
# Driver Component (For Test purposes only)
#
# Compatible with GNU Make 3.81 for Win32. #
##############################################################
##############################################################
# Definitions of global environment variables
#
##############################################################
#Get name of the current application
CURRENT_APPL = App_<Msn>
# Get the project directory into variable "PROJECT_ROOT"
43
Chapter 5 Application Example
PROJECT_ROOT = $(shell cd)\..\..\..\..\..\..
COMMON_SAMPLE_CORE_PATH =
$(PROJECT_ROOT)\$(MICRO_FAMILY)\common_platform
\modules\<Msn>\sample_application
# Get the current working directory into variable "SAMPLE_ROOT_PATH"
SAMPLE_ROOT_PATH =
$(PROJECT_ROOT)\$(MICRO_FAMILY)\$(MICRO_VARIANT)\modules
<Msn>\sample_application\$(MICRO_SUB_VARIANT)
# Get the current working directory into variable "STUBS"
STUBS_PATH =
$(PROJECT_ROOT)\$(MICRO_FAMILY)
\common_platform\generic
\stubs\$(AUTOSAR_VERSION)
# Get current configuration path
<MSN>_CONFIG_PATH =
$(SAMPLE_ROOT_PATH)\$(AUTOSAR_VERSION)
# Get TRXML path
TRXML_CONFIG_PATH = $(PROJECT_ROOT)
\$(MICRO_FAMILY)\$(MICRO_VARIANT)
\common_family\generator
# Get BSWMDT path
<MSN>_BSWMDT_CONFIG_PATH = $(PROJECT_ROOT)
\$(MICRO_FAMILY)
\$(MICRO_VARIANT)
\modules\<Msn>
\generator
# Get current configuration file path
<MSN>_CONFIG_FILE = $(MSN_CONFIG_PATH) \config
\App_<MSN>_$(MICRO_SUB_VARIANT)_
$(DEVICE_NAME)_Sample.arxml
# Path to TRXML Configuration File which is required for this module
TRXML_CONFIG_FILE =
"$(TRXML_CONFIG_PATH)\Sample_Application_$(MICRO
_VARIANT).trxml""
# Path to ECUM Configuration File which is required for this module
ECUM_CONFIG_PATH = $(STUBS_PATH)\EcuM
ifeq ($(AUTOSAR_VERSION), 3.2.2)
ECUM_CONFIG_FILE = "$(ECUM_CONFIG_PATH)\xml\EcuM.arxml"
else
44
Application Example Chapter 5 ECUM_CONFIG_FILE = "$(ECUM_CONFIG_PATH)\xml\EcuM_Icu.arxml"
endif
# Path to TRXML Configuration File which is required for Test Application
TRXML_CONFIG_FILE =
"$(TRXML_CONFIG_PATH)\Sample_Application_$(MICRO_VARIANT).trxml"
# Path to BSWMDT Configuration File which is required for MSN Sample
Application
ifeq ($(AUTOSAR_VERSION), 3.2.2)
MSN_BSWMDT_CONFIG_FILE =
"$(MSN_BSWMDT_CONFIG_PATH)\R322_$(MODULE_NAME)_$(MICRO_V
ARIANT)_BSWMDT.arxml"
else
ICU_BSWMDT_CONFIG_FILE =
"$(MSN_BSWMDT_CONFIG_PATH)\R403_$(MODULE_NAME)_$(MICRO_V
ARIANT)_BSWMDT.arxml"
endif
# Version check for inter modules required
MSN_VERSION_CHECK_REQ = yes
# Database to be linked together with the current application
# Define 'no' to isolate database from the application
<MSN>_DBASE_REQ = yes
# Get the name of the SRECORD file
CURRENT_APPL_SRECORD =
$(CURRENT_APPL)_$(MICRO_SUB_VARIANT)_Sample
# Name of the database if generated separately
<MSN>_DB = <Msn>_PBcfg
##############################################################
# Final executable
#
##############################################################
EXE = $(CURRENT_APPL)_ MICRO_
<SUB_VARIANT>_Sample.$(EXE_FILE_SUFFIX)
LIBRARIES_TO_BUILD =
OBJECTS_LINK_ONLY =
OBJECT_OUTPUT_PATH = $(SAMPLE_ROOT_PATH)\obj\ghs
GENERATED_SOURCE_FILES =
CC_FILES_TO_BUILD =
45
Chapter 5 Application Example
CPP_FILES_TO_BUILD =
ASM_FILES_TO_BUILD =
CC_INCLUDE_PATH =
CPP_INCLUDE_PATH =
ASM_INCLUDE_PATH =
PREPROCESSOR_DEFINES =
LIBRARIES_LINK_ONLY =
DIRECTORIES_TO_CREATE =
DEPEND_GCC_OPTS =
MAKE_CLEAN_RULES =
MAKE_GENERATE_RULES =
MAKE_COMPILE_RULES =
MAKE_DEBUG_RULES =
MAKE_CONFIG_RULES =
MAKE_ADD_RULES =
MAKE_DEBUG_RULES =
MAKE_ CONFIG_RULES =
MAKE_ADD_RULES =
MAKE_DEBUG_RULES += debug_base_make
STD_LIBRARY =
LNKFILE =
$(PROJECT_ROOT)\$(MICRO_FAMILY)\$(MICRO_VARIANT)\modules\<msn
>\sample_application\$(MICRO_SUB_VARIANT)\make\ghs\$(CURRENT_APP
L)_$(MICRO_SUB_VARIANT)_$(DEVICE_NAME)_Sample.ld
LNKFILE_DB =
$(PROJECT_ROOT)\$(MICRO_FAMILY)\$(MICRO_VARIANT)\modules\<ms
n>\sample_application\$(MICRO_SUB_VARIANT)\make\ghs\$(CURRENT_A
PPL)_$(MICRO_SUB_VARIANT)_$(DEVICE_NAME)_Sample_db.ld
.PHONY: MAKE_CLEAN_RULES MAKE_GENERATE_RULES
MAKE_COMPILE_RULES \
MAKE_DEBUG_RULES MAKE_CONFIG_RULES MAKE_ADD_RULES
##############################################################
# Modules to be included in the project
#
##############################################################
46
Application Example Chapter 5 ##############################################################
# Sample Application
#
include
$(COMMON_SAMPLE_CORE_PATH)\make\$(CURRENT_APPL)_Common_S
ample_Defs.mak
include
$(COMMON_SAMPLE_CORE_PATH)\make\$(CURRENT_APPL)_Common_S
ample_rules.mak
SAMPLE_CORE_PATH = $(SAMPLE_ROOT_PATH)
include
$(SAMPLE_CORE_PATH)\make\$(CURRENT_APPL
_$(MICRO_SUB_VARIANT)_Sample_defs.mak
include
$(SAMPLE_CORE_PATH)\make\$(CURRENT_APPL
_$(MICRO_SUB_VARIANT)_Sample_rules.mak
##############################################################
##############################################################
##############################################################
# DET Module Core Path
#
#DET_CORE_PATH = $(STUBS_PATH)\Det
#include $(DET_CORE_PATH)\make\det_defs.mak
#include $(DET_CORE_PATH)\make\det_rules.mak
##############################################################
##############################################################
# OS Module Core Path
#
OS_CORE_PATH = $(STUBS_PATH)\os
include $(OS_CORE_PATH)\make\os_defs.mak
include $(OS_CORE_PATH)\make\ os_rules.mak
#############################################################
##############################################################
# ECUM Module Core Path
#
ECUM_CORE_PATH = $(STUBS_PATH)\EcuM
include $(ECUM_CORE_PATH)\make\ecum_defs.mak
include $(ECUM_CORE_PATH)\make\ecum_rules.mak
##############################################################
##############################################################
47
Chapter 5 Application Example
# Scheduler Manager Module Core Path
#
ifeq ($(AUTOSAR_VERSION), 3.2.2)
SCHM_CORE_PATH = $(STUBS_PATH)\SchM
include $(SCHM_CORE_PATH)\make\schm_defs.mak
else
RTE_CORE_PATH = $(STUBS_PATH)\SchM
include $(RTE_CORE_PATH)\make\rte_defs.mak
endif
#############################################################
# <MSN> Driver Component
#
<MSN>_CORE_PATH =
$(PROJECT_ROOT \$(MICRO_FAMILY)\ common_platform
\modules\<msn>
include $(<MSN>_CORE_PATH)\make\renesas_<msn>_defs.mak
include $(<MSN>_CORE_PATH)\make\renesas _<msn>_check.mak
include $(<MSN>_CORE_PATH)\make\renesas_<msn>_rules.mak
#############################################################
##############################################################
# Command to generate standalone database
#
$(MSN_DB).$(S_RECORD_SUFFIX):$(MSN_DB).$(OBJ_FILE_SUFFIX)
$(LNKFILE_DB)
@echo *********************************************************************
@echo Building the standalone database ...
$(DBLINKER) $(LNKFILE_DB) \
"$(OBJECT_OUTPUT_PATH)\$(ICU_DB).$(OBJ_FILE_SUFFIX)" \
-map="$(OBJECT_OUTPUT_PATH)\$(ICU_DB).$(MAP_FILE_SUFFIX)" \
-o "$(OBJECT_OUTPUT_PATH)\$(MSN_DB).$(EXE_FILE_SUFFIX)"
@echo Generating Motorola S-Record file...
$(CONVERTER) $(SFLAGS)
"$(OBJECT_OUTPUT_PATH)\$(ICU_DB).$(EXE_FILE_SUFFIX)" \
-o "$(OBJECT_OUTPUT_PATH)\$(ICU_DB).$(S_RECORD_SUFFIX)"
@echo Done ...
##############################################################
##################
$(<MSN>_DB).$(S_RECORD_SUFFIX):$(<MSN>_DB).$(OBJ_FILE_SUFFIX
) $(LNKFILE_DB)
@echo *********************************************************************
@echo Building the standalone database ...
$(DBLINKER) $(LNKFILE_DB) \
"$(OBJECT_OUTPUT_PATH)\$(<MSN>_DB).$(OBJ_FILE_SUFFIX)" \
-map="$(OBJECT_OUTPUT_PATH)\$(<MSN>_DB).$(MAP_FILE_SUFFIX)" \
48
Application Example Chapter 5 -o "$(OBJECT_OUTPUT_PATH)\$(<MSN>_DB).$(EXE_FILE_SUFFIX)"
@echo Generating Motorola S-Record file...
$(CONVERTER) $(SFLAGS)
"$(OBJECT_OUTPUT_PATH)\$(<MSN>_DB).$(EXE_FILE_SUFFIX)" \
-o "$(OBJECT_OUTPUT_PATH)\$(<MSN>_DB).$(S_RECORD_SUFFIX)"
@echo Done ...
###############################################################
# End of the Base Make script #
###############################################################
5.3. Integrating The <MSN> Driver Component With Other Components This section explains the procedure to integrate the <MSN>Driver Component
with other BSW components and the application.
Depending on the various configurations, the following modules are required to
be integrated with the <MSN>Driver Component:
•
<MSN>Interface (Folder ‘Sample_Application’ where the sample
application for <MSN> exists. The variable ‘<MSN>_CORE_PATH’
and the corresponding module Makefile names must be suitably
changed in the base Makefile)
•
Development Error Tracer (Folder ‘Det’ where the DET module files exist.
The variable ‘DET_CORE_PATH’ and the corresponding module
Makefile names must be suitably changed in the base Makefile)
•
Scheduler Manager (Folder ‘SchM’ where the SCHM module exists.
The variable ‘RTE_CORE_PATH’ and the corresponding module
Makefile names must be suitably changed in the base Makefile)
•
MCU Interface (Folder ‘Mcu’ in the give example. The variables
‘MCU_CONFIG_PATH’ and ‘MCU_CONFIG_FILE’ must be suitably
changed in the module Makefile
(Software_Source_Code\ssc\mak\renesas_<MSN>_rules.mak) and
the base Makefile).
All the above folders are given only as examples and they have to be
replaced with actual component folders. It is assumed that every component
has the corresponding module Makefiles.
Apart from the above BSW components, few other folders are provided as
mentioned below:
•
AUTOSAR Type definition Files (Folder ‘common\include’, where the
header files containing standard definitions that are common to all
components are placed. The variable ‘STUB_CORE_PATH’ and the
corresponding module Makefile names must be suitably changed in the
base Makefile)
49
Chapter 5 Application Example
•
RH850 specific Files (Folder ‘X1X\common_platform\generic\include’,where
the header files that are common to all components but specific to Renesas
V850 microcontroller are placed. The variable ‘
GENERIC_PLATFORM_PATH’ and the corresponding module Makefile
names must be suitably changed in the base Makefile)
Compiler specific Files (Folder ‘compiler’, where the header files that are
common to all components but specific to GreenHills Compiler are placed.
The variable ‘COMPILER_PATH’ and the corresponding module Makefile
names must be suitably changed in the base Makefile).
5.4. Building The <MSN> Driver Component This section explains the procedure to build the <MSN>Driver Component for
any given configuration.
The <MSN> Driver Configuration Description file (.arxml) has to be given as
input to the <MSN> Driver Generation Tool. The tool generates output files
namely <Msn>_Lcfg.c, <Msn>_PBcfg.c, <Msn>_Cbk.h and <Msn>_Cfg.h.
Following variables must be defined in the base Makefile described in Section 5.2.1 (Makefile Description) •
PROJECT_ROOT: Root directory where the projects for all components
exist.
•
SPECIFIC_APPL_ROOT_PATH: Directory where the <MSN> sample
application exists.
•
OBJECT_OUTPUT_PATH: Directory where the module specific output
files are generated.
•
STARTUP_<family>_CORE_PATH: Core path for the variant specific
statup files exist.
•
STUB_CORE_PATH: Core path for the stub files exist.
•
COMPILER_PATH: Directory where the compiler files exist.
•
DEVICE_FILE_PATH: Directory where the device files exists.
•
MSN_CORE_PATH: Core path for the <MSN> Driver Component
folder.
•
MSN_TOOL_PATH: Directory where the module specific tool exe exist.
•
CC_INCLUDE_PATH: Path variable where all the header files can be
found by the compiler.
•
CC_FILES_TO_BUILD: Variable that contains the list of source files, to
be compiled and linked.
•
<MSN>_clean_generated_files: This target can be used to clean the
configuration source and header files generated by the <MSN> Driver
Generation Tool.
•
debug_<MSN>_makefile: This target can be used to print the debug
information such as paths used by <MSN> Driver Component.
•
generate_<MSN>_config: This target can be used to invoke the <MSN>
Driver Generation Tool which in turn takes the ECU Configuration
Description files (App_<MSN>_<DEVICE_NAME>_Sample.arxml) as
an input and generates the configuration source and header files.
50
Application Example Chapter 5
Following variables must be defined in the Module Makefile described in Section 5.2.1 (Makefile Description): •
PROJECT_ROOT: Root directory where the projects for all components
exist.
•
MSN_CONFIG_PATH: Configuration path for description file of the
<MSN> Driver Component.
•
MSN_CONFIG_FILE: Name of the <MSN> Driver Component description
file.
•
STUB_CONFIG_PATH: Configuration path for description file of the stub.
•
MCU_CONFIG_FILE: Name of the MCU Driver Component description
file.
•
TRXML_CONFIG_PATH: TRXML Configuration file path used for the
<MSN> Driver Component.
•
TRXML_CONFIG_FILE: TRXML Configuration file used for the <MSN>
Driver Component.
•
BSWMDT_CONFIG_PATH: Path for <MSN> BSWMDT file.
•
BSWMDT_CONFIG_FILE: Name of the <MSN> BSWMDT file.
•
GENERIC_STUB_PATH: Directory where the generic stub exist.
•
GENERIC_PLATFORM_PATH: Directory where the generic platform
files exist.
•
CC_INCLUDE_PATH: Path variable where all the header files can be
found by the compiler.
•
CC_FILES_TO_BUILD: Variable that contains the list of source files, to
be compiled and linked.
•
<MSN>_DB: Name of the Post-build configuration file.
The above mentioned variables must be used by the user to build the base
Makefile.
A sample base Makefile (App_<MSN>_ <MICRO_SUB_VARIANT>
_Device_Sample.mak) has been provided with the product for reference.
This file can be modified to suit the developer’s needs.
The targets that are supported in the base Makefile enable the user in build
and cleanup activities during/after the build process. They are listed below:
5.4.1. Targets Supported By The Sample Base Makefile 5.4.1.1. debug_base_make Invoking the Make utility and passing “debug_base_make” as a parameter
prints all the variables that are used in the base Makefile. This can be used to
print various paths and file names to see if they are correct.
5.4.1.2. clean_objs Invoking the Make utility and passing “clean_objs” as a parameter deletes all
the object files from the output folder
(“X1X\<MICRO_VARIANT>\modules\<msn>\Sample_application\<
MICRO_SUB_VARIANT >\obj” in this case).
51
Chapter 5 Application Example
5.4.1.3. clean Invoking the Make utility and passing “clean” as a parameter deletes tool
generated files in the configuration output folders
(“X1X\<MICRO_VARIANT>\modules\<msn>\sample_application\<
MICRO_SUB_VARIANT>\src” and
“X1X\<MICRO_VARIANT>\modules\<msn>\Sample_application\<
MICRO_SUB_VARIANT>\include”in this case)
.
5.4.1.4. clean_all Invoking the Make utility and passing “clean_all” as a parameter deletes all
files such as object file, list files and map files from the output folder
(“X1X\< MICRO_VARIANT >
\modules\<msn>\sample_application\< MICRO_SUB_VARIANT
>\obj” in this case).
5.4.1.5. generate_<msn>_config Invoking the Make utility and passing “generate_<MSN>_config” as a
parameter invokes the <MSN> Driver Generation Tool. The tool takes the
ECU Configuration Description File(s) (“X1X\< MICRO_VARIANT
>\modules\<msn>\Sample_application\<MICRO_SUB_VARIANT>
\ AUTOSAR_VERSION
config\<MSN>_Sample_ <MICRO_SUB_VARIANT>\.arxml” as input and
generates the output files in folders
“X1X\< MICRO_VARIANT >\modules\<msn>\Sample_application\<
MICRO_SUB_VARIANT>\ AUTOSAR_VERSION \src” and
“X1X\< MICRO_VARIANT >1\modules\<msn>\Sample_application\<
MICRO_SUB_VARIANT>\ AUTOSAR_VERSION \include”).
5.4.1.6. App_<MSN>_< MICRO_SUB_VARIANT >_Sample.out Invoking the Make utility and passing “Sample.out” as a parameter invokes the
compiler and linker sequentially. Then it generates the executable
“App_<MSN>_< MICRO_SUB_VARIANT >_Sample.out”.
5.4.1.7. <Msn>_PBcfg.s37 Invoking the Make utility and passing “<Msn>_PBcfg.s37” as a parameter
invokes
the compiler and linker sequentially and generates the Motorola S-Record file
“<Msn>_PBcfg.s37” in the output folder.
This scenario typically arises when post-build parameters are modified and
only the database needs to be flashed into the device without disturbing the
other ROM contents.
52
Support For Different Interrupt Categories Chapter 6 Chapter 6 Support For Different Interrupt Categories The <MSN> Driver supports CAT1 and CAT2 interrupt categories:
CAT1 In CAT1 type of interrupt ISR does not use an operating system service. In
practice, the OS does not handle these interrupts, and the interrupt handler is
implemented in the driver code, with the only restriction that OS services
cannot be called. Typically, these are the fastest highest priority interrupts.
CAT2 In CAT2 type of interrupt wherein the ISR is handled by the system and OS
calls can be called from the handler.
For CAT1 and CAT2, the selection of interrupt category is for each interrupt in
the module. Individual MCAL module does not contain any option for interrupt
category configuration. The user has to configure the ISR category in OS and
also to use the right MCAL specified name and MCAL expects
"ISR(INTERRUPT_NAME)" keyword defined in OS in case of CAT2.
Notes 1. The understanding is Os module does not publish short name handles for
CAT1 OsIsr container. But it should be defined in the interrupt vector table
by the OS.
2. The understanding is that Os module should publish short name handles
for CAT2 OsIsr container according to ecuc_sws_2108 requirement by
adding the Os_" pefix to the configured interrupt name.
Reference between the <MSN> module and OS: <Msn> module's <Module>_Irq.c/h files include "Os.h" header file to obtain the
interrupt category information configured in the OS. Therefore following pre-
processor definitions are expected to be published in Os.h file by the OS in
case of CAT2 or to be used in the interrupt vector table in case of CAT1.
Table 6-1 CAT1 and CAT2 Naming Convention Interrupt Category Naming Convention CAT1
<MCAL_INTERRUPT_NAME>_ ISR
CAT2
<MCAL_INTERRUPT_NAME>_CAT2_ISR
CAT2 (In case the handles of
Os_<MCAL_INTERRUPT_NAME>_CAT2_ISR
the OsIsr container are
generated without ‘Os_’ prefix
by Os generation tool)
53
Chapter 6 Support For Different Interrupt Categories MCAL in Stand Alone: In case if the MCAL modules are to be used stand alone without having
standard Autosar Os module, the user has to prepare an Os.h stub file with the
published handles only for those interrupt names which are to be used as
CAT2.
Table 6-2 List of ISR Names that need to be configured and published in Os.h (CAT2) or used in the interrupt vector table (CAT1) for <MSN> Driver CAT2(In case the handles of the Sl. OsIsr container are generated CAT1 CAT2 No. without ‘Os_’ prefix by Os
generation tool) 1
<MSN>n_SGm_ISR
<MSN>n_SGm_CAT2_ISR
Os_<MSN>n_SGm_CAT2_ISR
2
<MSN>_DMA_CHxy_ISR
<MSN>_DMA_CHxy_CAT2_ISR
Os_<MSN>_DMA_CHxy_CAT2_IS
R
Where
‘n’ indicate HW Unit number
‘m’ indicate SG Unit number
‘xy’ indicate DMA channel Id number
54
GNU MAKE Environment Chapter 7 Chapter 7 GNU MAKE Environment Every component is delivered with the necessary Make scripts that are
required to integrate the component with the application. The scripts are
compatible with GNU Make version 3.81.
All the delivered Makefiles have to be included in the project level base
Makefile in order to build the component together with the application. Refer
section “
Integration and Build Process” of the respective component User
Manuals for more information on the Makefile variables and their usage.
7.1. Build Process With GNUMAKE When the batch file of certain application is built, the GNU Make utility will be
searched by batch file. The GNU Make utility should be present in the default
path specified by GNUMAKE\PATH variable. By making use of the GNU Make
utility the batch file will be compiled.
7.2. Build Process Without GNUMAKE If GNU Make utility is not present at the default path or present in some other
directory the following procedure is followed to set the Environmental variable
GNUMAKE\PATH.
1. Right click on “My Computer” select properties, user will find System
Properties.
55
Chapter 7 GNU MAKE Environment 2. In System Properties select “Advanced” option, user will find
“Environmental Variables” at the bottom side of window.
3. Click on “Environmental Variables”, user will find “Environment Variables”
window in that, select “New”.
56
GNU MAKE Environment Chapter 7 4. After step 3, user can find “New User Variable” window with “Variable
name” and “Variable path” options which needs to be set, Variable name
will be set as GNUMAKE and Variable path is the path of the directory
where GNU Make utility is present and click ok.
5. After step 4, in “System Properties” window click “Apply” and then “Ok”.
Remark GNU Make utility version 3.81 must be separately downloaded and installed to
use the Makefiles delivered along with the component. More information on the
utility can be found at
http://www.gnu.org/ 57
Chapter 7 GNU MAKE Environment 58
Load Binaries Chapter 8 Chapter 8 Load Binaries Once the Executable or S-Record is generated using the project level base
Makefile, it needs to be downloaded into the target using a Flash programmer.
The user has to read the instructions provided in the Flash programmer’s User
Manual thoroughly before using it.
59
Chapter 8 Load Binaries 60
Appendix Chapter 9 Chapter 9 Appendix 9.1. Translation XML File Translation XML File content format shall be given as mentioned below:
<?xml version="1.0" encoding="UTF-8"?>
<!--
The tag PATH-DETAILS should not be renamed since it is top level element.
-->
<PATH-DETAILS>
<!--
TRANSLATION-FILE-PATH should contain the path of the translation
header file.
The tag TRANSLATION-FILE-PATH should not be renamed. Only respective
value should be updated for the translation header file.
-->
<TRANSLATION-FILE-PATH>
<value_of_<MSN>DeviceName>Path</value_of_<MSN>DeviceName>
</TRANSLATION-FILE-PATH>
<!--
The tags present in DEVICE-FILE-PATH tag should contain the path of
the device specific C Header File.
The tags present in DEVICE-FILE-PATH should be equal to the value
for parameter <MSN>DeviceName present in <MSN>General container.
The tag DEVICE-FILE-PATH should not be renamed.
If multiple device header files need to provide for same device then each file
name should be separated with space.
-->
<DEVICE-FILE-PATH>
<value_of_<MSN>DeviceName>Path</value_of_<MSN>DeviceName>
</DEVICE-FILE-PATH>
</PATH-DETAILS>
9.2. Configuration XML File Configuration XML File content format shall be given as mentioned below:
<?
xml version="1.0" encoding="UTF-8"?>
<!--
61
Chapter 9 Appendix None of the tag from this XML should be renamed or deleted.
-->
<XML>
<!-- Supported Command Line options -->
<OPTION>
<!-- Only ON or OFF should be provided. -->
<HELP>ON/OFF</HELP>
<!-- Only ON or OFF should be provided. -->
<LOG>ON/OFF</LOG>
<!-- Only ON or OFF should be provided. -->
<DRYRUN>ON/OFF</DRYRUN>
<!-- Only ON or OFF should be provided. -->
<OUTPUT>OFF</OUTPUT>
<!-- Name of output directory -->
<OUTPUT-PATH>Path</OUTPUT-PATH>
</OPTION>
<!-- To provide input files. If multiple input files need to be provided then
each file should be separated with ",". -->
<INPUT-FILE>Path</INPUT-FILE>
</XML>
62
Revision History Sl.No. Description Version Date 1.
Initial Version
1.0.0
31-Jan-2013
2.
Following changes are made:
1.0.1
16-Oct-2013
1. -Osrc and -Oinc options are added at section 4.3. Usage.
2. Error message ERR000008 is updated at section 4.8.1. Error
Messages.
3. F1x is renamed to X1x in all relevant places.
3.
Following changes are made:
1.0.2
24-Jan-2014
1. Chapter 5 is updated for paths.
2. F1x and F1L names are removed.
3. Makefile location is updated.
4. Name of executable is updated.
4.
Following changes are made:
1.0.3
08-April-2014
1. Page Number alignment is corrected.
2. R- Number is added for document.
5.
Following changes are made:
1.0.4
17-July-2014
1. Copyright year information is corrected.
2. R- Number is added for document.
6.
Following changes are made:
1.0.5
09-Aug-2014
1. Document is updated as per template.
63
Getting Started Document for X1x MCAL Driver User's Manual Version 1.0.5 Publication Date: Rev.0.01, August 09, 2014
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. 2880 Scott Boulevard Santa Clara, CA 95050-2554, U.S.A.
Tel: +1-408-588-6000, Fax: +1-408-588-6130
Renesas Electronics Canada Limited 1101 Nicholson Road, Newmarket, Ontario L3Y 9C3, Canada
Tel: +1-905-898-5441, Fax: +1-905-898-3220
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-65030, Fax: +49-211-6503-1327
Renesas Electronics (China) Co., Ltd. 7th Floor, Quantum Plaza, No.27 ZhiChunLu Haidian District, Beijing 100083, P.R.China
Tel: +86-10-8235-1155, Fax: +86-10-8235-7679
Renesas Electronics (Shanghai) Co., Ltd. Unit 204, 205, AZIA Center, No.1233 Lujiazui Ring Rd., Pudong District, Shanghai 200120, China
Tel: +86-21-5877-1818, Fax: +86-21-6887-7858 / -7898
Renesas Electronics Hong Kong Limited Unit 1601-1613, 16/F., Tower 2, Grand Century Place, 193 Prince Edward Road West, Mongkok, Kowloon, Hong Kong
Tel: +852-2886-9318, Fax: +852 2886-9022/9044
Renesas Electronics Taiwan Co., Ltd. 7F, No. 363 Fu Shing North Road Taipei, Taiwan
Tel: +886-2-8175-9600, Fax: +886 2-8175-9670
Renesas Electronics Singapore Pte. Ltd. 1 harbourFront Avenue, #06-10, keppel Bay Tower, Singapore 098632
Tel: +65-6213-0200, Fax: +65-6278-8001
Renesas Electronics Malaysia Sdn.Bhd. Unit 906, 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 Korea Co., Ltd. 11F., Samik Lavied' or Bldg., 720-2 Yeoksam-Dong, Kangnam-Ku, Seoul 135-080, Korea
Tel: +82-2-558-3737, Fax: +82-2-558-5141
© 2014 Renesas Electronics Corporation. All rights reserved.
Colophon 1.0
Getting Started Document for X1x MCAL Driver
User’s Manual
R20UT2979EJ0001
Document Outline
4 - KnownIssues_P1x_R403_2015_CW23
KnownIssues_P1x_R403_2015_CW236 - KnownIssues_P1x_R403_2015_CW23s
ID
Category
Summary
Description
ASR_TicketType
Status
22712
General
Usage of value INF not according ASR
Problem description:
BUG
OPEN
requirements
According AUTOSAR_TPS_ECUConfiguration the value 'inf' derived from standard module definition STMD must be used as follows:
ISSUE
• [ecuc_sws_6045] If the min value equals -inf or the max value equals inf in
the StMD the min/max values in the VSMD shall be replaced with the actually
supported min/max values for this implementation.
Expected behavior:
INF shall not be used, but instead the actual MIN/MAX values shall be available in PDFs
Current behavior:
See problem description field.
26927
General
[Port]
Problem description:
BUG
OPEN
AUTOSAR_PORT_Component_UserManual. Lack of information about Exclusives areas in AUTOSAR_PORT_Component_UserManual.pdf. As a result user is facing difficulty during integration.
ISSUE
pdf is lacking information about Exclusives Source Package: AUTOSAR_RH850_P1x_MCAL_E4.03
areas for CRITICAL SECTION PROTECTION
Expected Behavior:
The user manual should contain information about INIT_CONFIG_PROTECTION, REFRESH_PORT_INTERNAL_PROTECTION and SET_TO_DIO_ALT_PROTECTION.
Actual behaviour:
UM only describes SET_PIN_MODE_PROTECTION in chapter 4.4, but SET_PIN_DIR_PROTECTION, INIT_CONFIG_PROTECTION, REFRESH_PORT_INTERNAL_PROTECTION and
SET_TO_DIO_ALT_PROTECTION, SET_PIN_DEFAULT_MODE_PROTECTION, SET_PIN_DEFAULT_DIR_PROTECTION are not mentioned.
26988
General
CAN and LIN modules not following
Problem description:
BUG
OPEN
Autosar requirement BSW00347
As per AUTOSAR requirement BSW00347, the driver modules shall be named as per <MSN>_<VendorId>_<VendorSpecificName>_<ServiceName>.
ISSUE
For Example : 'Can_Init()' will become 'Can_59_Renesas_Init()'.
It shall be followed for File Names, Public APIs, Published Parameters, Memory allocation Keywords and Public data types. But this is not followed in CAN and LIN modules which support
multiple instance as per autosar base definition file.
Expected behaviour:
The driver modules shall be named as per <MSN>_<VendorId>_<VendorSpecificName>_<ServiceName>.
Actual behaviour:
The driver modules(CAN and LIN) are not named as per <MSN>_<VendorId>_<VendorSpecificName>_<ServiceName>.
The following MCAL modules have the tag 'UPPER-MULTIPLICITY-INFINITE' is set to 'true' in Autosar Base Definition file AUTOSAR_MOD_ECUConfigurationParameters.arxml and hence
support multiple instance.
1. CAN
2. Ethernet
3. FLS
4. Flexray
5. ICU
6. LIN
7. PWM
8. WDG
But for Ethernet, FLS, ICU, and PWM modules, the requirement BSW00347 is moved to NA requirements in the Traceability section.
27639
General
PRAGMA define inconsistent to device
<u>Problem Description:</u>
BUG
OPEN
header file package
PRAGMA define differs between io_macros_v2.h from device header file packages and compiler.h in MCAL package.
ISSUE
In Compiler.h:
#define PRAGMA(x) _Pragma(x)
In io_macros_v2.h:
#define PRAGMA(x) _Pragma(#x)
<u>Current Behaviour:</u>
In customer application this might cause a compilation warning due to a macro redefinition if both header files are used.
<u>Expected Behaviour:</u>
Consistent define used in both header files.
27721
General
Command line option -F not working
Problem description:
BUG
OPEN
The -F/FILEVERSION option of generation tool is not working. Instead of listing the version of tool code files, the tool is throwing error 'ERR000011:ECU Configuration Description File is
ISSUE
not provided as input to the Generation Tool'.
Expected behavior:
On the usage of -F/FILEVERSION option, generation tool must list the version of tool code files.
Actual behaviour:
See Problem description.
27747
General
Makefiles use invalid include paths for GHS Problem Description:
BUG
OPEN
builder
The GHS makefiles for sample applications use invalid include paths parameters.
ISSUE
This behaviour has currently no effect to GHS builder but this might change.
It lengthens the command lines without any use.
Actual behaviour:
GHS builder is called with invalid options like
-I\4.0.3
-I\common
Expected behaviour:
Only valid include path parameters shall be used.
27766
General
Functional codes are executing Even after Problem Description:
BUG
OPEN
DEM is reported.
ISSUE
Even after DEM error is reported, functional codes are getting executed, which may result in unexpected behavior of driver.
Similar issue is found in SPI while doing functional testing for E1x V4.00.04 release, And an issue is reported in mantis # bug:26731.
Decided to create new ticket to start investigation for similar issues in all other module (see note:181849).
Expected behavior:
Functional codes shall not execute after reporting DEM Error.
Actual behavior:
Functional codes are executed even after reporting DEM Error.
27974
General
Makefiles specify irrelevant folders for
Problem description:
BUG
OPEN
header search
The -I parameter is used to specify folders where the GHS builder shall search for header files. But also source folders are given.
ISSUE
Actual behaviour:
Many irrelevant folders are given as parameter to GHS builder. When project becomes large the maximum command line length (8k) is exceeded.
Expected behaviour:
Only relevant folders shall be given with -I parameter.
28478
General
CAN-ENTER-EXCLUSIVE-AREA-REF tag is
canEnterExclusiveArea is required inside the entity in BSWMDT, if the referenced exclusive area is used in the entity's code.
BUG
OPEN
missing in the BSWMDT
The entity can be BswCalledEntity, BswSchedulableEntity or BswInterruptEntity.
ISSUE
Actual behaviour:
<BSW-INTERNAL-BEHAVIOR UUID="ECUS:951843a9-6848-4a8d-869a-7b29a87158fa">
<SHORT-NAME>BswInternalBehavior_0</SHORT-NAME>
<EXCLUSIVE-AREA UUID="ECUS:1b965de4-5e4a-49d8-a4cb-e7782386f347">
<SHORT-NAME>VARIABLE_PROTECTION</SHORT-NAME>
</EXCLUSIVE-AREA>
</EXCLUSIVE-AREAS>
<ENTITYS>
<BSW-INTERRUPT-ENTITY UUID="ECUS:8d9d01cd-59a4-4f9d-a0c5-a46966e1b2ad">
<SHORT-NAME>BswInterruptEntity_1</SHORT-NAME>
<IMPLEMENTED-ENTRY-REF DEST="BSW-MODULE-ENTRY">/ArPackage_0/MCU_FEINT_ISR</IMPLEMENTED-ENTRY-REF>
<INTERRUPT-CATEGORY>CAT-1</INTERRUPT-CATEGORY>
<INTERRUPT-SOURCE>INTLVI</INTERRUPT-SOURCE>
</BSW-INTERRUPT-ENTITY>
Expected behaviour:
<BSW-INTERNAL-BEHAVIOR UUID="ECUS:951843a9-6848-4a8d-869a-7b29a87158fa">
<SHORT-NAME>BswInternalBehavior_0</SHORT-NAME>
<EXCLUSIVE-AREA UUID="ECUS:1b965de4-5e4a-49d8-a4cb-e7782386f347">
<SHORT-NAME>VARIABLE_PROTECTION</SHORT-NAME>
</EXCLUSIVE-AREA>
</EXCLUSIVE-AREAS>
28534
General
Wrong upper multiplicity definition for
Problem description:
BUG
OPEN
Configuration container.
In PDF of some MCAL modules the upper multiplicity is defined as
ISSUE
<UPPER-MULTIPLICITY-INFINITE>XX</UPPER-MULTIPLICITY-INFINITE>
The above definitions are not correct according to ASR ecuc_sws_2011.
Actual behavior:
Multiple configuration is not possible due to the above problem.
Expected behavior:
The correct definitions must be as follows:
<UPPER-MULTIPLICITY>XX</UPPER-MULTIPLICITY>
26812
ADC
Unexpected DET ADC_E_IDLE is been raised Problem Description:
BUG
OPEN
from Adc_DisableHardware Trigger
Unexpected DET ADC_E_IDLE is being raised when Adc_DisableHardwareTrigger is invoked for an already enabled group (using the api Adc_EnableHardwareTrigger)whose status is
ISSUE
ADC_STREAM_COMPLETED.
Expected Behaviour :
As per requirement ADC304, the DET ADC_E_IDLE should not be reported when Adc_DisableHardwareTrigger is called for a group that has already been enabled using
Adc_EnableHardwareTrigger.
Actual Behaviour :
The DET ADC_E_IDLE is reported when Adc_DisableHardwareTrigger is called for a group that has already been enabled using Adc_EnableHardwareTrigger.
27492
ADC
HW triggered One-shot conversion in
Problem Description:
BUG
OPEN
Circular Streaming is not working as
As per AUTOSAR specification, one HW trigger should trigger only one ADC channel group conversion stream. The conversion must finish once it receives the HW trigger that is equal to
ISSUE
expected
number of streams configured for the group.
But in the current design single trigger executes the whole stream of conversions.
Expected Behavior:
Only one ADC channel Group conversion stream should happen per H/W trigger.
Actual Behavior:
Streaming conversion is getting completed with single H/W trigger
27505
ADC
'ucGroupSettings' element of
Problem Description:
BUG
OPEN
Adc_GstGroupConfig[] is not generated
LSB of 'ucGroupSettings' element decides whether a group is one-shot or continuous.
ISSUE
properly
'0' means continuous group and
'1' means one-shot group.
But code generator is not generating this properly.
For one-shot mode and circular streaming group it generates '1' and
for continuous mode and linear streaming group it generates '0'
Expected Behavior:
LSB of 'ucGroupSettings' must be '0' for continuous group and '1' for one-shot group.
Actual Behavior:
Code generator is generating the below values,
For one-shot mode and circular streaming group it is generates '1' and
for continuous mode and linear streaming group it generates '0'
27592
ADC
DMA enabled ADC conversion gives wrong Problem description:
BUG
OPEN
conversion result if DTFRRQn register
ISSUE
signals a pending transfer request
Conversion of an ADC group with 'AdcResultAccessMode' => 'ADC_ISR_ACCESS' (Group without DMA) leads to the flagging of DTFRRQn.DRQ bit.
Conversion of an ADC group with 'AdcResultAccessMode' => 'ADC_DMA_ACCESS' (DMA enabled group) when DTFRRQn.DRQ bit already set leads to the return of converted value from
previous cycle.
Therefore DTFRRQn.DRQ bit must be cleared each time when DMA enabled ADC groups conversion is started.
Expected Behavior:
DMA enabled ADC Groups should return the converted result of the current input voltage.
Actual Behavior:
DMA enabled ADC Groups are not returning the converted result of the current input voltage because of already set DTFRRQn.DRQ bit.
27603
ADC
Conversion of a DMA enabled one-shot
Problem description:
BUG
OPEN
ADC group is happening only for the first
One-shot ADC groups with DMA as result access mode is getting converted only for the first trigger and not for the consecutive triggers.
ISSUE
HW trigger and not for the next triggers
Note that if the result access mode is selected as interrupt then it is working as expected.
Expected Behavior:
One-shot ADC groups with DMA as result access mode should convert the group channels for every HW trigger until it is stopped explicitly by Adc_DisableHardwareTrigger()
Actual Behavior:
One-shot ADC groups with DMA as result access mode is getting converted only for the first trigger and not for the consecutive triggers after enabling the group via
Adc_EnableHardwareTrigger()
27613
ADC
HW triggered ADC group with DMA circular Problem description:
BUG
OPEN
streaming access should convert one
Current behaviour of the driver is, HW triggered ADC group with DMA and circular streaming access mode is converts more than one sample per H/W trigger.
ISSUE
sample per one trigger
Sample conversion continues until the group is stopped by calling Adc_DisableHardwareTrigger().
As per the AUTOSAR specification only one sample conversion must be initiated for one HW trigger.
Expected Behavior:
As per the AUTOSAR specification only one sample conversion must be initiated for one HW trigger.
Actual Behavior:
Stream conversion continues with a single HW trigger.
27624
ADC
Adc_GetStreamLastPointer() API does not Problem description:
BUG
OPEN
return the valid sample count when the
Adc_GetStreamLastPointer() API does not return correct number of valid samples when the status of the circular streaming group is ADC_STREAM_COMPLETED. This API must return the
ISSUE
status of the group is
value equal to the configured 'AdcStreamingNumSamples' parameter of that group.
ADC_STREAM_COMPLETED
Expected Behavior:
Adc_GetStreamLastPointer() API must return the maximum sample value when the status of the circular streaming group is ADC_STREAM_COMPLETED.
Actual Behavior:
Adc_GetStreamLastPointer() API is returning random value when the status of the group is ADC_STREAM_COMPLETED.
28094
ADC
Value assigned to register (ADCDnTHGSR) is Problem Description:-
BUG
OPEN
not correct in API Adc_HwInit().
In Private API Adc_HwInit() value assigned to register (ADCDnTHGSR) usADCXnTHGSR is not correct, assignment to this register is as mentioned below.
ISSUE
<b> LpAdcRegisters->usADCXnTHGSR = (uint16)(LpHwUnitConfig->ucGroupSelectMask); </b>
Generated value in structure element "ucGroupSelectMask" is not correct, Thereby selection of T&H group B will not work properly.
In tool code value for structure element <b>"ucGroupSelectMask"</b> is as mentioned below. Here final value in "ucGroupSelectMask" is the value in local variable <b>$grp_mask</b>,
Understanding is that for register ADCDnTHGSR bit positions are in even number, as mentioned in section 30.3.23 of Device manual R01UH0436EJ0070 Rev.0.70, But in Generation Tool
code its considered that ADCDnTHGSR register bit positions are continues, As mentioned in Actual Behavior.
Please check and do needful.
Actual Behavior:-
@Line No 749 of BswPbIm.pm file, SVN Revision $185322
Looping below mentioned code for each channel.
# Fill ucGroupSelectMask
$grp_mask = 0;
$BswPbIm::Dbrom_PbImage{Adc_GstHWUnitConfig}{$index}
{ucGroupSelectMask} = $grp_mask;
if ($chn_trck eq "ADC_TH_GROUPB")
{
<b>$grp_mask = $grp_mask | (1 << $ch_id); </b>
$BswPbIm::Dbrom_PbImage{Adc_GstHWUnitConfig}{$index}
{ucGroupSelectMask} = $grp_mask;
}
28109
ADC
Limit check implementation is not proper
Problem description:
BUG
OPEN
for Polling mode
In the case of Polling, Adc_ReadGroup API is called multiple times in a Loop. From Adc_PollingReadGroup function(called form Adc_ReadGroup API), Adc_ErrIsr is called. In Adc_ErrIsr the
ISSUE
following errors are being cleared by writing 0x0E to ADCDnECR register.
1. Upper Limit/Lower Limit Error.
2. Overwrite Error.
3. Parity Error Clear.
In next polling(calling Adc_ReadGroup), even if the value is beyond Limit/Lower limit, ADC group notification is called and the conversion status is changed to ADC_STREAM_COMPLETED.
Expected Behavior:
ADC driver should trigger the next conversion even if it is configured for one-shot conversion.
Actual Behaviour:
Further conversion is not triggered for one-shot groups.
ADC group notification is called and the conversion status is changed to ADC_STREAM_COMPLETED.
28111
ADC
Conversion is not happening for TH groups Problem Description:
BUG
OPEN
when parameter 'AdcSuspendMode' is
Conversion is happening for ADC groups which contains Track and Hold enabled channels when the configuration parameter 'AdcSuspendMode'
ISSUE
'ADC_ASYNCHRONOUS_SUSPEND' and the in container 'AdcHwUnit' is configured as 'ADC_ASYNCHRONOUS_SUSPEND' and the parameter 'AdcGroupTriggSrc' is 'ADC_TRGG_SRC_SW'.
Trigger is SW
The track and hold functionality is working fine for HW triggered groups even if the parameter 'AdcSuspendMode' is 'ADC_ASYNCHRONOUS_SUSPEND'.
Also, it is working properly for both SW and HW triggered groups if the parameter 'AdcSuspendMode' is 'ADC_SYNCHRONOUS_SUSPEND'
But if the parameter 'AdcSuspendMode' is configured as 'ADC_SYNCHRONOUS_SUSPEND' the generator tool produces the following warning.
"The parameter 'AdcSuspendMode' should be configured as <ADC_ASYNCHRONOUS_SUSPEND> when the channels are enabled for Track and hold feature."
Expected Behavior:
conversion should be happened for both SW and HW triggered groups if parameter 'AdcSuspendMode' is 'ADC_ASYNCHRONOUS_SUSPEND'
Actual Behaviour:
Conversion is not happening if parameter 'AdcSuspendMode' is 'ADC_ASYNCHRONOUS_SUSPEND' for SW triggered groups.
28118
ADC
Critical section protection for global
Problem Description :
BUG
OPEN
structure array "Adc_GpGroupRamData" is
ISSUE
not implemented.
Critical section protection for global structure array "Adc_GpGroupRamData" is not implemented, even though the values of the structure "Adc_GpGroupRamData" is modified in most of
the APIs.
In most of the private API, address of global structure array "Adc_GpGroupRamData" is assigned to a local pointer and then the elements values are changed / modified / read.
Even though the values are changed using local pointer, the value in global structure array "Adc_GpGroupRamData" also gets changed.
Example :
The value of structure element "ddGroupStatus" of "Adc_GpGroupRamData" global structure is being modified in Adc_GroupCompleteMode()
private API called from Adc_Isr().
/* Set group status as conversion completed */
LpGroupData->ddGroupStatus = ADC_STREAM_COMPLETED;
Consider a situation in which API Adc_StopGroupConversion() is called from a high priority task ( say Timer Isr) than that of Adc_Isr(), And if Adc_StopGroupConversion() is called ( for
same group) just after start exciting Adc_Isr(), but not reached above mentioned code.
In this case the status Group Status remain ADC_STREAM_COMPLETED, even after calling Adc_StopGroupConversion().
To avoid such issues, critical sections need to be implemented properly.
Required MO suggestion on same.
Actual Behavior :
Critical section protection not implemented.
28120
ADC
Autosar requirement ADC413 is not taken Problem Description :
BUG
OPEN
care.
ISSUE
As per AUTOSAR requirement ADC413 all API functions, except Adc_Init, Adc_DeInit and Adc_GetVersionInfo are re-entrant. But in current implementation it is not taken care. If the
functions are called
for different channel groups, in current implementation these re-entrant API will not work properly.
Example:-
Consider that SW triggered ADC channel group 0 is already in queue.
Considered that we call Adc_ReadGroup() for ADC group 1 and API Adc_DisableHardwareTrigger() is invoked for ADC Channel group 1 form a interrupt (Like Timer ISR) when only DET
check in Adc_ReadGroup() API is completed. Then execution of Adc_ReadGroup() is pushed to stack and start execution of Adc_DisableHardwareTrigger() API.
When Adc_DisableHardwareTrigger() API complete execution, it pops the ADC channel group 0 from queue, trigger its conversion, and when Adc_ReadGroup() start execution, it will give
unexpected behavior.
similar issues exist in most of the API's,
Requesting MO suggestions on same.
Expected Behavior :
Requirement should be taken care properly and API's except above mentioned should be re-entrant.
Actual Behavior :
Requirement is not taken care.
28121
ADC
Memory section mapping used for global
Probable Description:-
BUG
OPEN
variable "Adc_GaaHwUnitIndex[]" and
1.The global variable "Adc_GaaResultGroupRamData[]" is mapped to memory section "CONFIG_DATA_UNSPECIFIED_SEC_STARTED" (ADC_START_SEC_CONFIG_DATA_UNSPECIFIED), But
ISSUE
"Adc_GaaResultGroupRamData[]" is not
this global variable is not initialized in Adc_PBcfg.c (Generated file).
correct.
Declaration of this variable is as mentioned below.
extern VAR(Adc_ValueGroupType, ADC_NOINIT_DATA) Adc_GaaResultGroupRamData[];
of Adc_Ram.c file.
2. The global variable "Adc_GaaHwUnitIndex[]" is mapped to memory section "VAR_NOINIT_UNSPECIFIED_SEC_STARTED" (ADC_START_SEC_CONFIG_VAR_NOINIT_UNSPECIFIED), But
this global variable is of type const and initialized in Adc_PBcfg.c (Generated file).
Declaration of this variable is as mentioned below.
extern CONST(uint8, ADC_CONST) Adc_GaaHwUnitIndex[];
of Adc_Ram.c file.
Suggested Solution:
1.Adc_GaaResultGroupRamData[] global variable needs to mapped to Uninitialized variable section.
2.Adc_GaaHwUnitIndex[] global variable needs to mapped to initialized constant variable section.
Expected Behavior:- NA
Actual Behavior:- NA
28125
ADC
Register ADCDnTHSTPCR
Problem Description :
BUG
OPEN
(ucADCXnTHSTPCR) needs to use instead of Register ADCDnTHSTPCR (ucADCXnTHSTPCR) needs to use instead of ADCDnTHSMPSTCR (ucADCXnTHSMPSTCR) to stop TRACK & HOLD in following mentioned Line of code.
ISSUE
ADCDnTHSMPSTCR (ucADCXnTHSMPSTCR)
to stop T&H.
As per device manual R01UH0436EJ0070 Rev.0.70 section 30.3.15 ADCDnTHSMPSTCR register is used for starting T&H.
As per device manual R01UH0436EJ0070 Rev.0.70 section 30.3.16 ADCDnTHSTPCR register is used for stop T&H.
1. LpAdcRegisters->ucADCXnTHSMPSTCR = ADC_ZERO;
of Adc_Private_ADCD_ADCB.c file in Private API Adc_HwDeInit().
2. LpAdcRegisters->ucADCXnTHSMPSTCR = ADC_BYTE_ZERO;
of Adc_Private_ADCD_ADCB.c file in Private API Adc_HwStopGroupConversion().
3. Also Adc_Init() needs to update to stop T&H by setting this register.
Actual Behavior :
Register use ADCDnTHSMPSTCR (ucADCXnTHSMPSTCR) to stop TRACK & HOLD.
Expected Behavior :
Register ADCDnTHSTPCR (ucADCXnTHSTPCR) needs to be use to stop TRACK & HOLD.
28134
ADC
Implementation of MRS requirement
Problem Description:
BUG
OPEN
"AR_PN0076_FR_0201" is not proper.
If we call Adc_EnableChannel() API before calling Adc_DisableChannel() API, illegal memory access will occur.
ISSUE
Because when we call Adc_EnableChannel() API internally private API Adc_IntDisableEnableChannel() will call as mentioned below.
Adc_IntDisableEnableChannel(Group, ChannelId, ADC_TRUE)
and in private API Adc_IntDisableEnableChannel(),
if LblApiType( 3rd argument) == ADC_TRUE,
then, decrement the number of channels to disabled,as mentioned in below code
LpGroupData->ucNoofChDisabled--;
Initial value of "ucNoofChDisabled" is zero, so after decrement it become 255, which is not correct result in
illegal memory access or unexpected behavior in API Adc_ReadGroup(), Adc_GetStreamLastPointer(), Adc_ConfigureGroupForConversion() and Adc_IsrConfigureGroupForConversion().
Expected Behavior:
N/A
Actual Behavior:
N/A
Suggested solution:
Add a DET check if particular channel is trying to enable before it is disabled.
28135
ADC
Version check for Dem.h file is not present. Problem description:
BUG
OPEN
As per autosar requirement ADC124 The ADC module shall perform Inter Module Checks to avoid integration of incompatible files.
ISSUE
But version check for Dem.h file is not present in the above mentioned file.
FILE : Adc_Private_ADCD_ADCB.c
Expected Behavior :
Version check should be done.
Actual Behavior :
No version check is performed.
28143
ADC
General requirement
Problem description :
BUG
OPEN
"AR_PN0034_FR_0025" is not considered.
The DMA related registers are not initialized in Adc_init().
ISSUE
The same issue is there with following registers also:
1. ADCDnTHBCR (ucADCXnTHBCR),
2. ADCDnSGCRx (ucADCXnSGCRx),
3. ADCDnSGVCSPx (ucADCXnSGVCSPx)
4. ADCDnSGVCEPx (ucADCXnSGVCEPx)
5. ADCDnSGMCYCRx (ucADCXnSGMCYCRx)
6. ADCDnULLMSRx (ucADCXnULLMSRx)
7. ADCDnADTIPRy (ulADCXnADTIPRy)
8. ADOPDIGn (ulADOPDIGn)
9. ADCDnTHACR
10. ADCDnTHCR
11. ADCXnULLMTBR 0 to 2
are not initialized in Adc_Init().
But as per General MRS "AR_PN0034_FR_0025" :
The <MSN>_Init API shall ensure that the related peripheral is running correctly, even if the peripheral was previously configured by another Application that changed the registers' default
values.
Thereby this General requirement "AR_PN0034_FR_0025" is not considered for above mentioned registers.
Expected Behavior:
The general MRS requirement "AR_PN0034_FR_0025" should be taken care for all above mentioned registers and DMA related registers and all should be initialized in Adc_init().
Actual Behavior:
28151
ADC
AUTOSAR requirement ADC077 is not
Problem Description:
BUG
OPEN
taken care while implementing Adc_Init().
As per this requirement,
ISSUE
[ADC077] The function Adc_Init shall disable the notifications and hardware trigger capability (if statically configured as active).
Configured HW triggers are not disabled in Adc_Init(). If we consider General MRS requirement "AR_PN0034_FR_0025", it needs to be corrected accordingly.
As per this requirement:- "The <MSN>_Init API shall ensure that the related peripheral is running correctly, even if the peripheral was previously configured by another Application that
changed the registers' default values. "
Expected Behavior:
Configured HW triggers to be disabled in Adc_Init()
Actual Behavior:
Configured HW triggers are not disabled in Adc_Init().
28158
ADC
The Cautions mentioned in Device manual Problem Description:
BUG
OPEN
are not implemented.
For example
ISSUE
As per Caution[1]: section 30.3.9
To prevent malfunctions, make ADCDnADCR1 settings after making or confirming the following settings.
(1) HLDTE of T&H group A and B are 0.
(2) ADSTARTE of all scan groups are 0 and TRGMD of all scan groups are 0H.
(3) SGACT of all scan groups are 0 (before scan groups are started).]
Before setting value to ADCDnADCR1 (ucADCXnADCR1) Register in Adc_Private_ADCD_ADCB.c file in Adc_HwInit() API, we are not setting the bits or values of these register bits
mentioned in Caution are unknown to the driver. So based on General MRS requirement "AR_PN0034_FR_0025" this is to be implemented.
Same type of issues are applicable for following registers also. Please check all applicable Cautions.
1. ADCDnADCR2 (ucADCXnADCR2)
2. ADCDnSFTCR (ucADCXnSFTCR)
3. ADCDnTDCR (ucADCXnTDCR)
4. ADCDnODCR (ucADCXnODCR)
5. ADCDnTHACR (ucADCXnTHACR)
6. ADCDnTHER (ucADCXnTHER)
7. ADCDnTHGSR(usADCXnTHGSR)
8. ADCDnSGVCSPx (ucADCXnSGVCSPx)
9. ADOPDIGn (ulADOPDIGn)
Expected Behavior:
none
Actual Behavior:
28165
ADC
DEM error is not reported for Overwrite
Problem description:
FEATURE
OPEN
Error in error ISR Adc_ErrIsr()
In the API Adc_ErrIsr(), ucADCXnOWER register is only used to calculate Physical channel ID. Understanding is that DEM error of Overwrite Error also needs to be reported. Also add
ISSUE
similar DEM error report to other errors like Parity Error, Upper / lower limit error and ID Error.
Expected Behavior:
DEM error needs to be reported.
Actual Behavior:
DEm error is not reported.
28179
ADC
Device manual CAUTION is not considered Problem Description:
BUG
OPEN
for implementation in Adc_HwInit() and
CAUTION mentioned in section 7.10.2.13 of R01UH0436EJ0070 Rev.0.70, is not considered for implementation .
ISSUE
Adc_HwDeInit()
As per device manual Caution
"DTFR.REQSEL can be changed while DTFR.REQEN is 0."
But in current implementation both bits REQSEL and REQEN of DTFRn Register are updating simultaneously as mentioned in below code snippet.
In Adc_HwInit():
LpDmaRegisters->ulDTFRn = LpSGmDmaConfig->ulDmaDtfrRegValue;
ulDmaDtfrRegValue is generated value contain value of both bits REQSEL and REQEN of DTFRn Register.
In Adc_HwDeInit():
LpDmaRegisters->ulDTFRn = ADC_DOUBLE_WORD_ZERO;
Understanding is that before changing the value of DTFR.REQSEL, needs to clear bit DTFR.REQEN.
Expected Behavior:
Please update the design as below.
In Adc_HwInit()
1. Reset: DTFRRQn register (0x00)
2. Clear bits LpDmaRegisters->ulDCENn = ADC_DMA_DTE_DISABLE;
3. LpDmaRegisters->ulDTFRn = LpSGmDmaConfig->ulDmaDtfrRegValue;
For Adc_HwDeInit()
Make similiar changes
Actual Behavior:
In Adc_HwInit():
LpDmaRegisters->ulDTFRn = LpSGmDmaConfig->ulDmaDtfrRegValue;
28184
ADC
Clearing of ID Error is not correct.
Problem Description :
BUG
OPEN
Clearing of Error flags are not correct, In current implementation ADCDnIER.IDE error flag for ID Error is not clearing.
ISSUE
LpAdcRegisters->ucADCXnECR = ADC_CHKCLR_ERROR_FLAG;
of Adc_Private_ADCD_ADCB.c file in Adc_ErrIsr() Private API is used to clear all the error flag.
As per device manual R01UH0436EJ0070 Rev.0.70 Section 30.3.29, register ADCDnECR (Error Clear Register) last 4 digits should be set to clear all error flag.
In Adc_PBTypes_ADCD_ADCB.h file ADC_CHKCLR_ERROR_FLAG value of this macro is 0x0E. So last ADCDnIER.IDE bit is not clear.
Suggested Solution :
Adc_PBTypes_ADCD_ADCB.h file ADC_CHKCLR_ERROR_FLAG value of this macro should be 0x0F to clear all the flag.
Actual Behavior : ID error is not getting clear when all the error flags are made clear.
Expected Behavior : ID error should also getting clear when all the error flags made clear.
28187
ADC
Implementation of MRS requirement
problem Description :
BUG
OPEN
AR_PN0076_FR_0087 and
1.MRS requirement "AR_PN0076_FR_0087" is needs to be take care in Tool code, But in current implementation its not taken care. As per Device manual R01UH0436EJ0070 Rev.0.70
ISSUE
AR_PN0076_FR_0089 is not proper.
section 30.3.28, number of ADCDnULLMTBRx register is 3 (x = 0, 1, 2). In current implementation tool code will not give any error even if we configure channel having limit check more
than 2, when value of parameter "AdcPriorityImplementation" = ADC_PRIORITY_NONE.
2.MRS requirement "AR_PN0076_FR_0089" is needs to be take care in Tool code, But in current implementation its not taken care. As per Device manual R01UH0436EJ0070 Rev.0.70
section 30.3.28, number of ADCDnULLMTBRx register is 3 (x = 0, 1, 2). In current implementation tool code will not give any error even if we configure channel having limit check more
than 2, when value of parameter "AdcPriorityImplementation" = ADC_PRIORITY_HW_SW or ADC_PRIORITY_HW.
Actual Behavior :
For both case generation tool code is not generating validation error, if limit check enabled for more than 3 channel Group with different Limit check setting. Understating is that, it will
not work properly when these groups are queued.
Expected Behavior :
For both case proper validation needs to add in Tool code.
Required MO suggestion on same.
28188
ADC
Register "ADCDnECR" (ucADCXnECR) is not Problem description:
BUG
OPEN
handled properly in Adc_DeInit and
In private API Adc_Init() register "ADCDnECR" (ucADCXnECR) is not implemented.
ISSUE
Adc_Init() API's.
and also in private API Adc_DeInit() register "ADCDnECR" (ucADCXnECR) is upated with zero as mentioned below :
LpAdcRegisters->ucADCXnECR = ADC_ZERO;
Understanding is that to clear error flags ADCDnOWER.OWE, ADCDnPER.PE and ADCDnIER.IDE, we need to set ( write 1) to respective bits of the "ADCDnECR" (ucADCXnECR) register in
Adc_DeInit() and Adc_Init() API.
We can also consider general MRS requirement "AR_PN0034_FR_0025", As per this requirement,
The Adc_Init API shall ensure that the related peripheral is running correctly, even if the peripheral was previously configured by another Application that changed the registers' default
values.
and autosar requirement ADC110 :
The function Adc_DeInit shall return all ADC HW Units to a state
comparable to their power on reset state. Values of registers which are not writeable are excluded. It’s the responsibility of the hardware design that this state does not lead to undefined
activities in the µC.
Expected Behavior :
Register ADCDnECR" (ucADCXnECR) should be updated correctly in Adc_Init and Adc_DeInit APIs as per requirements.
Actual Behavior :
Register ADCDnECR" (ucADCXnECR) is not handled as per the requirements.
28214
ADC
AUTOSAR Requirement ADC091 and
1. as per ADC091 requirement :
BUG
OPEN
ADC277 is not taken care.
"The ADC module’s configuration shall be such that an ADC Channel group contains at least one ADC Channel"
ISSUE
In current implementation AUTOSAR Requirement ADC091 is not taken care, in generation tool.
As per current implementation, tool code is not giving any proper error even if no channel is configured under a ADC Group and tool code will crash by giving error "ERR123001", which is
not correct.
2. As per ADC277 Requirement,
"The ADC module’s configuration shall be such that all channels
contained in one ADC Channel group shall belong to the same ADC HW Unit."
Its found that this SWS requirement is not mapped properly in TSDD, Traceability and TSTP, that's needs to fix accordingly.
Most of the requirement are not tracked properly in Traceability sheet.
Expected Behavior :
point 1. Tool code should give a error message stating no channel is configured for particular ADC group.
point 2. Update TSDD, TSTP, Traceability
Actual Behavior :
point 1. Tool code crash if no channel is configured for a ADC group.
point 2. Requirements are not tracked properly in Traceability sheet.
26442
Can
Transmission History List issues
1) CanIf (CanIf_TxConfirmation) is being called while looping by the Can_TxConfirmationProcessing function.
BUG
OPEN
Any processing isn't being done by hardware, so I'm thinking the time-out isn't being confirmed.
ISSUE
So don't we have to check the time out handling here?
2) It's written on "CLEARING OF ALL TRANSMIT MESSAGE BUFFERS" and a comment in the Can_StartMode function, but how is a transmission history buffer initialized?
RSCAN0THLACCm and RSCAN0TXQPCTRm resister weren't being read, so I didn't understand how to be initialized.
26903
Can
PBcfg file Generation operation terminated Problem description:
BUG
OPEN
due to Illegal division by zero
Generation terminated due to Illegal division by zero at /PerlApp/BswConfigValidate.pm line 561.
ISSUE
can_X1X.exe Can.arxml Sample_Application_F1x.trxml R403_can_F1x_BSWMDT.arxml EcuM.arxml Mcu.arxml Os.arxml Dem.arxml
INF000001: Tool Version: 1.2.3
INF000002: Command line arguments: Can_X1x.exe Can.arxml
Sample_Application_F1x.trxml R403_can_F1x_BSWMDT.arxml EcuM.arxml
Mcu.arxml Os.arxml Dem.arxml
Illegal division by zero at /PerlApp/BswConfigValidate.pm line 561.
Expected behavior:
PBcfg file Generation operation should not be terminated. If any error occurred Generator tool should throw out error with ambiguous error message.
Actual behavior:
PBcfg file Generation operation is terminated due to Illegal division.If any error occurred Generator tool is throwing out error with unambiguous error message.
27020
Can
Walking 0 pattern is not implemented in
Problem description:
BUG
OPEN
Can_RamTst_WalkPath_Algorithm() API
As per Renesas requirement AR_PN0069_FR_0023,the RAM is checked by using data patterns (checker pattern, walking-0 and walking-1 pattern).
ISSUE
But in the current implementation walking-0 pattern is not implemented. This shall be implemented as an enhancement, but it is not a bug since Walking "0"'s pattern and Walking "1"'s
pattern is similar.
Expected behaviour:
As per requirement walking-0 pattern shall be implemented.
Actual behaviour:
In the current code, walking-0 pattern is not implemented.
27183
Can
Can_SelfTestChannel API executes in
Problem description:
BUG
OPEN
modes other than STOPPED
ISSUE
If the controller is not in STOPPED state, the function 'Can_SelfTestChannel' shall be aborted and returns E_NOT_OK. But as per the current implementation, this check is not provided and
the code try to set the operation mode as Halt mode.
Expected behavior:
The function shall be aborted and returns E_NOT_OK, if the controller is not in the STOPPED state.
Actual behavior:
Please see the problem description.
27647
Can
Transmission occurs even if the return of
Problem description:
BUG
OPEN
Can_write() API is CAN_BUSY
If cancellation is enabled, cancellation has to be initiated for the lower priority ID/Identical ID (if identical Id cancellation is also enabled) request when the write request came with the
ISSUE
higher priority ID / identical ID for the same HTH. The TX request for the new L-PDU shall be repeated by the CanIf module, inside the notification function CanIf_CancelTxConfirmation -
requirement [CAN288].
If cancellation is disabled, the new Can_Write() request for the same HTH shall not be accepted and returned with CAN_BUSY. The first write request shall be transmitted which was in
pending state.
The same information is covered with the requirements [CAN213], [CAN214], [CAN215] and [CAN434]
Expected Behaviour:
1. The transmission shall not be there for the Can_Write() request when its return value is CAN_BUSY.
2. The cancellation of the pending transmission has to happen properly, when transmission cancellation is enabled.
Actual Behaviour:
In different scenarios the transmission of the frame happens even after returning the reply as CAN_BUSY for the Can_Write() API call.
EX:
1. When the cancellation is OFF (In polling mode), however the return value of the Can_Write() request for the same HTH is CAN_BUSY, the transmission of the frame is observed on the
CANAlyzer and also Tx confirmation is received.
2. When Identical ID cancellation is ON, however the return for the Can_Write() request for the same HTH with identical ID is CAN_BUSY as expected and cancel confirmation is received,
the transmission is happening without re-requested as stated in requirement [CAN288]. Also complete frame data is '0' and Tx confirmation is received as well.
3. When cancellation is ON, however the return for the Can_Write() request for the same HTH with higher priority ID is CAN_BUSY as expected and cancel confirmation is received, the
transmission is happening without re-requested as stated in requirement [CAN288] and also Tx confirmation is received .
27649
Can
Hth Cancellation is not notifed correctly to Problem description:
BUG
OPEN
the upper layer (CanIf) in case of multiple
There is no while loop, but unnecessarily LucArrPosition incremented and wrong comment provided.
ISSUE
Hth to cancel
uint8_least LucArrPosition;
--code----
if (LblTxCancelFlag == CAN_TRUE)
{
/* Set the BasicCAN HTH count to maximum to exit the while loop */
LucArrPosition = LpPBController->ucNoOfBasicCanHth;
/* Set the TX Cancellation Status flag of the HTH */
Can_RSCAN_GaaTxCancelStsFlgs[(LucArrPosition >> CAN_THREE)] =
(Can_RSCAN_GaaTxCancelStsFlgs[(LucArrPosition >> CAN_THREE)]) |
((uint8)(CAN_ONE << (LucCount % CAN_EIGHT)));
/* Increment the array position to point to next
* BasicCAN HTH of the controller */
LucArrPosition++;
}
else
{
/* No action required */
}
Expected behavior:
None
Actual behavior:
None
27650
Can
Multiple DET error reporting from one API Description:
BUG
OPEN
not compliant with AUTOSAR requirement According to CAN091 from AUTOSAR 4.0.3 CAN SWS - a function that reports a development error shall return immediately after.
ISSUE
In many CAN driver APIs multiple errors are checked and reported, before the function returns. Examples:
* Can_Init() may report CAN_E_TRANSITION, CAN_E_PARAM_POINTER before it returns
* Can_Can_InitController() may report e.g. CAN_E_UNINIT and CAN_E_PARAM_POINTER before it returns)
Expected behaviour:
Every CAN driver API should return immediately with not action after a development error is detected is reported
Actual behaviour:
In some case in CAN APIs multiple development errors can be reported, like for Can_Init(), Can_InitController()
27654
Can
DEM version Check is missing
Problem Description:
BUG
OPEN
As per the requirement [CAN111](BSW004), the AUTOSAR major and minor release version needs to be checked for all the external modules. But the version check for the DEM module is
ISSUE
missing.
Expected Behaviour:
The compilation error shall be reported when the DEM module with different AUTOSAR release version is integrated.
Actual behaviour:
The compilation is happening successfully even when the DEM module with different AUTOSAR release version is integrated.
27742
Can
The MCAL CAN driver shall clear the
Problem Description: The MCAL CAN driver will not clear the corresponding WUF flag in the ISR if the precompile configuration parameter CanWakeUpFactorClearIsr is set to TRUE.
BUG
OPEN
corresponding WUF flag in the ISR
Default value should be FALSE. PDF is reviewed and found that the parameter CanWakeUpFactorClearIsr is not implemented.
ISSUE
(AR_PN0069_FR_0025)
Expected Behavior: AR_PN0069_FR_0025 shall be implemented.
Actual Behavior: AR_PN0069_FR_0025 is not implemented properly
27874
Can
Autosare requirment CAN065_Conf is not
Problem Description:
BUG
OPEN
taken care
As per Autosare SWS CAN065_Conf, CanIdType shall support ID's of type STANDARD, MIXED and EXTENDED. In the current implementation only STANDARD and EXTENDED types are
ISSUE
taken care.
Expected Behavior: MIXED ID type shall also be supported by the PDF.
Actual Behavior: NA
27880
Can
Additional API to cancel Tx is not available Problem Description: The internal function “Can_TxCancel” is available as private API. As per the requirement description, the API shall be available as public API such that CanIf AUTOSAR BUG
OPEN
for CanIf / Upper layer.
module can have corresponding call to this API in order to use it.
ISSUE
Expected Behavior: The internal function “Can_TxCancel” shall be available as additional API (public)
Actual Behavior: NA
27882
Can
CAN_E_DATALOST development error is
Problem description:
BUG
OPEN
not reported
According to AUTOSAR 4.0.3 CAN SWS CAN395: "If the development error detection for the Can module is enabled, the Can module shall raise the error CAN_E_DATALOST in case of
ISSUE
“overwrite” or “overrun” event detection."
This DET error CAN_E_DATALOST is declared in Can.h but it is not used in the code.
Expected behaviour:
Development error CAN_E_DATALOST should be reported if overwrite or overrun events are detected in the reception buffers.
Actual behaviour:
CAN_E_DATALOST development error reporting is nowhere encountered in CAN driver code
27934
Can
Unexpected Behavior of in Can wake up
Problem description: CAN wake up shows unexpected behavior. Wake up ISR is getting triggered, even if wake up is not initiated.
BUG
OPEN
ISSUE
Expected Bahavior: Wake up shall be triggered only on occurance of a wake up event
Actual Behavior: Undefined behavior of CAN wake up
27945
Can
Can_Write request returns CAN_OK when Problem Description: Can_Write request returns CAN_OK when HTH is busy to process another transmit request. Can transmission shall only be initiated after getting tx confirmation on BUG
OPEN
HTH is busy
the last transmitted message.
ISSUE
Expected Behavior: Can_Write request shall return CAN_BUSY when HTH is busy to process another transmit request
Actual Behavior: NA
27965
Can
Can module is malfunctioning on HW Tx
Problem description:
BUG
OPEN
Cancellation.
Can module is malfunctioning when HW Tx Cancellation support is enabled and a Transmit abort request was not successful (the CAN frame was transmitted).
ISSUE
It this particular case, once the Tx Cancellation is initiated inside the Can module source code the global transmit cancel flag “Can_GblTxCancelIntFlg” is set to CAN_TRUE. Later this flag
“Can_GblTxCancelIntFlg” is cleared inside the source code invoked when the "INTCnWUP" interrupt is serviced. But in the current use case, since the Transmit abort request was not
successful, the "INTCnWUP" interruupt is not activated. Instead, the "INTCnTRX" interrupt is activated (frame successfully transmitted from message buffer m), but the source code
invoked when "INTCnTRX" interrupt is serviced (ex. CAN_CONTROLLER0_TX_ISR) does not clear the “Can_GblTxCancelIntFlg” flag.
The flag remains set and this causes subsequent calls to "Can_Write()" to fail and return "CAN_BUSY" result. This renders the Can module incapable to transmit CAN frames any more
(until being re-initialized).
Actual behavior: N/A
Expected behavior: N/A
28070
Can
[X1x][CAN]
Problem Description: While updating ECODE for merging the changes done as part of F1H E4.00.01 release to trunk, in Can_RAMTest API call of 'Can_RamTst_WalkPath_Algorithm' was
BUG
OPEN
Can_RamTst_WalkPath_Algorithm is not
replaced by 'Can_RamTest_Checker_Algorithm'. So now instead of calling Can_RamTst_WalkPath_Algorithm, Can_RamTest_Checker_Algorithm is called second time.
ISSUE
called from Can_RAMTest API
Work Around: Repeated call of 'Can_RamTest_Checker_Algorithm' has to be replaced with 'Can_RamTst_WalkPath_Algorithm'.
Expected behavior: Can_RamTst_WalkPath_Algorithm should be called from Can_RAMTest API.
Actual behavior: Can_RamTst_WalkPath_Algorithm is not called from Can_RAMTest API.
28503
Can
CAN_E_DATALOST development error is
Problem description:
BUG
OPEN
not reported
According to AUTOSAR 4.0.3 CAN SWS CAN395: "If the development error detection for the Can module is enabled, the Can module shall raise the error CAN_E_DATALOST in case of
ISSUE
“overwrite” or “overrun” event detection."
This DET error CAN_E_DATALOST is declared in Can.h but it is not used in the code.
Expected behaviour:
Development error CAN_E_DATALOST should be reported if overwrite or overrun events are detected in the reception buffers.
Actual behaviour:
CAN_E_DATALOST development error reporting is nowhere encountered in CAN driver code
28505
Can
Multiple polling period for Tx and Rx (valid Problem Description:
BUG
OPEN
for R3.2and R4.x) is not supported
This is a task to verify the possibility to configure and handle multiple transmission or reception in polling mode based on SWS R3.2 ID: CAN356,CAN436 (Rx) and CAN358, CAN345 (Tx).
ISSUE
The solution to this issue is to update the CAN code generator to count how many instances of the parameter CanMainFunctionWritePeriod and CanMainFunctionReadPeriod are
configured
and based on this to generate the opportune number of macro
#defines Can_MainFunction_Write_0
#define Can_MainFunction_Read_0
for the 1st instance,
#define Can_MainFunction_Write_1
#define Can_MainFunction_Read_1 for the 2nd instance
The generated code should look like this:
/*Polling Period 0 for Write*/
#define Can_MainFunction_Write_0() Can_MainFunction_Write()
/*Polling Period 1 for Write*/
#define Can_MainFunction_Write_1() Can_MainFunction_Write()
...etc.
Expected behaviour:
N/A
Actual Behaviour:
N/A
28541
Can
Restrict the baudrate to only a limited
Restrict the baudrate to only a limited range is wrong. There are other buadrate like 50K or 25K that can be realized.
BUG
OPEN
range is wrong.
ISSUE
Actually the generator impelementation is to occur error, if the value of the parameter CanControllerBaudRate is other than 33, 83,100,125,250,500 or 1000Kbps for the particular
controller.
Actual Behaviour: Error occurs, if the value of the parameter CanControllerBaudRate is other than 33,83,100,125,250,500 or 1000Kbps for the particular controller.
Expected Behaviour:Error should not occur, if the value of the parameter CanControllerBaudRate is other buadrate like 50K or 25K.
28601
Can
Correct typo in error ERR080034.
Problem Description:
BUG
OPEN
ISSUE
Correct typo in error ERR080034 in BswConfigValidate.pm
Expected behavior:
The description of the ERR shall be "The calculated 'Time Quanta' should be in the range of <8- 25>"
Actual Behavior:
The description of the error is currently
The calculated 'DBT (Data Bit Time)' should be in the range of <8- 25>.
Initialization Check is not performed for
Problem Description:
OPEN
Dio_MaskedWritePort() API In the DIO
Dio_MaskedWritePort() API is not checked whether DIO Is initialized or not.
ISSUE
driver.
Expected behavior:
FUNC(void, DIO_PUBLIC_CODE) Dio_MaskedWritePort
(Dio_PortType PortId,
Dio_PortLevelType Level,
Dio_PortLevelType Mask)
{
------variable declaraiton ----------
/* Check whether DIO_DEV_ERROR_DETECT is enabled */
#if (DIO_DEV_ERROR_DETECT == STD_ON)
/*START of DIO_AR_VERSION */
#if (DIO_AR_VERSION == DIO_AR_HIGHER_VERSION)
if (Dio_GblDriverStatus == DIO_UNINITIALIZED)
{
/* Report Error to DET */
(void)Det_ReportError(DIO_MODULE_ID, DIO_INSTANCE_ID,
DIO_MASKED_WRITE_PORT_SID, DIO_E_UNINIT);
LenDetErrFlag = E_OK;
}
else
{
/* No action required */
}
#endif
24131 DIO
BUG
---------
26249
DIO
The channel group not validated correctly Problem Description:
BUG
OPEN
in
Functional argument pointer 'ChannelGroupIdPtr' is checked only against NULL_PTR in Dio_ReadChannelGroup/Dio_WriteChannelGroup APIs and it is not validated properly to report
ISSUE
Dio_ReadChannelGroup/Dio_WriteChannel DIO_E_PARAM_INVALID_GROUP.
Group APIs
Currently, if wrong or out-of-bound address is passed (Ex: If Dio_GstChannelGroupData[] size is 4 i.e. 0-3 and if &Dio_GstChannelGroupData[4] is passed by mistake), the NULL_PTR
condition check is unable to catch this and the API proceeds for further processing instead of reporting DET DIO_E_PARAM_INVALID_GROUP.
While doing further processing the behaviour might be un-predictable.
Expected Behavior:
The channel group needs to be validated to report DET and it shall not do any further processing detecting DET.
Actual Behavior:
The channel group is not validated to report DET and it shall do further processing even during development error condition.
26251
DIO
Global variable
Problem Description:
BUG
OPEN
(Dio_GusNoOfChannelGroups) and config
The global variable 'Dio_GusNoOfChannelGroups' which is initialised with the value of the config structure member 'usNoofChannelGroups' is used as offset for accessing the channel
ISSUE
structure member (usNoofChannelGroups) group structure when multi config set comes into picture. But the name suggests that it holds the value of "number of channel groups configured" which misleading.
names are misleading
E.g.: If 8 channel groups are configured with two config sets (each), the handles will be generated as,
#define DioConf_DioChannelGroup_DioChannelGroup1 (&Dio_GstChannelGroupData[0])
#define DioConf_DioChannelGroup_DioChannelGroup2 (&Dio_GstChannelGroupData[1])
#define DioConf_DioChannelGroup_DioChannelGroup3 (&Dio_GstChannelGroupData[2])
#define DioConf_DioChannelGroup_DioChannelGroup4 (&Dio_GstChannelGroupData[3])
#define DioConf_DioChannelGroup_DioChannelGroup5 (&Dio_GstChannelGroupData[4])
#define DioConf_DioChannelGroup_DioChannelGroup6 (&Dio_GstChannelGroupData[5])
#define DioConf_DioChannelGroup_DioChannelGroup7 (&Dio_GstChannelGroupData[6])
#define DioConf_DioChannelGroup_DioChannelGroup8 (&Dio_GstChannelGroupData[7])
It shall generate 8 handles pointing 8 channel group structures and the channel structures 9-16 which is applicable for second config set shall be accessed with the help of same handles
with offset value in 'Dio_GusNoOfChannelGroups'. i.e. When config set 0 is initialised its value will be 0. When config set 1 is initialised its value will be 8 for the above case.
Expected Behavior:
The name of this global variable and respective config structure member has to be corrected with meaningful name which is near to it usage. Ex: 'Dio_GusChannelGroupsOffset' and
'usChannelGroupsOffset' respectively.
Actual Behavior:
Variable names are misleading
26572
DIO
Optimize the execution time of RSR register Problem description:
BUG
OPEN
setting sequence
Check the pin direction and prepare the value and write to psr register will take less time to execute when the pin direction check is failed(beginning check itself it will come out). As per
ISSUE
current method Even the pin direction check is failed, Prepare the value to set to the register operation is performed.
Expected behavior:
1.Check the pins direction.(Check the PMSR register.)
2.Prepare the value to set to the register.
3.Write the PSR register.
Source : Please refer to the attached file.(Proposed amendments)
Dio_WriteChannel 168-191
Dio_WriteChannelGroup 407-415
Dio_MaskedWritePort 584-591
Actual behavior:
1.Prepare the value to set to the register.
2.Check the pins direction.(Check the PMSR register.)
3.Write the PSR register.
Function : Dio_WriteChannel, Dio_WriteChannelGroup, Dio_MaskedWritePort
Line : Dio_WriteChannel 931-956
Dio_WriteChannelGroup 1573-1583
Dio_MaskedWritePort 1714-1721
27729
DIO
Unreachable code present in Dio.c
In API Dio_ReadChannelGroup and API Dio_WriteChannelGroup, In the below code if the first condition got true, code will not go inside else part. If the first condition fails the second
BUG
OPEN
condition would also be false. So the code inside the second if block is unreachable that is dead code. The issue is found during UT.
ISSUE
if (ChannelGroupIdPtr == NULL_PTR)
{
/* TRACE [R3, DIO140][R4, DIO140] */
/* TRACE [R4, DIO178] */
/* Report Error to DET */
(void)Det_ReportError(DIO_MODULE_ID, DIO_INSTANCE_ID,
DIO_WRITE_CHANNEL_GROUP_SID, DIO_E_PARAM_POINTER);
LenDetErrFlag = E_OK;
}
else
{
/* Get the pointer to corresponding index in the
array Dio_GstChannelGroupData */
/* MISRA Violation: START Msg(4:0492)-6 */
LpChannelGroupPtr = &ChannelGroupIdPtr[Dio_GusNoOfChannelGroups];
/* END Msg(4:0492)-6 */
if (NULL_PTR == LpChannelGroupPtr)
{
/* Report Error to DET */
(void)Det_ReportError(DIO_MODULE_ID, DIO_INSTANCE_ID,
DIO_WRITE_CHANNEL_GROUP_SID, DIO_E_PARAM_INVALID_GROUP);
LenDetErrFlag = E_OK;
}
else
{
26594
FLS
[F1L][FLS] Mismatch in memory mapping of Problem descripaon:
BUG
OPEN
Fls_MainFunction
There is a mismatch in the memory mapping of Fls_MainFunction.
ISSUE
In Fls.h, Fls_MainFunction is mapped to FLS_START_SEC_PUBLIC_CODE:(See the code below)
254 : #define FLS_START_SEC_PUBLIC_CODE
255 : #include "MemMap.h"
280 : extern FUNC(void, FLS_PUBLIC_CODE) Fls_MainFunction(void);
In Fls.c, Fls_MainFunction is mapped to FLS_START_SEC_SCHEDULER_CODE(See the code below)
1689 : define FLS_START_SEC_SCHEDULER_CODE
1690 : #include "MemMap.h"
1691 :
1692 : FUNC(void, FLS_PUBLIC_CODE)Fls_MainFunction(void)
And in MemMap.h, both FLS_START_SEC_PUBLIC_CODE and FLS_START_SEC_SCHEDULER_CODE are defined as ".FLS_PUBLIC_CODE_RAM".
Expected behaviour:
Memory mapping in both declaration and definition of function shall be unique.
Actual behaviour:
There is difference in the memory mapping of declaration and definition of function Fls_MainFunction.
26925
FLS
Length calculation for misaligned access
Description:
BUG
OPEN
fails
Length calculation in Fls_Internal leads to invalid values.
ISSUE
Actual behaviour:
Resulting length is around 4 billion which causes other function to be in endless loop.
Expected behaviour:
Correct length calculation
27581
FLS
Fls_GVar structure is not initialised
Problem description:
BUG
OPEN
properly according to C89/C90 (ISO/IEC
The initialization of Fls_GVar in Fls_Ram.c is not according to C90 standard. A structure that contains pointers, variables and further structures is simply initialized with "0".
ISSUE
9899:1990)
This is possible in C99 (ISO/IEC 9899:1999, chapter 6.7.8.21), but MCAL shall be implemented according to C89/C90 (ISO/IEC 9899:1990).
In Coding Guidelines EAAR-GL-0084.pdf, EAAR_PN0084_NR_0065 an example is given:
/* Usage and initialization in a C file: */
MyModule_Vector_tst Vector1_st = { 0, 0, 0 };
Expected behaviour:
Each element in the structure shall be initialised properly.
Actual behaviour:
Structure is initialised as VAR(Fls_GVarProperties, FLS_INIT_DATA) Fls_GVar = {FLS_ZERO};
27819
FLS
Fls_Resume cannot interrupt the FLS
Problem Description:
BUG
OPEN
ISR(JOB END).(AR_PN0072_FR_0046)
As per current implementation in Fls_Resume() API, If FLS_DEV_ERROR_DETECT = STD_ON and FLS_TIMEOUT_MONITORING = STD_ON then after waiting for FLS_ISR_TIMEOUT_VALUE, It
ISSUE
starts FLS Resume process without checking whether FLS ISR is serviced (Check whether Fls_GVar.Fls_MutexFlag == FLS_ZERO). In current implementation, It will also not report any DET if
timeout occurred after waiting for FLS ISR is serviced.
This issue exist in file Fls.c V1.3.6.
As per requirement AR_PN0072_FR_0046:-
<Fls_Suspend cannot interrupt the FLS ISR(JOB END). It means when FLS ISR(JOB END) has already entered critical section (protected by semaphore/mutex) the upcoming Fls_Suspend
must wait until ISR(JOB END) exits critical section. until ISR(JOB END) exits critical section.>
Understanding is that above mentioned point in MRS is not correct. As per our understanding correct one is as mentioned below.
<Fls_Resume cannot interrupt the FLS ISR(JOB END). It means when FLS ISR(JOB END) has already entered critical section (protected by semaphore/mutex) the upcoming Fls_Resume must
wait until ISR(JOB END) exits critical section. until ISR(JOB END) exits critical section.>
Expected Behavior: MRS requirement AR_PN0072_FR_0046 needs to implement properly.
Actual Behavior: MRS requirement AR_PN0072_FR_0046 is not implemented properly.
27829
FLS
Fls_Suspend cannot interrupt the FLS
Problem Description:
BUG
OPEN
ISR(JOB END).(AR_PN0072_FR_0045)
As per current implementation in Fls_Suspend() API, If FLS_DEV_ERROR_DETECT = STD_ON and FLS_TIMEOUT_MONITORING = STD_ON then after waiting for FLS_ISR_TIMEOUT_VALUE, It
ISSUE
starts FLS Suspend process without checking whether FLS ISR is serviced (Check whether Fls_GVar.Fls_MutexFlag == FLS_ZERO). In current implementation, It will also not report any DET if
timeout occurred after waiting for FLS ISR is serviced.
This issue exist in file Fls.c V1.3.6.
As per requirement AR_PN0072_FR_0045:- Fls_Suspend cannot interrupt the FLS ISR(JOB END). It means when FLS ISR(JOB
END) has already entered critical section (protected by semaphore/mutex) the upcoming Fls_Suspend must wait until ISR(JOB END) exits critical section.
Expected Behavior: MRS requirement AR_PN0072_FR_0045 needs to implement properly.
Actual Behavior: MRS requirement AR_PN0072_FR_0045 is not implemented properly.
27839
FLS
Fls_Cancel cannot interrupt the FLS ISR(JOB Problem Description:
BUG
OPEN
END).(AR_PN0072_FR_0011)
As per current implementation in Fls_Cancel() API if FLS_DEV_ERROR_DETECT = STD_ON and FLS_TIMEOUT_MONITORING = STD_ON then after waiting for FLS_ISR_TIMEOUT_VALUE, It
ISSUE
starts FLS Cancel process without checking whether FLS ISR is serviced (Check whether Fls_GVar.Fls_MutexFlag == FLS_ZERO). In current implementation, It will also not report any DET if
timeout occurred after waiting for FLS ISR is serviced.
This issue exist in file Fls.c V1.3.6.
As per requirement AR_PN0072_FR_0011:- Fls_Cancel cannot interrupt the FLS ISR(JOB END). It means when FLS ISR(JOB END) has already entered critical section (protected by
semaphore/mutex) the upcoming Fls_Cancel must wait until ISR(JOB END) exits critical section.
Expected Behavior: MRS requirement AR_PN0072_FR_0011 needs to implement properly.
Actual Behavior: NA
27867
FLS
Pre compile switch required to partition
Problem description:
BUG
OPEN
FCL and FDL in source code
ISSUE
(AR_PN0072_FR_0027)
As per AR_PN0072_FR_0027, The source code of FLS module must be partitioned in FCL part and FDL part by
using pre-compile switches.
The Flash library files, in this case FCL/FDL files, shall be included in build process as per FLS module configuration for respective use-cases. Redundant library files shall be excluded from
build process
Expected behavior: The requirement AR_PN0072_FR_0027 shall be implemented
Actual Behavior: NA
27890
FLS
Flash library status mapping
Problem description:
BUG
OPEN
Internal status of underlying libraries, ie. FCL and FDL shall be mapped to FLS driver status accordingly and shall lead to proper job processing result of FLS driver.
ISSUE
In case of critical internal errors, notification must be given and user can decide to take necessary remedy.
Expected behavior:
MRS requirement AR_PN0072_FR_0042 needs to implement.
Actual behavior:
MRS requirement AR_PN0072_FR_0042 is not implemented properly.
28459
FLS
Incomplete linker directive file for FLS
<B>Problem Description:</B>
BUG
OPEN
sample application
The linker directive file of FLS sample application does not contain the entries for
ISSUE
copying the initial variable values from ROM to RAM during startup.
This is typically done by e.g. <pre>.romdata ROM(.data)</pre>
<B>Expected Behaviour:</B>
Variables are initialized by GHS startup as required by C standard.
<B>Actual Behaviour:</B>
Variables are uninitialized, typically at 0 after power on, at any undefined value after reset.
Application might show strange behaviour.
28514
FLS
Negative test cases required to verify the
In Fls.c,in section
BUG
OPEN
boundary check of FLS_CF_OFFSET_VALUE
ISSUE
#if (FLS_FLASH_ACCESS == FLS_CODEFLASH_ACCESS)
/* Virtual address is mapped to physical address */
TargetAddress = TargetAddress - FLS_CF_OFFSET_VALUE;
There shall be a check for TargetAddress against FLS_CF_OFFSET_VALUE before doing subtraction.
Further, it requires negative test cases to verify the boundary check.
28515
FLS
Fls_GulTimeout to be removed from
In Fls_Internal.c, Fls_GulTimeout is actually not used in functions Fls_CFProcessReadCommand and Fls_CFProcessCompareCommand.
BUG
OPEN
functions Fls_CFProcessReadCommand and
ISSUE
Fls_CFProcessCompareCommand
So it should be removed from above mentioned two subfunctions.
28516
FLS
Setting of variable job notification to True In Fls_Internal.c, in API Fls_EndJobProcess(), 'LblJobNotification' variable is set to true irrespective of the condition check "if (R_FDL_OK == Fls_GstVar.GucDFStatus)".
BUG
OPEN
is actually not depending on data flash
ISSUE
status or code flash status
Similar is the case with the check "if (R_FCL_OK == Fls_GstVar.GucCFStatus)".
So the redundant code can be merged in these cases.
28517
FLS
DEM error report should be added
In Fls_Irq.c, Dem_ReportErrorStatus(FLS_E_ERASE_FAILED, DEM_EVENT_STATUS_FAILED) and Dem_ReportErrorStatus(FLS_E_WRITE_FAILED, DEM_EVENT_STATUS_FAILED) should be
BUG
OPEN
depending on the Erase/Write operations. added depending on the Erase/Write operations.
ISSUE
28518
FLS
Tool shall throw error message when
If interrupt is supported (FlsUseInterrupt = ON) and the call back functions are not mapped (NULL), the program will hang.
BUG
OPEN
'FlsUseInterrupt = ON' and the call back
ISSUE
functions are not mapped
The tool code shall be updated to throw error message for above mentioned user configuration.
28520
FLS
Default value of LenReturnValue shall be
In Fls.c,
BUG
OPEN
E_NOT_OK
ISSUE
Default value of LenReturnValue shall be E_NOT_OK. In this way, FLS job request will be rejected in the first place when driver state is busy. This logic is not dependent on DET settings.
28521
FLS
The logic for updating
In Fls_Irq.c, at end of job processing, the logic for updating Fls_GVar.Fls_GenState, Fls_GVar.Fls_GenJobResult and triggering JobEnd or JobError notifications shall be in line with the logic BUG
OPEN
Fls_GVar.Fls_GenState and
in Fls_EndJobProcess function in Fls_Internal.c.
ISSUE
Fls_GVar.Fls_GenJobResult shall be in line
with the logic in Fls_EndJobProcess
In the current implementation, Fls_Erase and Fls_Write support interrupt based job processing. And Fls_EndJobProcess is not required at end of interrupt based job processing.
28522
FLS
JobEnd and JobErrorNotification should
In Fls_Irq.c, Fls_GpConfigPtr->pJobEndNotificationPointer() and Fls_GpConfigPtr->pJobErrorNotificationPointer() should be depending on both (FLS_JOB_NOTIF_CONFIG == STD_ON) && BUG
OPEN
depend on both (FLS_JOB_NOTIF_CONFIG (FLS_INTERRUPT_MODE == STD_ON).
ISSUE
== STD_ON) && (FLS_INTERRUPT_MODE ==
STD_ON)
Actual Behaviour :
if (R_FDL_OK == Fls_GstVar.GucDFStatus)
{
/* Set the job Result to OK */
Fls_GVar.Fls_GenJobResult = MEMIF_JOB_OK;
/* If job ended with success and call the job end call back
* function.
*/
Fls_GpConfigPtr->pJobEndNotificationPointer();
}
else
{
/* Set the job Result to Failed */
Fls_GVar.Fls_GenJobResult = MEMIF_JOB_FAILED;
/* If job ended with error and call the job error call back
* function.
*/
Fls_GpConfigPtr->pJobErrorNotificationPointer();
}
Expected Behaviour :
if (R_FDL_OK == Fls_GstVar.GucDFStatus)
{
28523
FLS
Improvement in PDF of P1x
The following points should be taken care in the Parameter Definition File of P1x.
BUG
OPEN
ISSUE
a. The upper bound/maximum value of FlsFclRamAddress shall be 4276092927 (0xFEDF_FFFF) for P1x.
b. The parameters used in each of the following containers should be re-ordered to give a better overview of parameters.
1. FlsDataFlash
2. FlsCodeFlash
3. FlsPublishedInformation
c. Parameter "FlsDFTotalSize" in 'FlsDataFlash' container should be renamed as "FlsDataFlashSize".
d. The statement in the description of following parameters shall be updated as mentioned.
1. FlsMaxWriteNormalMode : add into description - This parameter is not used for implementation.
2. FlsMaxEraseNormalMode : add into description - This parameter is not used for implementation.
3. FlsTotalSize : improve description - This parameter specifies the total amount of flash memory in bytes that is accessible by FLS driver.
4. FlsNumberOfSectors : add into description - This parameter setting shall be in line with FlsSectorStartaddress.
5. FlsFclRamAddress : add into description - This parameter is not used for implementation.
6. FlsDFTotalSize : improve description - This parameter indicates the physical total size of Data Flash memory.
28545
FLS
Safe exit from while-loop for
In Fls.c,
BUG
OPEN
R_FDL_Handler in Fls_Init shall be realized
ISSUE
as per general requirement
Safe exit from while-loop for R_FDL_Handler in Fls_Init shall be realized as per general requirement.
Timeout monitoring can be considered here.
28546
FLS
DEM error should be reported for transient FLS Initialization (Fls_Init) can fail during driving cycle of ECU, due to eg. operation voltage change, clock frequency change, etc. (transient failures).
BUG
OPEN
failures
Such kind of fault must be notified and afterwards the upper layer can, for example, retry with init procedure until succeeds, or the system can be switched to a safety state if required.
ISSUE
DEM error should be reported here.
28547
FLS
R_FDL_Handler() call in Fls_MainFunction
In Fls.c, R_FDL_Handler() call in Fls_MainFunction and Fls_Init should be protected with critical section.
BUG
OPEN
and Fls_Init should be protected with
ISSUE
critical section
28587
FLS
Unexpected Interrupt pending bit is set in Problem description:
FEATURE
OPEN
Fls_Write and Fls_Erase APIs
In Fls_Write and Fls_Erase APIs, interrupt processing is enabled as follows:
ISSUE
#if (FLS_INTERRUPT_MODE == STD_ON)
/* Enable interrupt processing */
RH850_SV_MODE_IMR_AND(16, (Fls_GpConfigPtr->pFlEndImrAddress),
(Fls_GpConfigPtr->usFlEndImrMask));
#endif
At that point SW nearly always had the interrupt pending bit set, so a first unwanted interrupt occurs quite fast there.
Pending interrupts are not properly handled in the code so that this will cause some confusion because of a pending interrupt from the previous operation.
There is a chance of setting interrupt pending bit from the previous Read operation, which have inbuilt blank check.
Expected behaviour:
Before enabling interrupts, interrupt pending bit shall be cleared.
Actual behaviour:
Interrupt pending bit is set when interrupt processing is enabled in Fls_Write and Fls_Erase APIs
28507
FlsTst
As per Autosar requirement, FlsTst.h
According to Autosar requirement specification, the include of Std_Types.h should be done in FlsTst.h
BUG
OPEN
should include Std_Types.h directly.
ISSUE
But in FlsTst, Std_Types.h is included through FlsTst_PBTypes.h and FlsTst_Types.h in the current implementation. The files can be found in the following svn path -
/trunk/external/X1X/common_platform/modules/flstst/include
Expected behaviour :
FlsTst.h should include Std_Types.h directly.
Actual behaviour :
Std_Types.h is included through FlsTst_PBTypes.h and FlsTst_Types.h
28511
FlsTst
FlsTst_GenLastFgndResult and
FlsTst_GenLastFgndResult and FlsTst_GenOverallBgndResult shall be declared as FLSTST_INIT_DATA, so as to match with memory section FLSTST_START_SEC_VAR_UNSPECIFIED.
BUG
OPEN
FlsTst_GenOverallBgndResult shall be
But in the current implementation FlsTst_GenLastFgndResult and FlsTst_GenOverallBgndResult are declared as FLSTST_NOINIT_DATA. This can be found in the path -
ISSUE
declared as FLSTST_INIT_DATA
\trunk\external\X1X\common_platform\modules\flstst\src\FlsTst_Ram.c
Expected Behaviour :
/* Variable to store the fgnd test result */
VAR(FlsTst_TestResultFgndType, FLSTST_INIT_DATA)FlsTst_GenLastFgndResult
= FLSTST_NOT_TESTED;
/* TRACE [R4, FlsTst154] */
/* Variable to store the overall Bgnd test result */
VAR(FlsTst_TestResultType, FLSTST_INIT_DATA)FlsTst_GenOverallBgndResult
= FLSTST_RESULT_NOT_TESTED;
Actual Behaviour :
/* Variable to store the fgnd test result */
VAR(FlsTst_TestResultFgndType, FLSTST_NOINIT_DATA)FlsTst_GenLastFgndResult
= FLSTST_NOT_TESTED;
/* TRACE [R4, FlsTst154] */
/* Variable to store the overall Bgnd test result */
VAR(FlsTst_TestResultType, FLSTST_NOINIT_DATA)FlsTst_GenOverallBgndResult
= FLSTST_RESULT_NOT_TESTED;
27528
Fr
[P1x][Fr] While doing QAC Static Analysis,
Problem Description:
BUG
OPEN
Some of the Misra violations are not
While running QAC Static Analysis for the Fr_59.c file and Fr_59_Internal.c, QAC Misra rules violations are occuring.Some of the violations are justified and some violations are not
ISSUE
justified.
justified.(For example: The messages such as 4:1843, 4:1863, 4:2985 etc. are not justified.).
Common code change is not in the scope of V4.00.04 P1x release.
Expected Behaviour:
NA
Actual Behaviour:
NA
27727
Fr
[P1x][V4.00.04][FR] The test cases related Problem Description:
BUG
OPEN
to
The test cases related to Dem_ReportErrorStatus(FrDemCtrlTestResultRef, DEM_EVENT_STATUS_FAILED) - FR_ETC_065, Dem_ReportErrorStatus (FrIfDemFTSlotStatusRef,
ISSUE
Dem_ReportErrorStatus(FrDemCtrlTestRes DEM_EVENT_STATUS_FAILED) - FR_ETC_066 and FR_ETC_067 are failing.
ultRef, DEM_EVENT_STATUS_FAILED) -
FR_ETC_06
FR_ETC_065:
In the ESTS, in the Tested functionality, Dem_ReportErrorStatus(FR_E_ACCESS, DEM_EVENT_STATUS_FAILED) is tested.But in the expected test result,
Dem_ReportErrorStatus(FrDemCtrlTestResultRef, DEM_EVENT_STATUS_FAILED) is checked for the APIs Fr_ReceiveRxLPdu, Fr_CheckTxLPduStatus, Fr_TransmitTxLPdu, Fr_CancelTxLPdu.
The test cases FR_ETC_065 is not tested because the Dem_ReportErrorStatus (FrDemCtrlTestResultRef, DEM_EVENT_STATUS_FAILED) is not implemented in the following APIs
Fr_ReceiveRxLPdu, Fr_CheckTxLPduStatus, Fr_TransmitTxLPdu, Fr_CancelTxLPdu.
FR_ETC_066 and FR_ETC_067:
In the ESTS, in the Tested functionality, Dem_ReportErrorStatus(FR_E_ACCESS, DEM_EVENT_STATUS_FAILED) is tested.But in the expected test result,Dem_ReportErrorStatus
(FrIfDemFTSlotStatusRef, DEM_EVENT_STATUS_FAILED) is checked for the APIs Fr_TransmitTxLPdu, Fr_ReceiveRxLPdu.
The test cases FR_ETC_066 and FR_ETC_067 are not tested because the Dem_ReportErrorStatus (FrIfDemFTSlotStatusRef, DEM_EVENT_STATUS_FAILED) is not implemented in the
following APIs Fr_TransmitTxLPdu, Fr_ReceiveRxLPdu.
Expected Behaviour:
FR_ETC_065:
As per the Autosar R4.03 FlexRay SWS requirement,
if any hardware error occurs while running the APIs Fr_ReceiveRxLPdu[FR232], Fr_CheckTxLPduStatus[FR243] , Fr_TransmitTxLPdu[FR223], Fr_CancelTxLPdu[FR613], then it should call
Dem_ReportErrorStatus (FrDemCtrlTestResultRef, DEM_EVENT_STATUS_FAILED) and return E_NOT_OK.
FR_ETC_066 and FR_ETC_067:
As per the Autosar R4.03 FlexRay SWS requirement,
In the API Fr_ReceiveRxLPdu, [FR605]If the optional configuration parameter FrIfDemFTSlotStatusRef exists and a single slot status error bit (vSS!SyntaxError, vSS!ContentError,
vSS!Bviolation) is set, then the slot status information shall be reported to DEM as Dem_ReportErrorStatus (FrIfDemFTSlotStatusRef, DEM_EVENT_STATUS_FAILED).
Actual Behaviour:
27728
[P1x][V4.00.04][FR] the functional
Problem Description:
OPEN
testcases related to Transmit Queue and
In ESTS the functional testcases related to Transmit Queue and Receive Queue functionality (FR_ETC_098, FR_ETC_099, FR_ETC_100, FR_ETC_101, FR_ETC_102, FR_ETC_103) are failing.
ISSUE
Receive Queue functionality are failing.
Expected Behaviour:
After transmitting the Data by invoking Fr_TransmitQueue_Table() it is returning E_OK as per the Expected Test result and when Fr_ReceiveQueue_Table() is invoked, it should E_OK and
also the transmitted data should be received by the controller.
Actual Behaviour:
After transmitting the Data by invoking Fr_TransmitQueue_Table() it is returning E_OK as per the Expected Test result and when Fr_ReceiveQueue_Table() is invoked, it is returning E_OK
as per the expected Test Result but the data is not received.
Fr
BUG
28147
Fr
[P1x][Fr][R4.0]
Problem Description:
BUG
OPEN
Fr_User_Request_Output_Transfer and
Fr_User_Request_Output_Transfer and Fr_User_Request_Input_Transfer API's are returning E_OK but no transmit/receive functionality is happening.
ISSUE
Fr_User_Request_Input_Transfer API's are
not working.
Expected Behaviour:
Transmit/receive functionality should happen in this Fr_User_Request_Output_Transfer and Fr_User_Request_Input_Transfer API's .
Actual Behaviour:
Transmit/receive functionality is not happen in this Fr_User_Request_Output_Transfer and Fr_User_Request_Input_Transfer API's .
28326
[P1x][FR]Some Ecode lines are more than Problem Description:
OPEN
80 characters and trailing spaces are
1.More than 80 characters in following lines :
ISSUE
present.
Fr_59_Internal.c : @L1332 , L1352, 1405,1424,1519,1591,1620,1632,1774,1905,2101
Fr_59.c : @L1909,2561
Fr_59_Debug.h : @L83
Fr_59_GeneralTypes.h:@L277,286
Fr_59_Internal.h : @L71, @L97
Fr_59_Version.h: @L86
Fr_59.h : @L436, L70
2. Trim trailing space not done in following files:
Fr_59.h, Fr_59_Ram.h, Fr_59_PBTypes.h, Fr_59_Internal.h, Fr_59.c, Fr_59_Ram.c, Fr_59_Internal.c
Actual Behavior:
NA
Expected Behavior:
NA
Fr
BUG
28474
Fr
[P1x][Fr][R4.0] Null pointer checking is not Problem Description:
BUG
OPEN
performing.
Null pointer checking is not performing in the following API's
ISSUE
1.Fr_59_ReceiveRxLPdu
line: 3053 (*Fr_LPduStatusPtr = FR_59_NOT_RECEIVED;)
line: 3058 (*Fr_LSduLengthPtr = FR_59_ZERO;)
2.Fr_59_CheckTxLPduStatus
line: 8485 (*Fr_TxLPduStatusPtr = FR_59_NOT_TRANSMITTED;)
Actual behaviour:
When dereference a NULL pointer thereby raising a NullPointerException. It will cause the controller to reset.
Expected behaviour:
Null pointer checking should be performed in the API Fr_59_ReceiveRxLPdu, Fr_59_CheckTxLPduStatus
28397
GPT
Wake up disabled channels are giving DET Description
BUG
OPEN
after GPT_MODE_SLEEP to
-----------
ISSUE
GPT_MODE_NORMAL mode transition.
While Running ATF test case "GPT_FTC_142" its observed that unexpected DET with
ApiId = 0X2 => Service Id of Gpt_DeInit API.
ErrorId = 0XB => DET code to report Timer is already running.
is occurring when calling Gpt_DeInit(), here all channels are expected be in "stopped" state.
We tested as mentioned below, in ATF configuration "ATF_cfg01".
Test Scenario
-------------
1. Call Gpt_Init(&GPT_CONFIG_01) to initialize the driver with [GPT_CONFIG_01].
2. Call Gpt_EnableNotification() for channel 0.
3. Call Gpt_EnableNotification() for channel 1.
4. Call Gpt_EnableNotification() for channel 3.
5. Call Gpt_EnableWakeup() for channel 0.
6. Call Gpt_DisableWakeup() for channel 1.
5. Call Gpt_DisableWakeup() for channel 3.
6. Call Gpt_StartTimer() for channel 0.
7. Call Gpt_StartTimer() for channel 1.
8. Call Gpt_StartTimer() for channel 3.
9. Wait for 1 Seconds.
28405
GPT
Timer is starting automatically when call
While testing ATF test case "App_Gpt_Sample" its observed that notification is occurring when call Gpt_EnableWakeup() in GPT_MODE_SLEEP mode before starting the timer.
BUG
OPEN
Gpt_EnableWakeup() in GPT_MODE_SLEEP
ISSUE
mode.
We tested as mentioned below, in ATF configuration "ATF_cfg05".
1. Call Gpt_Init(&GPT_CONFIG_01) to initialize the driver with [GPT_CONFIG_01].
2. Call Gpt_EnableNotification() for channel 0.
3. Start timer for channel 0.
4. Wait for 200 (ms).
5. call Gpt_GetTimeElapsed() for channel 0.
6. Check whether Time Elapsed > 0 , and it's obtained as expected.
7. Wait for 10 (ms).
8. call Gpt_GetTimeRemaining() for channel 0.
9. Check whether Time Remaining > 0 , and it's obtained as expected.
10. Wait for 5 Seconds.
11. Check whether notification obtained is > 0 , and it's obtained as expected.
12. call Gpt_DisableWakeup() for channel 0.
13. Set GPT mode to 'GPT_MODE_SLEEP' by calling "Gpt_SetMode(GPT_MODE_SLEEP)".
14. Wait for 1 Seconds.
15. Clear The Notification Count.
16. Wait for 2 Seconds.
17. Check whether notification obtained is = 0 , and it's obtained as expected.
18. Set GPT mode to 'GPT_MODE_NORMAL' by calling "Gpt_SetMode(GPT_MODE_NORMAL)".
19. Wait for 2 Seconds.
20. Check whether notification obtained is = 0 , and it's obtained as expected.
21. Set GPT mode to 'GPT_MODE_SLEEP' by calling "Gpt_SetMode(GPT_MODE_SLEEP)".
22. call Gpt_EnableWakeup() for channel 0.
23. Set GPT mode to 'GPT_MODE_NORMAL' by calling "Gpt_SetMode(GPT_MODE_NORMAL)".
24. Wait for 5 Seconds.
25856
ICU
Obsolete code in Icu_HW_Init() function.
Problem description:
BUG
OPEN
At line 754 in Icu_LLDriver.c the following loop is present:
ISSUE
for (LucCnt = ICU_MAX_TIMER_CHANNELS_CONFIGURED; LucCnt < ICU_MAX_CHANNEL;
LucCnt++)
{
This "for" loop is used for external interrupts only and not for timer channels initialization.
Inside the loop you have checks for timer channels, which will always fail, since the loop is only for channels configured with external interrupts.
It seems that everything above the "switch" at line 823 in this loop is obsolete code.
Expected behavior:
N/A
Actual behavior:
N/A
Interrupts(IMR) are enabled All Channel
Problem Description:
OPEN
After calling Icu_SetMode() Api form
As per Autosar4.0.3 ICU requirement says that ICU194 ICU_MODE_NORMAL: Normal operation, all used interrupts are enabled according to the notification requests. ICU_MODE_SLEEP:
ISSUE
ICU_MODE_SLEEP to ICU_MODE_NORMAL. Reducedpower mode. In sleep mode only those notifications are available which are configured as wakeup capable.
Current implementation is
In Icu_SetMode(ICU_MODE_NORMAL) Api called after Icu_SetMode(ICU_MODE_SLEEP) Api.
All interrupts are enabled with out considering Current notification status.
Ver4.01.06 -- release Icu_LLDriver.c
1765: /* Enable Interrupt */
1766: RH850_SV_MODE_IMR_AND(16, (LpImrIntpCntrlReg),
(LpChannelConfig->usImrMaskValue));
Expected Behaviour:
All used interrupts are enabled according to the notification requests
Actual Behaviour:
27622 ICU
All interrupts are enabled with out considering notification status.
BUG
28585
ICU
Component User Manual - Unimplemented Problem Description:
BUG
OPEN
APIs and Not supported features
1. The functionalities which are not supported by the hardware are present in the component user manual.Icu_CheckWakeup, Icu_DisableWakeup and Icu_EnableWakeup should be
ISSUE
removed from user manual.
2. If a feature is not supported please mention "Not supported" in Table 5-1
Expected Behaviour:
NA
Actual Behaviour:
Wakeup functionalities(Icu_CheckWakeup, Icu_DisableWakeup and Icu_EnableWakeup) which are not implemented are mentioned in the user manual, which misleads the user.
27490
MCU
McuResetReason could not be accessed By Problem Description:
BUG
OPEN
EcuMResetReason from
The contents of McuPublishedInformation0/McuResetReasonConf0/McuResetReason could not be accessed from EcuMResetReason since the implementation methodology in
ISSUE
McuPublishedInformation0/McuResetReas McuPublishedInformation dont seem to be according to what AUTOSAR has prescribed
onConf0 container
Note: Why is the P1x McuResetReason implementation different from F1x (The McuResetReason implemented in different way for F1x and P1x devices )
Expected Behavior:
None
Actual Behavior:
None
28160
MCU
GetVersionInfo() API of each module shall Problem Description:
BUG
OPEN
also return “instanceID” as one of the
ISSUE
parameter in Std_VersionInfoType
This ticket is created to track the pre-release review done on P1x MCU work products as part of V4.00.04 release.
Requirement: AR_PN0034_FR_0017
Finding: As per the requirement GetVersionInfo() API of each module shall also return “instanceID” as one of the
parameter in Std_VersionInfoType pointed by the output parameter versioninfo. In the current implementation only moduleid, and vendorid are returned. Instance id is not returned
Expected Behavior:
GetVersionInfo() API of each module shall return moduleid, vendorid and instanceID
Actual Behavior:
GetVersionInfo() API of each module shall return moduleid and vendorid
28170
MCU
Dummy read to register must be
Problem Description:
BUG
OPEN
performed after writing to register.
ISSUE
This ticket is created to track the pre-release review done on P1x MCU work products as part of V4.00.04 release.
Requirement: AR_PN0034_FR_0068
Finding: Synchronizing peripherals register write operation by dummy read. As per this requirement, Dummy read to register must be performed after writing to register. The requirement
is not taken care in Mcu source code.
Expected Behavior:
NA
Actual Behavior:
NA
28202
MCU
APIs Mcu_GetResetReason() and
Problem Description:
BUG
OPEN
Mcu_GetResetRawValue() shall return the
ISSUE
same result in case they are called multiple This ticket is created to track the pre-release review done on P1x MCU work products as part of V4.00.04 release.
times
Requirement: EAAR_PN0079_FR_0086
The APIs Mcu_GetResetReason() and Mcu_GetResetRawValue() shall return the
same result in case they are called multiple times after a reset or a power on
event.
Finding: Add test case to test the requirement.
Expected behaviour:
NA
Actual behaviour:
NA
28382
MCU
McuResetReason added in Mcu schema
In Mcu Schema several reset reason was added in McuPublishedInformation container.
BUG
OPEN
cannot be referenced by EcuM
ISSUE
According with ECUM128_Conf Mcu Reset Reason should be in McuResetReasonConf container so this can be referenced by EcuM module .
28421
MCU
In definition file Mandatory parameter's
Problem Description:
BUG
OPEN
Lower and Upper multiplicity values are not In definition .arxml file Mandatory parameter's Lower and Upper multiplicity value should be one.
ISSUE
taken care properly
parameters are McuLoopCount and McuPbusWaitCount.
example:
In Mcu_PBTypes.h MCU_PBUSWAITCOUNT is define with MCU_PBUSWAITCOUNT_VALUE and is used in Mcu.c file
If McuPbusWaitCount value is not set, In Mcu_Cfg.h for MCU_PBUSWAITCOUNT_VALUE will not be generated any value:
In PBcfg.h file
/* Pbus Count Value for the MCU_PBUSWAITCOUNT */
#define MCU_PBUSWAITCOUNT_VALUE
Expected Behavior:
<!-- PARAMETER DEFINITION: McuPbusWaitCount -->
<ECUC-INTEGER-PARAM-DEF UUID="ECUS:dbeafba1-bfaf-4ca0-8572-235f3c9b9b35">
<SHORT-NAME>McuPbusWaitCount</SHORT-NAME>
<DESC>
<L-2 L="EN">The parameter represents the PBus access wait time.The loop can be minimum 1 to maximum 65535</L-2>
</DESC>
<LOWER-MULTIPLICITY>1</LOWER-MULTIPLICITY>
<UPPER-MULTIPLICITY>1</UPPER-MULTIPLICITY>
Actual Behavior:
<!-- PARAMETER DEFINITION: McuPbusWaitCount -->
<ECUC-INTEGER-PARAM-DEF UUID="ECUS:dbeafba1-bfaf-4ca0-8572-235f3c9b9b35">
<SHORT-NAME>McuPbusWaitCount</SHORT-NAME>
<DESC>
<L-2 L="EN">The parameter represents the PBus access wait time.The loop can be minimum 1 to maximum 65535</L-2>
28444
MCU
Reset reson handling depending on
What is the difference between "McuResetReasonConfPowerOnReset" and "McuResetReasonConfPowerOnFlagReset" ?
BUG
OPEN
POF.POF bit
ISSUE
The implementation seems to be wrong as POF.POF bit seems to be set in both cases mentioned, which means only McuResetReasonConfPowerOnFlagReset is reported and
McuResetReasonConfPowerOnFlagReset is never reported.
28473
MCU
App_MCU_Device_Sample.h Which is not
Problem Description:
BUG
OPEN
as per AR_PN0034_FR_0039.
ISSUE
App_MCU_Device_Sample.h Which is not as per AR_PN0034_FR_0039.
Expected Behavior:
NA
Actual Behavior:
NA
25132
Port
When changing port pin to a DIO mode,
Problem Description:
BUG
OPEN
handling of PSRn(Pn) is different by API.
The port pin can be changed to a DIO mode at API Port_SetPinMode, Port_SetToDioMode and Port_SetPinDefaultMode.Among these the Port_SetToDioMode doesn't set to PSR
ISSUE
register.Is this what Development Team intended?
DIO output level change should be performed in DIO Driver and the user can also decide at the timing of change in the DIO output level.I'm thinking this specification is simplest and is
without mistakes.
Could you tell me why it's such specification?
Expected Behavior :
It is necessary to unify these specifications
Actual Behavior :
the Port_SetToDioMode doesn't set to PSR register.
26487
Port
When Port_SetPinDirection() change
PortPinDirectionChangeable = True
BUG
OPEN
direction from o/p to o/p (refeshing) for
PortPinModeChangeable = True
ISSUE
JTAG pins, the o/p level will set to default
PortPinLevelValue = PORT_PIN_LEVEL_LOW
state.
PortPinInitialMode = DIO_SUPP_PFC_PMCSR
PortPinDirection = <b>PORT_PIN_OUT</b>
Test case:
Port_Init(PortConfigSet0);
while(1)
{
/* This API will initilize all the registers to the initial values */
Port_Init(PortConfigSet0);
/* Set Port Pin level of for JP0_6 to High. */
JPSR0 = 0xFFFF0040;
/* Refresh the pin. */
Port_SetPinDirection (Port_PortGroupJtag00_PortPin60, <b>PORT_PIN_OUT</b>);
}
Expected result:
JP0_6 remains High.
Actual result:
JP0_6 sets to Low.
26852
Port
Local variables may remain not initialized in Problem description:
BUG
OPEN
Port_SetToDioOrAltMode API.
If we have a configuration with the following generated code
ISSUE
/* Availability of numeric port groups */
#define PORT_NUM_PORT_GROUPS_AVAILABLE STD_OFF
/* Availability of alphabetic port groups */
#define PORT_ALPHA_PORT_GROUPS_AVAILABLE STD_OFF
/* Availability of jtag port groups */
#define PORT_JTAG_PORT_GROUPS_AVAILABLE STD_OFF
then in Port_SetToDioOrAltMode() API the local variables LpFuncCtrlReg and LulBaseAddress will be used without being initialized.
Expected result:
N/A
Actual result:
N/A
27039
Port
Port Group 4 Pin 6 MUX appears to be mis- Problem description:
BUG
OPEN
labeled in the Parameter defitnition file.
Port Group 4 Pin 6 MUX appears to be mis-labeled in the Parameter definition file. It is labeled as TAUD202_ALT6_OUT, while according to the HW user manual "2.4.1.7 Port 4 (P4)" it is
ISSUE
related to TAUD2O3.
Expected behavior:
Port Group 4 Pin 6 MUX must be labeled as TAUD2O3_ALT6_OUT.
Actual behavior:
Port Group 4 Pin 6 MUX is labeled as TAUD2O2_ALT6_OUT.
27079
Port
Port Generator throwing unwanted error
Problem description:
BUG
OPEN
If PortIpControl is enabled for e.g. CSI pins as recommended in description of PortIpControl, then error 124018 is raised.
ISSUE
Pin names in description of PortIpControl do not match to available options in PortPinInitialMode.
This issue is valid for 701011 device, but not for 701035.
Expected behaviour:
No error should occur.
Actual behaviour:
ERR124018 Error occurs that is in contradiction to description.
27676
Port
Fail to initialize the PFCAE registers
Problem Description:
BUG
OPEN
correctly
The register initialization sequence in Port_InitConfig() api is not as mentioned in r01uh0436ej0070_rh850p1x.pdf(v0.70) at page 122 Section 2.3.4.6.
ISSUE
Expected Behavior :
PFCAE register along with PFC and PFCE should be initialized after initializing
PINV register.
Actual Behavior :
The function control registers(PFC,PFCE,PFCAE) are initialized before PINV register initialization
28391
Port
PINVn register is not setting properly in API Problem description:
BUG
OPEN
Port_SetPinDirection()
Value updating to PINVn — Port Output Level Inversion Register write protection is not implemented as in device User Manual.
ISSUE
Expected behavior:
Needs to follow the write protection sequence mentioned in device User Manual.
Actual behavior:
Register write protection is not implemented properly.
28447
Port
PMSR register access is not correct
Problem description:
BUG
OPEN
PMSR register is accessing without checking whether PMSR register is present for that particular Port group.
ISSUE
Expected behavior: Before accessing PMSR register check whether PMSR register is exist is required.
/*Check for PMSR register availability */
if (PORT_REG_NOTAVAILABLE != LpSetPinModeGroupStruct->ucPMSRRegIndex)
{
...
}
Actual behavior:
This check is not present result in illegal memory access.
28539
Port
Pre compiler Macro is surrounded code at Problem description:
BUG
OPEN
wrong place in Port_FilterConfig()
ISSUE
Pre compiler Macro "PORT_DNFA_REG_CONFIG" is surrounded code at wrong place in Port_FilterConfig().
#if ((PORT_DNFA_REG_CONFIG == STD_ON) || (PORT_FCLA_REG_CONFIG == STD_ON))
#define PORT_START_SEC_PRIVATE_CODE
#include "MemMap.h"
STATIC FUNC(void, PORT_PRIVATE_CODE) Port_FilterConfig(void)
{
/* Pointer to digital filter DNFA register data structure */
#if (PORT_DNFA_REG_CONFIG == STD_ON)
P2CONST(volatile Port_DNFARegs, AUTOMATIC, PORT_CONFIG_DATA) LpDNFAReg;
/* Pointer to Edge control EDC register data structure */
#if (PORT_EDGE_DETECT_CONTROL == STD_ON)
P2CONST(volatile Port_EDCRegs, AUTOMATIC, PORT_CONFIG_DATA) LpEDCReg;
#endif /* End of PORT_EDGE_DETECT_CONTROL == STD_ON */
-----code-----
#endif /* End of PORT_DNFA_REG_CONFIG == STD_ON */
-----code----
Port_FilterConfig() API is enabled by PORT_DNFA_REG_CONFIG is STD_ON or PORT_FCLA_REG_CONFIG is STD_ON,
In side variable declaration is done for PORT_DNFA_REG_CONFIG is STD_ON, When PORT_DNFA_REG_CONFIG is STD_OFF and PORT_FCLA_REG_CONFIG is STD_ON it will corrupted.
Expected behavior:
Pre compiler Macro should be surrounded the E-code at appropriate places.
25724
PWM
Det PWM_E_PARAM_CHANNEL is not
Problem description:
BUG
OPEN
reporting for Pwm_SetTriggerDelay().
For the current PWM driver implementation we face the problem that it is not reporting Det PWM_E_PARAM_CHANNEL for Pwm_SetTriggerDelay() when configured for PWM TAU
ISSUE
channel.
Expected behavior:
Det PWM_E_PARAM_CHANNEL should report for Pwm_SetTriggerDelay() when configured for PWM TAU channel.
Actual behavior:
DET is not occuring.
26874
PWM
Pwm_SelectChannelClk is starting the PWM Problem Description:
BUG
OPEN
diag channels configured for sync start
If you configure 2 channels 1 on TAU and one PWM diag in sync start mode. If after Pwm_SynchronousInit() API, Pwm_SelectChannelClk() is called, the pwm diag channel will start even
ISSUE
before calling Pwm_SynchronousStart().
Expected behavior:
Channels marked as synchronous shall start only after Pwm_SynchronousStart() API is called.
Current behavior:
Check the problem description
28292
PWM
[P1x][PWM] PWM notification is not
Problem Description:
BUG
OPEN
handled properly
1. PWM notification null pointer checking is not performing on Pwm_HW_Callback ISR
ISSUE
2. Notification will send for wrong PWM channels/channels which are not configured.
Actual behaviour:
With in Pwm_HW_Callback ISR, channel id is incrementing with in a for loop. Notification checking and sending is doing outside this for loop. After the execution of that for loop channel id
will be, exact channel id + 1 + number of slave channels. So the notification will send for wrong channels or try to send notification for the channels which are not configured.
Example: we have configured 7 channels out of which 3 are slave channels.
and the interrupt is coming for 4th master channel.
So at the end of the 'for' loop, channel id will be 8. This will cause out of array access and if the value of that memory location is one, it will try to send notification, which is not configured.
This will cause the controller to reset.
Expected behaviour:
1.PWM notification null pointer checking should be performed in Pwm_HW_Callback ISR
2.PWM notification checking should be with proper channel id.
25663
RamTst
[P1x][RAMTST][R4.0] The test result is not RamTst_GetTestResultPerBlock() does not return RAMTST_RESULT_UNDEFINED, when March test on the specific block is running.
BUG
OPEN
RAMTST_RESULT_UNDEFINED, if a March
ISSUE
Test on this block is running.
25664
RamTst
[P1x][RAMTST][R4.0] RamTst_FillPattern
When the configuration parameter RamTstTestPolicy for a block is set to RAMTEST_DESTRUCTIVE, the test algorithm does not fill the tested cells after the test with the bit pattern defined BUG
OPEN
not getting updated in the RAM location
for this block by parameter RamTst_FillPattern except for the test algorithm RAMTST_ABRAHAM_TEST_APP.
ISSUE
when RamTstTestPolicy is
RAMTEST_DESTRUCTIVE.
26482
RamTst
Dem event parameter name not generated Problem Description:
BUG
OPEN
correctly
If the short name of DemEventParameter in file Dem_RamTst.arxml is not appended with any number then the Dem event parameter name is not getting generated correctly.
ISSUE
Expected Behaviour:
DEM event parameters should generated correctly as follows
#define RAMTST_E_RAM_FAILURE \
DemConf_DemEventParameter_DemEventParameter
Actual Behaviour:
DEM event parameters are generated as follows
#define RAMTST_E_RAM_FAILURE \
DemConf_DemEventParameter_
This results in compilation issues as "the identifier "DemConf_DemEventParameter_" is undefined"
28604
RamTst
Issues in EUM.
Problem Description:
BUG
OPEN
This ticket is to report the defects found in EUM.
ISSUE
1.In Section 8 "Software Generation Tool" and "Driver Generation Tool" are used in parallel, which is misleading.
[Driver Generation Tool] should be used here.
2.In Revision History SI. No. 4 "As part of P1x V4.00.04 activity following changes are made:" should be removed.
3.In Section 4.5 'X' is not marked for user mode for RamTst APIs, even with known limitations listed in Table 4-1. This is not in line with other MCAL modules.User mode is supported by
RamTst_RunFullTest, RamTst_RunPartialTest, RamTst_MainFunction, but with precondition that the critical section should be disabled.
Expected behavior
N/A
Actual behavior
N/A
28605
RamTst
RamTst_Ram.c and RamTst_Ram.h files are Problem Description :
BUG
OPEN
missing.
ISSUE
Unlike other MCAL modules there are no dedicated files, ie. RamTst_Ram.c and RamTst_Ram.h, to address global variables.
In other MCAL modules <MSN>_Ram.c and <MSN_Ram.h> used to address global variables.
Actual Behavior :
No dedicated file is exist to address global variables.
Expected Behavior :
To maintain consistent file structures across all the MCAL modules these files should be added to address global variables.
28607
RamTst
Autosar requirement RamTst033 is not
Problem Description :
BUG
OPEN
implemented properly.
ISSUE
As per AUTOSAR requirement RamTst033 :
"If the DET is enabled and the execution status of the RAM Test is
not RAMTST_EXECUTION_RUNNING or RAMTST_EXECUTION_SUSPENDED, the
function RamTst_Stop shall report the error value RAMTST_E_STATUS_FAILURE to
the DET, and then immediately return."
Actual Behavior :
In the current implementation execution status is checked against STOPPED as below:
else if (RAMTST_EXECUTION_STOPPED == RamTst_ExecutionStatus) in RamTst_Stop API.
Expected Behavior :
N/A
28608
RamTst
Autosar requirement RamTst003 is not
Problem Description :
BUG
OPEN
implemented properly.
ISSUE
As per this requirement RamTst.h shall include Std_Types.h directly.
In current implementation Std_Types.h is included via RamTst_Types.h.
Actual Behavior :
Std_Types.h is included RamTst_Types.h and RamTst_Types.h is included RamTst.h which is not correct as per Autosar requirement RamTst003.
Expected Behavior :
RamTst.h shall include Std_Types.h directly.
25109
SPI
SpiJobEndNotification functions are not
Problem description:
BUG
OPEN
generated correctly, when two or more
SpiJobEndNotification functions are not generated correctly, when two or more Jobs have the same JobEndNotification function.
ISSUE
Jobs have the same JobEndNotification
Some JobEndNotifications functions are NULL after the generation, in spite they are not configured as NULL.
function.
There is no information or warning in the generator's manual, that this configuration would not be allowed.
Expected behavior:
If the following SpiJobEndNotifications are in one configuration:
TswSpi_AsyncJobEndNotif
TswSpi_AsyncJobEndNotif
NULL
NULL
TswSpi_PrioCheckJob1EndNotif
TswSpi_PrioCheckJob2EndNotif
TswSpi_PrioCheckJob3EndNotif
TswSpi_PrioCheckJob4EndNotif
TswSpi_PrioCheckJob5EndNotif
NULL
NULL
the same should be expected to be generated in Spi_BPcfg.c
Actual behavior:
Instead in Spi_BPcfg.c we have the following:
NULL_PTR
TswSpi_AsyncJobEndNotif
NULL_PTR
26389
SPI
Short name, File name and Path generated Problem Description:
BUG
OPEN
for error id ERR083058 is incorrect
ERR083058 message is generating as follows
ISSUE
The reference path </AUTOSAR/EcucDefs/Dem0/DemConfigSet0/DemEventParamete> provided for the parameter 'SPI_E_HARDWARE_ERROR' in the container
'SpiDemEventParameterRefs', having shortname <HASH(0x31829ac){ShortName}> is incorrect.
File Name: HASH(0x31829ac) {FileName}
Path: HASH(0x31829ac){ShortName}
Expected Behaviour:
Correct Short name, File name and Path should be generated for error id ERR083058.
Actual Behaviour:
Short name, File name and Path generated for error id ERR083058 are wrong.
26420
SPI
Execution stuck in Spi_HWTransmitSyncJob Problem Description:
BUG
OPEN
function
ISSUE
When a sequence is transmitted synchronously, the execution hangs in Spi_HWTransmitSyncJob.
Expected Behaviour:
Sequence should be transmitted without hang.
Actual Behaviour:
Calling Spi_SyncTransmit API results hanging in Spi_HWTransmitSyncJob API .
26764
SPI
The SPI driver does not change its status in Problem description:
BUG
OPEN
case of data consistency error occurs
In case of data consistency error flag (CSIHnDCE) is set during SPI sync transmission, the ongoing sequence is aborted.
ISSUE
during sync transmission.
The problem is that after the ongoing sequence was aborted, the global variable Spi_GusHwStatus is not changed by the Spi_SyncTransmit API. This blocks all the next SPI communication.
Expected result:
In case of consistency error detection during SPI Sync transmission, the ongoing sequence must be cancelled.
Actual result:
After consistency error detection during SPI Sync transmission, whole further communication is blocked.
A workaround is not to enable the CSIHnCTL1.CSIHnDCS bit, until this issue is not fixed.
27688
SPI
Illegal Memory access in Spi_Driver.c in API Problem description:
BUG
OPEN
Spi_TransmitISR()
If the if condition:
ISSUE
if (SPI_FIFO_BUFFER_FULL != Spi_GucHWFifoBufferSts[SPI_FIFO_RX_INDEX])) fails,
the pointer LpPBChannelConfig will not be initialised (since it is written in the if condition at Line 5618)
This would lead to an illegal memory access (at Line:5707) where LpPBChannelConfig is used.
Expected Behavior:
The variable LpPBChannelConfig shall be initialized before used
Actual behavior:
If the if condition ((if (SPI_FIFO_BUFFER_FULL != Spi_GucHWFifoBufferSts[SPI_FIFO_RX_INDEX]))) fails, LpPBChannelConfig is not initialized.
27707
SPI
Illegal Memory access in Spi_Driver.c
Problem Description: In Spi_Driver.c, API Spi_TransmitISR(), the local variable LpJobConfig is initialized in the part of code as below.
BUG
OPEN
ISSUE
if (SPI_FIFO_BUFFER_UNINIT == Spi_GucHWFifoBufferSts[SPI_FIFO_RX_INDEX])
{
..............;
...............;
LpJobConfig = Spi_GpFirstJob + LddJobIndex;
}
If the condition SPI_FIFO_BUFFER_UNINIT is not equal to Spi_GucHWFifoBufferSts[SPI_FIFO_RX_INDEX]), the variable LpJobConfig will not be initialized. This could lead to illegal memory
access since the variable is also used elsewhere. Eg: In the do while loop below the if loop mentioned in the description,
#if (SPI_DMA_MODE_ENABLE == STD_ON)
/* MISRA Violation: START Msg(4:2962)-18 */
if ((SPI_INTERRUPT_MODE == Spi_GddAsyncMode) &&
(SPI_INVALID_DMAUNIT == LpJobConfig->ucRxDmaDeviceIndex))
/* END Msg(4:2962)-18 */
#endif
Expected Behavior: None
Actual Behavior: Illegal Memory access could happen if the if condition mentioned in the problem description fails.
27978
SPI
Spi_SyncTransmit API is not working
Problem Description:
BUG
OPEN
properly.
ISSUE
when calling Spi_SyncTransmit() an exception is occurring from private API Spi_HWTransmitSyncJob(). On analysis we found that this is because of improper handling of a while loop exit
criteria, resulting in illegal memory access.
Expected behavior:
Spi_SyncTransmit() execute with out any exception.
Actual behavior:
An exception is occurring while execution of Spi_SyncTransmit() API.
28233
SPI
Improper pre-compiler switch for the
Problem Description:
BUG
OPEN
Spi_Mainfunction_Handling function
Spi_Mainfunction_Handling function should be invoked only when polling mechanism is selected by Spi_SetAsyncMode API. This mode can be set only when the SPI_LEVEL_DELIVERED is
ISSUE
definition
two. but the pre compiler switch for the function definition is as follows
#if (((SPI_LEVEL_DELIVERED == SPI_ONE) || (SPI_LEVEL_DELIVERED == SPI_TWO)) \
&& (SPI_HWUNIT_ASYNCHRONOUS == STD_ON))
#define SPI_START_SEC_PUBLIC_CODE
#include "MemMap.h"
FUNC(void, SPI_PUBLIC_CODE) Spi_MainFunction_Handling (void)
{
...
Expected Behaviour:
Spi_Mainfunction_Handling function shall be available in Level 2 only.
Actual Behaviour:
Spi_Mainfunction_Handling function is available in Level 1 and 2 also.
28249
SPI
SpiFifoTimeOut parameter is mandatory
Problem description:
BUG
OPEN
SpiFifoTimeOut parameter is made mandatory but it is only valid for CSIH
ISSUE
Expected behaviour:
SpiFifoTimeOut parameter should be optional (multiplicity 0..1) and additionally there should be a generator error check in case it is not configured for CSIH HW units in FIFO mode.
28251
SPI
The information provided about user mode Problem Description:
BUG
OPEN
and supervisor mode is not correct in the
In the user manual Table 4-5, it indicates that Spi_MainFunction_Handling() requires Supervisor mode access when Interrupt mode is active (SI. No. 14), though
ISSUE
user manual
Spi_MainFunction_Handling() is not necessary in interrupt mode.
Also, Spi_AsyncTransmit(), SI. No. 4 in Table 4-5, is missing any mark in the Interrupt Mode/user mode column..
Expected Behaviour:
Spi_MainFunction_Handling shall be removed in interrupt mode and Spi_AsyncTransmit() shall be corrected for applicable modes.
Actual Behaviour:
Spi_MainFunction_Handling is marked for both interrupt and Polling modes. and Spi_AsyncTransmit() is missing any mark in the Interrupt Mode/user mode column.
28364
SPI
Error ERR083120 is generated when
Problem Description:
BUG
OPEN
SpiEnableCs is configured as false
When the Parameter SpiEnableCs is configured as false SpiPortPinSelect should not be configured. But when SpiPortPinSelect is not configured tool is generating error ERR083120- the
ISSUE
parameter 'SpiPortPinSelect' value in the container 'SpiJob<x>', should be configured as CSL<n> since 'CSIH<x>' is configured.
Expected Behaviour:
Tool should not generate error.
Actual Behaviour:
ERR083120 is generated.
28456
SPI
Variables are uninitialized when the certain Problem description:
BUG
OPEN
condition does not meet.
Some of the Variables are uninitialized when the following conditions are not met.
ISSUE
when the SPI_DIRECT_ACCESS_MODE is STD_OFF
Expected behavior:
Before using the variables, Variables should be initialized.
Actual behavior:
Before using the variables, Variables are not initialized when SPI_DIRECT_ACCESS_MODE is STD_OFF
28676
SPI
Calling of Spi_MainFunction_Handling
Description:
BUG
OPEN
possible in interrupt mode
If interrupt mode is selected (Spi_SetAsyncMode(SPI_INTERRUPT_MODE))
ISSUE
a call to Spi_MainFunction_Handling() is possible. Functions Spi_TransmitISR and Spi_ReceiveISR are called there without further checks. This can cause
corrupted data transmission.
Actual Behavior:
No error but corrupted data.
Expected Behavior:
In interrupt mode a call to Spi_MainFunction_Handling shall be rejected, e.g. by DET.
28199
WDG
Wdg_SetMode function reports DEM error Problem description:
BUG
OPEN
if WDGIF_OFF_MODE is selected
As per AUTOSAR specification [WDG160], Wdg_SetMode function supports WDGIF_OFF_MODE.
ISSUE
And the user sets WdgDisableAllowed parameter 'true' in Configuration tool.
However, in code Wdg_59_DriverA_SetMode function reports a Dem Error in case WDGIF_OFF_MODE is selected.
Wdg_59_DriverA_SetMode function in Wdg_59_DriverA.c:
if (Mode == WDGIF_OFF_MODE)
{
/* Report Error to DEM */
Dem_ReportErrorStatus(WDG_59_DRIVERA_E_DISABLE_REJECTED,
DEM_EVENT_STATUS_FAILED);
WDG driver does not allow Wdg_SetMode function to translate the state into OFF by "4.4 WDG State Diagram" in WDG Driver Component Embedded User's Manual Rev.0.01 Nov 2013.
Customer need to know the background for this.
Expected behaviour:
Wdg_SetMode function shall report DEM error only if required mode is 'WDGIF_OFF_MODE' and 'WdgDisableAllowed' is false.
Actual behaviour:
Wdg_SetMode function is reporting DEM error only if required mode is 'WDGIF_OFF_MODE' and 'WdgDisableAllowed' is true.
7 - Releasenotes_P1x_FULL_R403_Ver4.00.04
19 - Releasenotes_P1x_FULL_R403_Ver4.00.04s
Renesas Electronics
Release Date: 08/06/2015
Release Notes for RENESAS RH850/P1x:
RENESAS_SW-AUTOSAR-P1x: MCAL Ver4.00.04
QM Beta Quality
1.1 Purpose:
To deliver AUTOSAR R4.0.3 MCAL software for P1x V4.00.04 release using the following inputs.
Device Manual: r01uh0436ej0070_rh850p1x.pdf
Device File:
DF-RH850P1M-EE_V100.zip
Operating Precautions: R01TU0069ED0200_RH850.pdf
Flash Libraries:
RENESAS_FCL_RH850_T01E_V2.00.exe
RENESAS_FDL_RH850_T01E_V2.00.exe
Modules supported: ADC, CAN, DIO, FLS, FLSTST, FR, GPT, ICU, MCU, PORT, PWM,
RAMTST, SPI, WDG.
Page 1 of 42
Renesas Electronics
Release Date: 08/06/2015
1.2 Package information
Product RH850/P1x
Variant P1M
Product Release Version Ver4.00.04
AUTOSAR Specification Version 4.0.3
Device tested on P1M - R7F701310
Devices supported R7F701304
R7F701305
R7F701310
R7F701311
R7F701312
R7F701313
R7F701314
R7F701315
R7F701318
R7F701319
R7F701320
R7F701321
R7F701322
R7F701323
Release Date 08-June-2015
Page 2 of 42
Renesas Electronics
Release Date: 08/06/2015
1.3 Tools
1.3.1 GHS
Tool Version Options GreenHills
Green Hills Multi
-Ospace -g -cpu=rh850g3k -gsize
Multi IDE –
V6.1.4 Compiler
-prepare_dispose -sda=all -passsource
compiler
Version 2013.5.5
-Wundef -no_callt -reserve_r2
+
--short_enum -fsoft --prototype_errors
Patches :
--diag_error 193 -dual_debug -large_sda
P2, P9, P12, P13,
--no_commons -shorten_loads
P14
-shorten_moves -Wshadow -nofloatio
-ignore_callt_state_in_interrupts -delete
-inline_prologue
1.3.2 Configuration code generator
Tool Version Options ECU Spectrum
4.0.14
-
1.3.3 Additional software
Tool Version Options NA
-
-
Page 3 of 42
Renesas Electronics
Release Date: 08/06/2015
1.4 Generic Information
1.4.1 Release Target
Processor P1M - R7F701310
Module Generic
Date 08-June-2015
1.4.2 Release Items
Filename Version Change Description P1x_translation.h
1.0.6
File updated for FLS and CAN macros.
ComStack_Types.h
1.0.1
No change
Std_Types.h
1.0.1
No change
rh850_Types.h
1.0.4
No change
Platform_Types.h
1.0.1
No change
Compiler.h
1.0.3
No change
Compiler_Cfg.h
1.0.5
No change
MemMap.h
1.0.6
No change
NvM_Types.h
1.0.1
No change
Os.h
1.0.1
No change
Os.c
1.0.2
No change
GettingStarted_MCAL_Drivers_X1x.
1.0.5
No change
pdf
AUTOSAR_Modules_Overview.pdf
1.0.7
No change
1.4.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 4 of 42
Renesas Electronics
Release Date: 08/06/2015
1.5 Module Index
ADC CAN DIO FLS FLSTST FR GPT ICU MCU PORT PWM RAMTST SPI WDG Page 5 of 42
Renesas Electronics
Release Date: 08/06/2015
2 ADC
2.1 Target Info
Processor P1M - R7F701310
Module ADC
Date 08-June-2015
2.2 Release Items
Filename Version Change Description P1x- Parameter Definition files R403_ADC_P1M_04_05_12_13_20
1.0.5
As part of Px4 V4.00.04 Release, following changes
_21.arxml
are made
1. As per mantis #24237, Parameter
AdcUseHwContiScanMode is added in AdcGroup container.
2. As per mantis #27411, PDF name is modified.
3. Copyright information is updated.
R403_ADC_P1M_10_11_14_15_18
1.0.6
As part of Px4 V4.00.04 Release, following changes
_19_22_23.arxml
are made
1. As per mantis #24237, Parameter
AdcUseHwContiScanMode is added in AdcGroup container.
2. As per mantis #27411, PDF name is modified.
3. Copyright information is updated.
BSWMDT R403_ADC_P1x_BSWMDT.arxml
1.0.4
As part of P1x V4.00.04 Release, following changes are made:
1. Software version is updated.
2. As per mantis #26305, critical section name
'RAMDATA_PROTECTION' is changed to
'ADC_RAMDATA_PROTECTION'.
3. Copyright information is updated.
Source Code Adc.c
1.7.7
As part of P1x V4.00.04 Release, following changes are made:
1. NULL check is added for 'PtrToSamplePtr' in
Adc_GetStreamLastPointer() API.
2. As per mantis #26305, critical section name
'RAMDATA_PROTECTION' is changed to
'ADC_RAMDATA_PROTECTION'.
3. MISRA violation is updated.
Adc_Irq.c
1.3.4
No change
Page 6 of 42
Renesas Electronics
Release Date: 08/06/2015
Adc_Private_ADCD_ADCB.c
1.0.7
As part of P1x V4.00.04 Release, following changes are made:
1. As per mantis #24936 Redundant compilation switches are
corrected in Adc_GroupCompleteMode() API.
2. As per mantis #25801, 'Track and Hold' implementation is
corrected to match with the flow diagram in the HW User
manual.
3. As per mantis #26305, critical section name
'RAMDATA_PROTECTION' is changed to
'ADC_RAMDATA_PROTECTION'.
4. As per mantis #25842, position of critical section exit is
corrected in Adc_GroupCompleteMode API.
5. As per mantis #24237, software re-triggering is implemented
for continuous conversion for software triggered groups.
6. As per mantis #27488, HW triggered One-shot conversion is
corrected to avoid conversion of more than one stream in one
HW trigger.
7. As per mantis #26324, volatile declaration is added for
variables storing register values.
8. MISRA violation is updated.
9. As per mantis #27334, redundant variables and double
assignments are removed.
10. As per mantis #27186, index calculation of the array
'Adc_GpRunTimeData' is corrected to avoid out of bound
access.
Adc_Ram.c
1.5.3
No change
Adc_Version.c
1.1.3
No change
Adc.h
1.5.5
No change
Adc_Debug.h
1.0.2
No change
Adc_Irq.h
1.0.9
No change
Adc_PBTypes_ADCD_ADCB.h
1.0.5
As part of P1x V4.00.04 Release, following changes are made:
1. As per mantis #25801, 'Track and Hold' implementation is
corrected to match with the flow diagram in the HW Usermanual.
2. As per mantis #26331, element names are corrected in union
'UInt'.
3. As per mantis #26324, volatile declaration is added for
variables storing register values.
Adc_Private.h
1.4.6
As part of P1x V4.00.04 Release, following changes are made:
1. Compiler switches are corrected for the API
Adc_SearchnDelete().
Page 7 of 42
Renesas Electronics
Release Date: 08/06/2015
Adc_Ram.h
1.5.3
No change
Adc_Types.h
1.7.4
No change
Adc_Version.h
1.1.1
No change
Tool Executable Adc_ADCD_ADCB.exe
1.3.2
Tool exe updated for tool code changes.
Adc_ADCD_ADCB.cfgxml
1.0.1
No change
X1x Common Sample Application Source file App_ADC_Common_Sample.c
1.1.9
No change for P1x V4.00.04 release.
X1x Common Sample Application Header file App_ADC_Common_Sample.h
1.0.4
No change for P1x V4.00.04 release.
P1x Sample Application P1M Source file App_ADC_P1M_Sample.c
1.0.1
No change for P1x V4.00.04 release.
P1x Sample Application P1M Header file App_ADC_Device_Sample.h
1.0.2
No change for P1x V4.00.04 release.
P1x User Manual AUTOSAR_ADC_Component_Use
1.0.4
The following changes are done.
rManual.pdf
1. Chapter 2 is updated for reference document.
2. Section 3.1 is updated for folder section.
3. Section 4.1 is updated for usage guidelines.
4. In chapter 13, P1M supported devices are added.
5. Section 13.1 is updated for translation header file and
parameter definition files.
6. Section 13.2 is updated for sample application structure and
building sample application.
7. Section 13.3 is updated for memory and throughput details.
8. Chapter 14 is updated for version of ADC Driver component.
9. Range of ChannelId is corrected in sections 10.3.1 and 10.3.2.
10. Channel Mapping is corrected in section 10.3.3.
11. Table 13-2 is updated for CAT-2 ERROR ISR.
AUTOSAR_ADC_Tool_UserManu
1.0.4
1. Error message ERR123140 is added.
al.pdf
2. Section 2.1 Reference Documents are updated to add PDF
reference.
3. List of mandatory parameters is updated in section 8.1.
2.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 8 of 42
Renesas Electronics
Release Date: 08/06/2015
3 CAN
3.1 Target Info
Processor P1M - R7F701310
Module CAN
Date 08-June-2015
3.2 Release Items
Filename Version Change Description P1x- Parameter Definition files R403_CAN_P1M_04_05_10_to_15.arxml
1.0.4
As part of P1x V4.00.04 release, following changes are
made.
1. As per mantis #27411, renamed file.
2. Updated File version and copyright information.
3. As per mantis #24428, added a parameter
'CanWakeupFunctionalityAPI' under CanGeneral
container.
R403_CAN_P1M_18_to_23.arxml
1.0.2
As part of P1x V4.00.04 release, following changes are
made.
1. As per mantis #27411, renamed file.
2. Updated File version and copyright information.
3. As per mantis #24428, added a parameter
'CanWakeupFunctionalityAPI' under CanGeneral
container.
BSWMDT R403_CAN_P1x_BSWMDT.arxml
1.0.4
As part of V4.00.04 P1x release, following changes are
made
1. Device Support Added for R7F701304, R7F701305,
R7F701313, R7F701318, R7F701319, R7F701320,
R7F701321, R7F701322, and R7F701323.
2. Software version information is updated.
3. Copyright information is updated.
Source Code Can.c
1.2.12
As part of P1x V4.00.04 release, following changes are
made,
1. As per mantis #27644,
RH850_SV_MODE_IMR_WRITE_ONLY (16,
LpWupIntMaskReg, (LpPCController->usWupIntMask));
is changed to RH850_SV_MODE_IMR_AND (16,
Page 9 of 42
Renesas Electronics
Release Date: 08/06/2015
LpWupIntMaskReg, (LpPCController->usWupIntMask));
for the proper masking of IMR register.
Can_Int.c
1.1.6
No change
Can_Irq.c
1.1.8
No change
Can_MainServ.c
1.2.8
No change
Can_ModeCntrl.c
1.2.9
No change
Can_Ram.c
1.1.2
No change
Can_RamTest.c
1.0.4
No change
Can_Version.c
1.0.6
No change
Can_Wakeup.c
1.0.14
As part of P1x V4.00.04 release, Following change is
made
1. Access to Can_CheckWakeup() API is made under the
compiler switch condition
#if(CAN_CHECKWAKEUP_API == STD_ON).
Can_Write.c
1.0.17
No change
Can_Wakeup_Int.c
1.0.1
As part of P1x V4.00.04 release, following changes are
made,
1. As per mantis #27642, removed unused parameter
'LucController' from 'CanEnableWakeUp' function
definition.
2. As per mantis #27641, 'DNFA2EN' register handling
modified.
Can.h
1.0.11
No change
Can_Debug.h
1.0.3
No change
Can_Init.h
1.0.2
No change
Can_Int.h
1.0.2
No change
Can_Irq.h
1.0.8
No change
Can_MainServ.h
1.0.3
No change
Can_ModeCntrl.h
1.0.5
No change
Can_PBTypes.h
1.0.9
No change
Can_PCTypes.h
1.0.11
No change
Can_Ram.h
1.0.6
No change
Can_RamTest.h
1.0.3
No change
Can_RegStruct.h
1.0.3
No change
Can_Tgt.h
1.0.12
No change
Can_Types.h
1.0.9
No change
Can_Version.h
1.0.7
No change
Can_Wakeup.h
1.0.5
As part of P1x V4.00.04 release, Following change is
made
Page 10 of 42
Renesas Electronics
Release Date: 08/06/2015
1. Can_CheckWakeup() API is made under the compiler
switch condition #if(CAN_CHECKWAKEUP_API ==
STD_ON).
Can_Write.h
1.0.3
No change
Tool Executable Can_X1x.exe
1.2.11
As per mantis #24579 and #24428 BswConfigValidate.pm,
BswIm.pm, BswHdr.pm, BswConfig.pm are updated.
Can_X1x.cfgxml
1.0.0
No Change
X1x Sample Application Source file App_CAN_Common_Sample.c
1.0.11
As part of P1x V4.00.04 release, Following change
is made
1. Can_CheckWakeup() call is made under pre compiler
switch #if(CAN_CHECKWAKEUP_API == STD_ON).
X1x Sample Application header file App_CAN_Common_Sample.h
1.0.2
No change
P1x Sample Application P1M Source file App_CAN_P1M_Sample.c
1.0.1
No change
P1x Sample Application P1M header file App_CAN_Device_Sample.h
1.0.0
No change
P1x User Manual AUTOSAR_CAN_Component_UserMa
1.0.3
Following changes are made.
nual.pdf
1. Updated ‘Chapter 2 Reference Documents’.
2. Added a ‘Note’ in Chapter 4 , Forethoughts.
3. Chapter 13 is updated for adding new devices support.
4. Chapter 14 is updated for Release Details.
5. Section 13.3 is updated with Memory, Stack Usage and
Throughput details for 144 pin device 701310.
6. Added ISR Throughput details in section 13.3.
7. Chapter 13, section 13.2 compiler, linker, and assembler
options removed.
AUTOSAR_CAN_Tool_UserManual.pdf
1.0.2
Following change is made
1. Updated ‘Section 2.1 Reference documents’.
2. In Section 8.1, ERR080075 to ERR080080 are added.
3. In Section 8.3, INF080007 to INF080010 are added.
3.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 11 of 42
Renesas Electronics
Release Date: 08/06/2015
4 DIO
4.1 Target Info
Processor P1M - R7F701310
Module DIO
Date 08-June-2015
4.2 Release Items
Filename Version Change Description P1x- Parameter Definition files R403_DIO_P1M_04_05_12_13_20_
1.0.3
Following changes are made :
21.arxml
1. File renamed from R403_DIO_P1M_701304_701305_
701312_701313_701320_701321.arxml to
R403_DIO_P1M_04_05_12_13_20_21.arxml as per mantis
#27411.
2. Parameter DioPortName is updated with portgroups
pin information
R403_DIO_P1M_10_11_14_15_18_
1.0.4
Following changes are made:
19_22_23.arxml
1. File is renamed from R403_DIO_P1M_701310_701311_
701314_701315_701318_701319_701322_701323.arxml to
R403_DIO_P1M_10_11_14_15_18_19_22_23.arxml as per
mantis #27411.
BSWMDT R403_DIO_P1x_BSWMDT.arxml
1.0.4
Following changes are made:
1. Environment section is updated for new devices.
2. Copyright information is updated.
Source Code Dio.c
1.0.21
No change
Dio_Ram.c
1.0.7
No change
Dio_Version.c
1.0.6
No change
Dio.h
1.0.11
No change
Dio_Debug.h
1.0.3
No change
Dio_LTTypes.h
1.0.14
No change
Dio_PBTypes.h
1.0.12
No change
Dio_Ram.h
1.0.10
No change
Dio_Version.h
1.0.8
No change
Tool Executable Dio_X1x.exe
1.0.16
No change
Dio_X1x.cfgxml
1.0.1
No change
Page 12 of 42
Renesas Electronics
Release Date: 08/06/2015
P1x Sample Application P1M Source file App_DIO_P1M_Sample.c
1.0.4
No change
P1x Sample Application P1M header file App_DIO_Device_Sample.h
1.0.4
Following changes are made:
1. Updated to support new devices 701318, 701319, 701320,
701321, 701322, 701323
2. Copyright information is updated.
P1x User Manual AUTOSAR_DIO_Component_User
1.0.6
Following changes are made:
Manual.pdf
1. Chapter 2 reference documents section is updated.
2. Chapter 3 section 3.1.1 is updated for new devices.
3. Chapter 4 section 4.1 General is updated and a note is added
regarding interrupt vector (.c) file
4. Chapter 13
13.1.1 Translation header files section is updated as per new
devices.
13.1.2 PDF section is updated as per new devices.
13.3.1 Sample application structure is updated for new devices
13.3.2 Building sample application section is updated
13.4 Memory and throughput details are updated for 144 pin
devices.
AUTOSAR_DIO_Tool_UserManual
1.0.2
Section 2.1 Reference documents section is updated with the
.pdf
parameter definition file names.
4.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 13 of 42
Renesas Electronics
Release Date: 08/06/2015
5 FLS
5.1 Target Info
Processor P1M - R7F701310
Module FLS
Date 08-June-2015
5.2 Release Items
Filename Version Change Description P1x- Parameter Definition files R403_FLS_P1M_04_05.arxml
1.1.1
As part of P1x V4.00.04 Release,
1. As per mantis #24538, parameter 'FlsCancelTime'
is added in FlsPublishedInformation container.
2. As per mantis #24538, parameter 'FlsCFCancelTime' is added
in FlsCodeFlash container.
3. As per mantis #23970, description of parameters
'FlsEraseTime', 'FlsWriteTime', 'FlsBlankCheckTime' and
'FlsReadTime' are updated.
4. As per mantis #27411, filename is updated.
5. Updated file version and copyright information.
R403_FLS_P1M_10_to_15.arxml
1.1.1
As part of P1x V4.00.04 Release,
1. As per mantis #24538, parameter 'FlsCancelTime' is added in
FlsPublishedInformation container.
2. As per mantis #24538, parameter 'FlsCFCancelTime'
is added in FlsCodeFlash container.
3. As per mantis #23970, description of parameters
'FlsEraseTime', 'FlsWriteTime', 'FlsBlankCheckTime' and
'FlsReadTime' are updated.
4. As per mantis #27411, filename is updated.
5. Updated file version and copyright information.
R403_FLS_P1M_18_to_23.arxml
1.0.1
As part of P1x V4.00.04 Release,
1. As per mantis #24538, parameter 'FlsCancelTime' is added in
FlsPublishedInformation container.
2. As per mantis #24538, parameter 'FlsCFCancelTime'
is added in FlsCodeFlash container.
3. As per mantis #23970, description of parameters
'FlsEraseTime', 'FlsWriteTime', 'FlsBlankCheckTime' and
'FlsReadTime' are updated.
Page 14 of 42
Renesas Electronics
Release Date: 08/06/2015
4. As per mantis #27411, filename is updated.
5. Updated file version and copyright information.
BSWMDT R403_FLS_P1x_BSWMDT.arxml
1.0.4
As part of P1x V4.00.04 release, following changes are made:
1. Updated software version.
2. Updated file version and copyright information.
Source Code Fls.c
1.3.9
As part of P1x V4.00.04 release, following changes are made:
1. As per mantis #28186, section
DRIVERSTATE_DATA_PROTECTION is renamed to
FLS_DRIVERSTATE_DATA_PROTECTION.
2. Updated file version.
Fls_Irq.c
1.0.2
No change
Fls_Internal.c
1.3.6
No change
Fls_Ram.c
1.2.5
No change
Fls_Version.c
1.1.0
No change
Fls.h
1.3.5
No change
Fls_Debug.h
1.0.1
No change
Fls_Internal.h
1.3.2
No change
Fls_Irq.h
1.0.1
No change
Fls_PBTypes.h
1.5.3
No change
Fls_Ram.h
1.2.5
No change
Fls_Types.h
1.3.5
No change
Fls_Version.h
1.1.1
No change
Tool Executable Fls_X1x.exe
1.3.6
No change
Fls_X1x.cfgxml
1.0.0
No change
X1x Sample Application source file App_FLS_Common_Sample.c
1.1.9
No change
X1x Sample Application header file App_FLS_Common_Sample.h
1.0.2
No change
P1x Sample Application P1M Source file App_FLS_P1M_Sample.c
1.0.0
No change
P1x Sample Application P1M header file App_FLS_Device_Sample.h
1.0.1
No change
P1x User Manual AUTOSAR_FLS_Component_User
1.0.5
The following changes are made:
Manual.pdf
1. Chapter 2: Reference document is updated
Page 15 of 42
Renesas Electronics
Release Date: 08/06/2015
2. As part of device support activity for R7F701304,
R7F701305, R7F701313, R7F701315, R7F701318 to
R7F701323 updated sections 3.1.1, 13.1.1, 13.1.2, 13.3.1.
3. Updated version number and copyright year.
4. Updated section 13.4 for memory and throughput.
5. Removed section Compiler, Linker and Assembler in
Chapter13.
6. Removed Test_Application_P1x.trxml path from Section
3.1.1.
7. Section 4.1 is updated for adding note in Forethoughts.
8. Chapter 12 is updated.
9. Section 4.2. Preconditions is updated.
10. Updated Tables 4-2 and 4-3 in Section 4.5.
11. Chapter 14: Release Detail is updated for FLS Driver
Version
AUTOSAR_FLS_Tool_UserManual
1.0.3
The following changes are made:
.pdf
• Pdf name and version are updated in Section 2.1
• Added parameters FlsCancelTime and FlsCFCancelTime in the
list of mandatory parameters in Section 8.1.
• The description of error ERR092029 is updated in Section 8.1.
• Updated version number and copyright year.
5.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 16 of 42
Renesas Electronics
Release Date: 08/06/2015
6 FLSTST
6.1 Target Info
Processor P1M - R7F701310
Module FLSTST
Date 08-June-2015
6.2 Release Items
Filename Version Change Description P1x- Parameter Definition files R403_FLSTST_P1M_04_05.arxml
1.0.3
As part of P1x V4.00.04 development activity the following
changes are made:
1. As per mantis #27411, file name changed to
R403_FLSTST_P1M_04_05.arxml
2. Copyright information updated.
3. ADMIN-DATA updated.
R403_FLSTST_P1M_10_to_15.arx
1.0.3
As part of P1x V4.00.04 development activity the following
ml
changes are made:
1. As per mantis #27411, file name changed to
R403_FLSTST_P1M_10_to_15.arxml
2. Copyright information updated.
3. ADMIN-DATA updated.
R403_FLSTST_P1M_18_to_23.arx
1.0.1
As part of P1x V4.00.04 development activity the
ml
following changes are made:
1. As per mantis #27411, file name changed to
R403_FLSTST_P1M_18_to_23.arxml
2. Copyright information updated.
3. ADMIN-DATA updated.
BSWMDT R403_FLSTST_P1x_BSWMDT.arx
1.0.3
As part of P1x V4.00.04 development activity the
ml
following changes are made:
1. Environment section updated to add device
support
2. Copyright information updated.
Source Code FlsTst.c
1.0.6
No change
FlsTst_Ram.c
1.0.3
No change
FlsTst_Version.c
1.0.1
No change
Page 17 of 42
Renesas Electronics
Release Date: 08/06/2015
FlsTst.h
1.0.4
No change
FlsTst_Debug.h
1.0.0
No change
FlsTst_PBTypes.h
1.0.3
No change
FlsTst_Ram.h
1.0.4
No change
FlsTst_Types.h
1.0.2
No change
FlsTst_Version.h
1.0.0
No change
Tool Executable FlsTst_X1x.exe
1.0.4
No change
FlsTst_X1x.cfgxml
1.0.0
No change
X1x Sample Application source file App_FLSTST_Common_Sample.c
1.0.1
No change
X1x Common Sample Application header file App_FLSTST_Common_Sample.h
1.0.0
No change
P1x Sample Application P1M Source file App_FLSTST_P1M_Sample.c
1.0.0
No change
P1x Sample Application P1M header file App_FLSTST_Device_Sample.h
1.0.1
No change
P1x User Manual AUTOSAR_FLSTST_Component_
1.0.5
As part of P1x V4.00.04 following changes are
UserManual.pdf
made:
1. Section 4.1 is updated by adding forethought
2. Section 13.2 for compiler, linker and assembler
options is removed
3. Sections 13.3.1, Section 13.3.2, Section 13.3.3 are
updated with RAM/ROM details and throughput
details
4. Section 13 and Section 13.1.1 are updated by
adding the new devices supported by the translation
header
5. Section 13.1.2 is updated with the renamed pdf
files used
6. Section 13.2.1 is updated by adding the sample
applications added for the new devices
7. Section 13.2.2 is updated by adding the new
devices supported.
AUTOSAR_FLSTST_SA_Test_Pro
1.0.1
No change.
cedure.pdf
AUTOSAR_FLSTST_Tool_UserMa
1.0.3
As part of P1x 4.00.04 the following changes are
nual.pdf
made:
Page 18 of 42
Renesas Electronics
Release Date: 08/06/2015
Reference documents section is updated.
6.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 19 of 42
Renesas Electronics
Release Date: 08/06/2015
7 FR
7.1 Target Info
Processor P1M - R7F701310
Module FR
Date 08-June-2015
7.2 Release Items
Filename Version Change Description P1x- Parameter Definition files R403_FR_P1M_04_05_10_to_15_1
1.0.4
As per the PRD,
8_to_23.arxml
1. Devices R7F701318, R7F701319, R7F701320, R7F701321,
R7F701322 and R7F701323 are added in 'FrDeviceName'
parameter and in environment section and devices which are not in
scope is removed.
2. As per Mantis #27411, The file name has been changed to
R403_FR_P1M_04_05_10_to_15_18_to_23 from
R403_FR_P1M_701300_701301_701304_701305_701308_to_7
01323
3. As per Mantis #27728, Max, Min and default value of following
parameters FrOutputPtrTableAddress, FrFifoPtrTableAddress
and FrInputPtrTableAddress are modified.
BSWMDT R403_Fr_P1x_BSWMDT.arxml
1.0.2
As part of P1x V4.00.04 Maintenance activity,
1. Software version information is updated.
2. Module ID is Changed to 81
3. Environment Section is updated to add all
Supported devices of P1M.
Source Code Fr_59.c
1.0.4
No change
Fr_59_Internal.c
1.0.4
No change
Fr_59_Version.c
1.0.1
No change
Fr_59_Ram.c
1.0.2
No change
Fr_59_Debug.h
1.0.1
No change
Fr_59_GeneralTypes.h
1.0.1
No change
Fr_59_Internal.h
1.0.3
As part of P1x_V4.00.04 maintenance activity, As per mantis
#27460, following API's are declared as extern.
1. Fr_Input_Queue_Halt(), Fr_User_Request_Input_Transfer(),
Fr_User_Request_Output_Transfer.
Page 20 of 42
Renesas Electronics
Release Date: 08/06/2015
Fr_59_PBTypes.h
1.0.3
No change
Fr_59_Ram.h
1.0.2
No change
Fr_59_Types.h
1.0.1
No change
Fr_59_Version.h
1.0.1
No change
Fr_59.h
1.0.3
No change
Tool Executable Fr_X1x.exe
1.0.4
No change
Fr_X1x.cfgxml
1.0.0
Initial Version.
X1x Common Sample Application Source file for node1 App_FR_Common_Sample.c
1.0.1
No change
X1x Common Sample Application Source file for node2 App_FR_Common_Sample.c
1.0.1
No change
X1x Common Sample Application header file for node1 App_FR_Common_Sample.h
1.0.1
No change
X1x Common Sample Application header file for node2 App_FR_Common_Sample.h
1.0.1
No change
P1x Sample Application P1M Source file for node1 App_FR_P1M_Sample.c
1.0.2
No change
P1x Sample Application P1M Source file for node2 App_FR_P1M_Sample.c
1.0.2
No change
P1x Sample Application P1M header file for node1 App_FR_Device_Sample.h
1.0.2
No change
P1x Sample Application P1M header file for node2 App_FR_Device_Sample.h
1.0.2
No change
P1x User Manual AUTOSAR_FR_Component_User
1.0.3
Following changes are made:
Manual.pdf
1. Chapter 2 Reference Documents updated.
2. Chapter 1, 8, 12 and Sections 3.1.1, 4.2, 4.5, 10.3, 13.2.1,
13.3.3 Updated the file names by adding vender id.
3. Section 13.2.1. Sample Application Structure updated by
adding the sample application configuration for supported
devices.
4. Memory and Throughput details updated in section 13.2.
5. Chapter 14 Release Details updated.
6. Copyright information updated.
7. Removed Compiler and Linker options.
AUTOSAR_FR_Tool_UserManual.
1.0.4
Following changes are made:
pdf
1. File names of Fr_PBcfg.c and Fr_Cfg.h renamed to
Fr_59_PBcfg.c and Fr_59_Cfg.h.
Page 21 of 42
Renesas Electronics
Release Date: 08/06/2015
2. Copyright information updated
7.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 22 of 42
Renesas Electronics
Release Date: 08/06/2015
8 GPT
8.1 Target Info
Processor P1M - R7F701310
Module GPT
Date 08-June-2015
8.2 Release Items
Filename Version Change Description P1x- Parameter Definition files R403_GPT_P1M_04_05_12_13_20_21.arx
1.0.1
As part of P1x V4.00.04 development activity the
ml
following changes are made:
1. As per mantis #27411, file name changed
to
R403_GPT_P1M_04_05_12_13_20_21.ar
xml
2. Copyright information updated.
3. ADMIN-DATA updated.
R403_GPT_P1M_10_11_14_15_18_19_22_
1.0.6
As part of P1x V4.00.04 development
23.arxml
activity the
following changes are made:
1. As per mantis #27411, file name changed
to
R403_GPT_P1M_10_11_14_15_18_19_2
2_23.arxml
2. Copyright information updated.
3. ADMIN-DATA updated.
BSWMDT R403_GPT_P1x_BSWMDT.arxml
1.0.4
No change
Source Code Gpt.c
1.0.17
No change
Gpt_Irq.c
1.0.8
No change
Gpt_LLDriver.c
1.0.19
No change
Gpt_Ram.c
1.0.4
No change
Gpt_Version.c
1.0.3
No change
Gpt.h
1.0.5
No change
Gpt_Debug.h
1.0.3
No change
Gpt_Irq.h
1.0.7
No change
Gpt_LLDriver.h
1.0.5
No change
Page 23 of 42
Renesas Electronics
Release Date: 08/06/2015
Gpt_PBTypes.h
1.0.14
No change
Gpt_Ram.h
1.0.4
No change
Gpt_RegReadBack.h
1.0.1
No change
Gpt_Types.h
1.0.5
No change
Gpt_Version.h
1.0.4
No change
Tool Executable Gpt_X1x.exe
1.1.6
No change
Gpt_X1x.cfgxml
1.0.0
No change
X1x Common Sample Application Source file App_GPT_Common_Sample.c
1.0.5
No change
X1x Common Sample Application header file App_GPT_Common_Sample.h
1.0.3
No change
P1x Sample Application P1M Source file App_GPT_P1M_Sample.c
1.0.1
No change
P1x Sample Application P1M header file App_GPT_Device_Sample.h
1.0.1
No change
P1x User Manual AUTOSAR_GPT_Component_UserManua
1.0.5
Following changes are made:
l.pdf
1. Added note in chapter4 Forethoughts.
2. Removed Compiler Assembler and linker option.
3. Updated copyright information.
4. Updated chapter 13 to add additional device support.
5. Updated throughput and memory details.
AUTOSAR_GPT_Tool_UserManual.pdf
1.0.5
Following changes are made:
• Updated copyright information.
• Updated reference section with new PDF name.
8.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 24 of 42
Renesas Electronics
Release Date: 08/06/2015
9 ICU
9.1 Target Info
Processor P1M - R7F701310
Module ICU
Date 08-June-2015
9.2 Release Items
Filename Version Change Description P1x- Parameter Definition files R403_ICU_P1M_04_05_12_13_20
1.0.1
As per mantis issue #27411, following changes has been
_21.arxml
made:
1. PDF renamed as
R403_ICU_P1M_04_05_12_13_20_21.arxml
2. Copyright information is updated.
R403_ICU_P1M_10_11_14_15_18
1.1.2
As per mantis issue #27411, following changes has been
_19_22_23.arxml
made:
1. PDF renamed as
R403_ICU_P1M_04_05_12_13_20_21.arxml
2. Copyright information is updated.
BSWMDT File R403_ICU_P1x_BSWMDT.arxml
1.0.2
No change
Source Code Icu.c
1.5.5
No change
Icu_Irq.c
1.2.0
No change
Icu_LLDriver.c
1.6.6
No change
Icu_Ram.c
1.1.4
No change
Icu_Version.c
1.0.4
No change
Icu.h
1.4.4
No change
Icu_Debug.h
1.0.1
No change
Icu_Irq.h
1.1.1
No change
Icu_LLDriver.h
1.3.4
No change
Icu_PBTypes.h
1.5.5
No change
Icu_Ram.h
1.1.4
No change
Icu_Types.h
1.1.2
No change
Icu_Version.h
1.0.3
No change
Tool Executable Icu_X1x.exe
1.4.6
No change
Page 25 of 42
Renesas Electronics
Release Date: 08/06/2015
Icu_P1x.cfgxml
1.0.0
No change
X1x Common Sample Application Source file App_ICU_Common_Sample.c
1.3.4
No change
P1x Sample Application Source file App_ICU_P1M_Sample.c
1.0.4
As a part of P1x V4.00.04 release corrected
Port_Init() for Device 701310.
X1x Common Sample Application Header file App_ICU_Common_Sample.h
1.0.2
No change
P1x Sample Application Header file App_ICU_Device_Sample.h
1.0.0
No change
P1x User Manual AUTOSAR_ICU_Component_User
1.0.7
Following changes are made:
Manual.pdf
1. Chapter 2 Reference documents are updated for version
change.
2. Chapter 4 is updated for information regarding Interrupt
vector table.
3. Section 13.1.1 is updated for adding new devices.
4. Section 13.1.1 is updated for names of PDF.
5. Section 13.2 Compiler, Linker and Assembler section is
removed.
6. Section 13.2 is updated for parameter definition file and
sample application configuration files of all P1M devices.
7. Section 13.3 Memory and Throughput details are updated
AUTOSAR_ICU_Tool_UserManual
1.0.4
Following changes are made:
.pdf
Parameter definition file names and versions are updated in
section 2.1.
9.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 26 of 42
Renesas Electronics
Release Date: 08/06/2015
10 MCU
10.1 Target Info
Processor P1M - R7F701310
Module MCU
Date 08-June-2015
10.2 Release Items
Filename Version Change Description P1x- Parameter Definition files R403_MCU_P1M_04_05.arxml
1.1.4
1. As per Mantis #26418, Description of "McuResetReason"
parameter is to
"The parameter represents the different type of reset that a Micro
supports. This parameter is referenced by the parameter
EcuMResetReason in the ECU State manager module,
MCU_SW_RESET."
2. As per Mantis #27411, The file name has been changed to
R403_MCU_P1M_04_05 from
R403_MCU_P1M_701304_701305
3. Local RAM range corrected to 4273864704 to 4273995775
R403_MCU_P1M_10_to_15_18_to_
1.0.1
1. As per Mantis #26418, Description of "McuResetReason"
23.arxml
parameter is to
"The parameter represents the different type of reset that a
Micro supports. This parameter is referenced by the parameter
EcuMResetReason in the ECU State manager module,
MCU_SW_RESET."
2. As per Mantis #27411, The file name has been changed to
R403_MCU_P1M_10_to_15_18_to_23 from
R403_MCU_P1M_701310_to_701315_7013018_to_7013023.
BSWMDT R403_MCU_P1x_BSWMDT.arxml
1.0.5
Updated SW-VERSION for changes in Source code
Source Code Mcu.c
1.0.6
1. As per mantis #26418 ,following change is made:
MCU_SW_RST is corrected with name MCU_SW_RESET ,
MCU_WDT_RST is corrected with name
MCU_WATCHDOG_RESET,
MCU_POWER_ON_CLEAR_RST is corrected with name
MCU_POWER_ON_RESET
2. Added code comments as per MO Review in Mantis
Page 27 of 42
Renesas Electronics
Release Date: 08/06/2015
#27515
3. Justifications for QAC warnings Msg(4:0857), Msg(4:2983),
Msg(4:4499), Msg(4:2991), Msg(4:2982),
Msg(4:2992), Msg(4:2996), Msg(4:0400).
Mcu_Irq.c
1.0.6
1. Added code comments as per MO Review in Mantis
#27515
2. Added justification for MISRA warning Msg(4:3138)
3. Added compiler switch, #ifndef
Os_MCU_FEINT_CAT2_ISR and #ifndef
MCU_FEINT_CAT2_ISR for MCU_FENMI_ENTRY and
MCU_FENMI_LEAVE as per mantis #27723
Mcu_Ram.c
1.0.4
Added code comments as per MO Review in Mantis #27515
Mcu_Version.c
1.0.2
No changes
Mcu.h
1.0.3
1. Added code comments as per MO Review in Mantis #27515
2. Added Justification for MISRA Violation:
START Msg(4:3412)
Mcu_Debug.h
1.0.2
Added code comments as per MO Review in Mantis
#27515
Mcu_Irq.h
1.0.2
1.Added code comments as per MO Review in Mantis #27515
2.Removed _Interrupt_ from MCU_FEINT_ISR
Mcu_PBTypes.h
1.0.4
Added code comments as per MO Review in Mantis #27515
Mcu_Ram.h
1.0.4
Added code comments as per MO Review in Mantis #27515
Mcu_Types.h
1.0.4
1.As per mantis #26418 ,following change is made:
MCU_SW_RST is corrected with name MCU_SW_RESET ,
MCU_WDT_RST is corrected with name
MCU_WATCHDOG_RESET ,
MCU_POWER_ON_CLEAR_RST is corrected with name
MCU_POWER_ON_RESET
2. Added code comments as per MO Review in Mantis #27515
Mcu_Version.h
1.0.1
Added code comments as per MO Review in Mantis #27515
Tool Executable Mcu_P1x.exe
1.1.1
Updated for Ver4.0004 release
Mcu_P1x.cfgxml
1.0.0
No change
P1x Sample Application P1M Source file App_MCU_P1M_Sample.c
1.0.3
As per mantis #27723, the following change is made,
1. Removed #pragma intvect MCU_FEINT_ISR 0x000000E0.
P1x Sample Application P1M header file App_MCU_Device_Sample.h
1.0.2
No change
Page 28 of 42
Renesas Electronics
Release Date: 08/06/2015
P1x User Manual AUTOSAR_MCU_Component_Use
1.0.5
Following changes are made:
rManual.pdf
1. New section, “4.7 Callout API” added to chapter 4.
2. Information regarding Interrupt vector table is added to
“Section 4.1 General”.
3. As part of device support activity for R7F701304, R7F701305,
R7F701313, R7F701315, R7F701318 to R7F701323 updated
sections 3.1.1, 13.1, 13.2.
4. Removed section Compiler,Linker and Assembler in
Chapter13.
5. Updated section 13.3 for memory and throughput
6. Copyright information has been changed to 2015
AUTOSAR_MCU_Tool_UserManu
1.0.3
The following changes are made:
al.pdf
• Pdf name and version are updated in Section 2.1
• Updated version and copyright year.
10.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 29 of 42
Renesas Electronics
Release Date: 08/06/2015
11 PORT
11.1 Target Info
Processor P1M - R7F701310
Module PORT
Date 08-June-2015
11.2 Release Items
Filename Version Change Description P1x- Parameter Definition files R403_PORT_P1M_04_05.arxml
1.0.1
As per mantis 27411,27777,26630 following changes
are made
1. File name changed to R403_PORT_P1M_04_05.arxml
from R403_PORT_P1M_701304_701305.arxml
2. Copyright information is updated.
3. Parameter 'PortIpControl' is removed from
PortGroup0,PortGroup2 PortPin4,PortGroup3
PortPin11,14,PortGroup4 PortPin2-4 and PortGroup5
PortPin5-14
4. Parameters 'PortInputSelection', 'PortUnlimitedCurrentControl',
'PortDriveStrengthControl' and
'PortOpenDrainControl_Expansion' are removed from PortPin4 of
PortGroupJtag0.
R403_PORT_P1M_10_11_14_15.ar
1.0.4
As per mantis 27411,27777,26630 following changes are made:
xml
1. File name changed from
R403_PORT_P1M_701310_701311_701314_701315.arxml
to R403_PORT_P1M_10_11_14_15.arxml.
2. Copyright information is updated.
3. Parameter 'PortInputSelection' is removed from
PortPin0 of PortGroup0 and PortPin4 of PortGroupJtag0.
4. Parameters 'PortInputSelection', 'PortUnlimitedCurrentControl',
'PortDriveStrengthControl' and
'PortOpenDrainControl_Expansion' are removed from PortPin4 of
PortGroupJtag0
5. Parameter 'PortIpControl' is removed from
PortGroup0,PortGroup3 PortPin11,14, PortGroup4 PortPin2-4
and PortGroup5 PortPin5-15.
R403_PORT_P1M_12_13.arxml
1.0.2
As per mantis 27411,27777,26630 following changes are made:
1. File name changed from
Page 30 of 42
Renesas Electronics
Release Date: 08/06/2015
R403_PORT_P1M_701312_701313.arxml to
R403_PORT_P1M_12_13.arxml
2. Copyright information is updated.
3. Parameter 'PortIpControl' is removed from
PortGroup0,PortGroup1 PortPin1,PortGroup3
PortPin11,14,PortGroup4 PortPin2-4 and PortGroup5
PortPin0,5-14.
4. Parameter 'PortInputSelection' is removed from
PortGroup2 PortPin3,6,8,PortGroup3 PortPin3
5. Parameters 'PortInputSelection', 'PortUnlimitedCurrentControl',
'PortDriveStrengthControl' and
'PortOpenDrainControl_Expansion' are removed from
PortPin4 of PortGroupJtag0.
R403_PORT_P1M_18_19_22_23.ar
1.0.1
As per mantis 27411,27777,26630 following changes are made:
xml
1. File name changed from
R403_PORT_P1M_701318_701319_701322_701323.arxml to
R403_PORT_P1M_18_19_22_23.arxml.
2. Copyright information is updated.
3. Parameters 'PortInputSelection',
'PortUnlimitedCurrentControl', 'PortDriveStrengthControl' and
'PortOpenDrainControl_Expansion' are removed from PortPin4 of
PortGroupJtag0
4. Parameter 'PortIpControl' is removed from
PortGroup0,PortGroup3 PortPin5,11,14, PortGroup4 PortPin2-4
and PortGroup5 PortPin5-14
R403_PORT_P1M_20_21.arxml
1.0.1
As per mantis 27411,27777,26630 following changes
are made:
1. File name changed from
R403_PORT_P1M_701320_701321.arxml to
R403_PORT_P1M_20_21.arxml.
2. Copyright information is updated.
3. Parameter 'PortIpControl' is removed from
PortGroup0,PortGroup2 PortPin0,PortGroup3
PortPin11,14,PortGroup4 PortPin2-4 and PortGroup5 PortPin5-14
4. Parameter 'PortInputSelection' is removed from PortGroup0
PortPin10,PortGroup3 PortPin13.
5. Parameters 'PortInputSelection', 'PortUnlimitedCurrentControl',
'PortDriveStrengthControl' and
'PortOpenDrainControl_Expansion' are removed from
PortPin4 of PortGroupJtag0.
Page 31 of 42
Renesas Electronics
Release Date: 08/06/2015
BSWMDT R403_PORT_P1x_BSWMDT.arxml
1.0.3
As per mantis #27419 following changes are made:
1. Environment section is updated to add P1x devices
2. Copyright information is updated.
Source Code Port.c
1.5.9
No change
Port_Ram.c
1.0.3
No change
Port_Version.c
1.0.2
No change
Port.h
1.5.3
No change
Port_Debug.h
1.0.1
No change
Port_Types.h
1.3.1
No change
Port_PBTypes.h
1.4.7
No change
Port_Ram.h
1.0.1
No change
Port_Version.h
1.0.5
No change
Tool Executable Port_X1x.exe
1.3.12
Tool updated for P1x Ver4.00.04 release.
Port_X1x.cfgxml
1.0.0
No change
P1x Sample Application P1M Source file App_PORT_P1M_Sample.c
1.0.4
No change
P1x Sample Application P1M header file App_PORT_Device_Sample.h
1.0.1
No change
P1x User Manual AUTOSAR_PORT_Component_Us
1.0.5
Following changes are made:
erManual.pdf
1. Section 1.1 Document Overview is updated.
2. Chapter 2 Reference documents are updated for version change.
3. Chapter 4 is updated for information regarding Interrupt vector
table.
4. Chapter 6 Port_SetPinMode is updated.
5. Section 10.2.4 Port_PinModeType is updated.
6. Section 13.1.1 is updated for adding new devices.
7. Section 13.2 Compiler, Linker and Assembler section is
removed.
8. Section 13.2 is updated for parameter definition file and sample
application configuration files of all P1M devices.
9. Section 13.3 Memory and Throughput details are updated.
AUTOSAR_PORT_Tool_UserManu
1.0.5
Following changes are made:
al.pdf
1. Parameter Definition file names and versions are updated in
section 2.1.
Page 32 of 42
Renesas Electronics
Release Date: 08/06/2015
2. Error message ERR124018 is added in section 8.1.
11.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 33 of 42
Renesas Electronics
Release Date: 08/06/2015
12 PWM
12.1 Target Info
Processor P1M - R7F701310
Module PWM
Date 08-June-2015
12.2 Release Items
Filename Version Change Description P1x Parameter Definition file R403_PWM_P1M_04_05_12_13_2
1.0.1
As part of P1x V4.00.04 Maintenance Activity, the following
0_21.arxml
changes are done.
1. As per mantis #27411, the file names are changed and file
version is updated.
2. Copyright information is updated.
3. Admin Data is updated.
R403_PWM_P1M_10_11_14_15_1
1.0.3
As part of P1x V4.00.04 Maintenance Activity,the following
8_19_22_23.arxml
changes are done.
1. As per mantis #27411, the file names are changed and file
version is updated.
2. Copyright information is updated.
3. Admin Data is updated.
BSWMDT File R403_PWM_P1x_BSWMDT.arxml
1.0.3
No change
Source Code Pwm.c
1.6.7
No change
Pwm_Irq.c
1.2.1
No change
Pwm_LLDriver.c
1.6.9
No change
Pwm_Ram.c
1.3.8
No change
Pwm_Version.c
1.0.4
No change
Pwm.h
1.4.6
No change
Pwm_Debug.h
1.0.1
No change
Pwm_Irq.h
1.2.0
No change
Pwm_LLDriver.h
1.4.4
No change
Pwm_PBTypes.h
1.4.9
No change
Pwm_Ram.h
1.3.8
No change
Pwm_Types.h
1.5.5
No change
Pwm_Version.h
1.0.5
No change
Page 34 of 42
Renesas Electronics
Release Date: 08/06/2015
Tool Executable PWM_X1x.exe
1.6.5
No change
Pwm_X1x.cfgxml
1.0.0
No change
X1x Sample Application Source file App_PWM_Common_Sample.c
1.4.4
No change
X1x Sample Application header file App_PWM_Common_Sample.h
1.0.3
No change
P1x Sample Application P1M Source file App_PWM_P1M_Sample.c
1.0.3
No change
P1x Sample Application P1M Header file App_PWM_Device_Sample.h
1.0.1
No change
P1x User Manual AUTOSAR_PWM_Component_Us
1.0.3
As part of V4.00.04 P1x Maintenance Activity,Following changes
erManual.pdf
are made.
1. Chapter 2 is updated for referenced documents version.
2. Updated Section 3.1.1 and section 13.1.1 for adding the device
names.
3. Section 13.3.1 is updated for name of the parameter definition
file and additional devices.
4. Section 13.4 is updated for ROM/RAM usage, Stack Depth and
Throughput details.
5. Section 4.1 is updated to add notes for the file
“Interrupt_VectorTable.c” and the API
“Pwm_SetChannelOutput”.
6. In Section 13, The Compiler,Linker and Assembler options are
removed.
7. Section 4.6, Table 4-2, Remarks is updated for the
Set_TriggerDealy API.
8. In Section 4.1, a note is updated for the ‘The counter of master
channel’.
AUTOSAR_PWM_Tool_UserManu
1.0.3
As part of V4.00.04 P1x Maintenance Activity,
al.pdf
following changes are made:
1. Chapter 2 ‘Reference’ is updated for the name and version of
the parameter definition files.
2. Error message ERR000019 is added in section 8.1
12.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 35 of 42
Renesas Electronics
Release Date: 08/06/2015
13 RAMTST
13.1 Target Info
Processor P1M - R7F701310
Module RAMTST
Date 08-June-2015
13.2 Release Items
Filename Version Change Description P1x Parameter Definition file R403_RAMTST_P1M_04_05.arxml
1.0.1
As per mantis 25915 following changes are made:
1. File name changed to R403_RAMTST_P1M_04_05.arxml
from R403_RAMTST_P1M_701304_701305.arxml.
2. LOWER-MULTIPLICITY of
RamTstDemEventParameterRefs container and
RAMTST_E_RAM_FAILURE parameter is updated.
R403_RAMTST_P1M_10_to_15_1
1.0.3
As per mantis 25915 , following changes are made :
8_to_23.arxml
1. LOWER-MULTIPLICITY of
RamTstDemEventParameterRefs container and
RAMTST_E_RAM_FAILURE parameter is updated.
2. File name changed from
R403_RAMTST_P1M_701310_to_701315_701318
_to_701323.arxml to
R403_RAMTST_P1M_10_to_15_18_to_23.arxml
BSWMDT R403_RAMTST_P1x_BSWMDT.ar
1.0.4
No change
xml
Source Code RamTst.c
1.1.4
No change
RamTst.h
1.1.3
No change
RamTst_RegReadBack.h
1.0.1
No change
RamTst_Types.h
1.1.2
No change
Tool Executable RamTst_X1x.exe
1.0.8
No change
RamTst_X1x.cfgxml
1.0.0
No change
X1x Sample Application source file App_RAMTST_Common_Sample.c
1.0.1
No change
X1x Sample Application header file App_RAMTST_Common_Sample.h
1.0.0
No change
Page 36 of 42
Renesas Electronics
Release Date: 08/06/2015
P1x Sample Application P1M Source file App_RAMTST_P1M_Sample.c
1.0.2
No change
P1x Sample Application P1M header file App_RAMTST_Device_Sample.h
1.0.1
No change
P1x User Manual AUTOSAR_RAMTST_Component
1.0.3
As part of P1x V4.00.04 activity following changes are made:
_UserManual.pdf
1. In chapter 2, Reference documents updated.
2. Chapter 3, section 3.3.1 Folder structure updated.
3. Chapter 13 supporting device name updated, also section
13.1.1 updated.
4. Chapter 13, section 13.2 compiler, linker, and assembler
options removed.
5. Chapter 13, section 13.2 Sample Application updated.
6. Chapter 13, section 13.3 Memory And Throughput Details
updated.
AUTOSAR_RAMTST_Tool_User
1.0.3
Following changes are made:
Manual.pdf
1.Updated chapter 2 by adding new PDF reference.
13.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 37 of 42
Renesas Electronics
Release Date: 08/06/2015
14 SPI
14.1 Target Info
Processor P1M - R7F701310
Module SPI
Date 08-June-2015
14.2 Release Items
Filename Version Change Description P1x Parameter Definition file R403_SPI_P1M_04_05_12_13_20_
1.0.5
As per mantis #27411,following changes are made
21.arxml
1. File has been renamed to reduce file name length.
2. Updated Copyright information.
R403_SPI_P1M_10_11_14_15_18_
1.0.5
As per mantis #27411,following changes are made
19_22_23.arxml
1. File has been renamed to reduce file name length.
2. Updated Copyright information.
BSWMDT File R403_SPI_P1x_BSWMDT.arxml
1.0.6
Following changes are made:
1. Software version information is updated.
2. Updated copyright information.
Source Code Spi.c
1.5.6
No change
Spi_Driver.c
1.4.4
Following changes are made
1. As per mantis #27771, Spi_ReceiveISR API is updated to
remove compilation warning.
2. As per mantis #27772, Spi_HwInit API is updated for 32 bit
DMA settings.
Spi_Irq.c
1.2.8
No change
Spi_Ram.c
1.2.8
No change
Spi_Scheduler.c
1.2.12
No change
Spi_Version.c
1.0.6
No change
Spi.h
1.1.5
No change
Spi_Driver.h
1.2.9
No change
Spi_Irq.h
1.2.3
No change
Spi_LTTypes.h
1.2.11
As per mantis #27772, definition for
SPI_DMA_32BIT_RX_SETTINGS and
SPI_DMA_32BIT_TX_SETTINGS are added.
Spi_PBTypes.h
1.2.11
No change
Spi_Ram.h
1.2.8
No change
Page 38 of 42
Renesas Electronics
Release Date: 08/06/2015
Spi_Scheduler.h
1.2.4
No change
Spi_Types.h
1.2.7
No change
Spi_Version.h
1.0.6
No change
Tool Executable Spi_X1x.exe
1.2.12
No change
Spi_X1x.cfgxml
1.0.0
No change
X1x Common Sample Application Source file App_SPI_Common_Sample.c
1.0.7
As part of P1x V4.00.04 Release activity,
1. Removed all device specific macros.
2. Test Application is updated to make it common across all family
X1x Common Sample Application header file App_SPI_Common_Sample.h
1.0.5
As part of P1x V4.00.04 Release activity,
1. Removed all device specific macros.
2. Test Application is updated to make it common across all family
P1x Sample Application P1M Source file App_SPI_P1M_Sample.c
1.0.3
As part of P1x V4.00.04 development activity, following changes
are made:
1. Corrected port settings and chip select settings for master for
701310 external loopback testing.
2. Updated slave register settings.
3. Updated Copyright information.
P1x Sample Application P1M header file App_SPI_Device_Sample.h
1.0.2
As part of P1x V4.00.04 development activity, following
changes are made:
1. Modified for 701310 external loopback testing.
2. Updated slave register settings.
3. Updated Copyright information
P1x User Manual AUTOSAR_SPI_Component_User
1.0.6
Following changes are made :
Manual.pdf
1. Updated Chapter 2 ‘Reference Documents’ to correct the name
and version of device manual.
2. Information regarding Interrupt vector table has been provided
in section 4.1 ‘General’.
3. In Chapter 13, ’P1M Specific Information’ P1M 4.0.3 supported
devices are updated.
4. Table 13-1 PDF information updated for P1M 4.0.3 supported
devices.
5. Section 13.1.1 has been updated to include the translation
header file for all P1M 4.0.3 supporting devices.
Page 39 of 42
Renesas Electronics
Release Date: 08/06/2015
6. Updated section 13.3.1 ‘Sample Application Structure’ to add
all the supported devices for P1M 4.0.3.
7. Updated section 13.3.2 ‘Building the Sample Application’ to
add configuration details for the device 701310.
8. Updated section 13.4 ‘Memory and Throughput’ for the device
R7F701310.
9. Updated chapter 14 ‘Release Details’ to correct the SPI driver
version.
10. Removed section ‘Compiler, Linker and Assembler’ from
chapter 13.
11. Added macros SPI_DMA_32BIT_TX_SETTINGS and
SPI_DMA_32BIT_RX_SETTINGS in Chapter 6 ‘Registers
Details’.
AUTOSAR_SPI_Tool_UserManual.
1.0.7
Following changes are made:
pdf
1. Updated section 2.1 ‘Reference Documents’ to correct the name
and version of Parameter Definition Files.
2. Section 8.1 and Section 8.2 is modified for removing warning
and adding error message (WRN083001 to ERR083122).
14.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 40 of 42
Renesas Electronics
Release Date: 08/06/2015
15 WDG
15.1 Target Info
Processor P1M - R7F701310
Module WDG
Date 08-June-2015
15.2 Release Items
Filename Version Change Description P1x - Parameter Definition files R403_WDG_P1M_04_05_10_to_15
1.0.3
As part of P1x V4.00.04 development activity the
_18_to_23.arxml
following changes are made:
1. As per mantis #27411, file name changed to
R403_WDG_P1M_04_05_10_to_15_18_to_23.arxml
2. Copyright information updated.
3. ADMIN-DATA updated.
BSWMDT R403_WDG_P1x_BSWMDT.arxml
1.0.3
No change
Source Code Wdg_59_DriverA.c
1.0.12
No change
Wdg_59_DriverA_Irq.c
1.0.8
No change
Wdg_59_DriverA_Private.c
1.0.5
No change
Wdg_59_DriverA_Ram.c
1.0.5
No change
Wdg_59_DriverA_Version.c
1.0.4
No change
Wdg_59_DriverA.h
1.0.6
No change
Wdg_59_DriverA_Debug.h
1.0.1
No change
Wdg_59_DriverA_Irq.h
1.0.5
No change
Wdg_59_DriverA_PBTypes.h
1.0.8
No change
Wdg_59_DriverA_Private.h
1.0.3
No change
Wdg_59_DriverA_Ram.h
1.0.5
No change
Wdg_59_DriverA_RegReadBack.h
1.0.0
No change
Wdg_59_DriverA_Types.h
1.0.4
No change
Wdg_59_DriverA_Version.h
1.0.5
No change
Tool Executable Wdg_X1x.exe
1.0.17
No change
Wdg_X1x.cfgxml
1.0.0
No change
X1x Common Sample Application Source file App_WDG_Common_Sample.c
1.0.10
No change
Page 41 of 42
Renesas Electronics
Release Date: 08/06/2015
X1x Common Sample Application header file App_WDG_Common_Sample.h
1.0.4
No change
P1x Sample Application P1M Source file App_WDG_P1M_Sample.c
1.0.3
No change
P1x Sample Application P1M header file App_WDG_Device_Sample.h
1.0.2
No change
P1x User Manual AUTOSAR_WDG_Component_Us
1.0.4
Following changes are made:
erManual.pdf
1. Updated Chapter 4.1 to add notes.
2. Updated Chapter 13 to add new device support.
3. Removed sections for Compiler, Linker and Assembler.
4. Updated Chapter 13.3 with memory and throughput details.
5. Updated copyright information.
AUTOSAR_WDG_Tool_UserManu
1.0.2
Following changes are made:
al.pdf
1. Updated Chapter 2 to add PDF reference.
2. Updated copyright information.
15.3 Known Issues
ID Description 1.
Please refer KnownIssues_P1x_R403_2015_CW23.pdf
Page 42 of 42
Document Outline
10 - RenesasMcalSuprt Peer Review Checklists
Overview
Summary Sheet
Synergy Project
Source Code
Sheet 1: Summary Sheet
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 1.2 | 8-Jun-15 |
 | Peer Review Summary Sheet |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Synergy Project Name: |
|
|
| kzshz2:
Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy
Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request.
RenesasMcalSuprt |
| Revision / Baseline: |
|
|
| kzshz2:
Intended Use: Identify which Synergy revision of this component is being reviewed
Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request.
Suprt_Renesas_Mcal_02.00.00 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
|
| kzshz2:
Intended Use: Identify the developer who made the change(s)
Rationale: A change request may have more than one resolver, this will help identify who made what change. Change owner identification may be required by indusrty standards.
Lucas Wendling |
| Work CR ID: |
|
|
| EA4#3177 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Intended to identify at a high level to the reviewers which areas of the component have been changed.
Rationale: This will be good information to know when ensuring appropriate reviews have been completed.
Modified File Types: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| kzshz2:
Intended Use: Identify who where the reviewers, what they reviewed, and if the reviewed changes have been approved to release the code for testing. Comments here should be at a highlevel, the specific comments should be present on the specific review form sheet.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
ADD DR Level
Move reviewer and approval to individual checklist form
Review Checklist Summary: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Reviewed: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| N/A | MDD |
|
|
| N/A | Source Code |
|
|
| N/A | PolySpace |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| N/A | Integration Manual |
|
|
| N/A | Davinci Files |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Comments: |
|
| 3rd Party BSW component. Only reviewed 3rd party files for correctness to delivery and any Nexteer created |
|
|
|
|
|
|
| source files and documentation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Guidelines:
- The reviews shall be performed over the portions of the component that were modified as a result of the Change Request.
- New components should include FDD Owner and Integrator as apart of the Group Review Board (Source Code, Integration Manual, and Davinci Files)
- Enter any rework required into the comment field and select No. When the rework is complete, review again using this same review sheet and select Yes. Add date and additional comment stating that the rework is completed.
- To review a component with multiple source code files use the "Add Source" button to create a Source code tab for each source file.
- .h file should be reviewed with the source file as part of the source file. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 2: Synergy Project
| Peer Review Meeting Log (Component Synergy Project Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
| New baseline version name from Summary Sheet follows |
|
|
|
|
|
|
|
|
| | Yes |
| Comments: |
|
| Follows convention created for |
|
| naming convention |
|
|
|
|
|
|
|
|
|
|
|
| BSW components |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Project contains necessary subprojects |
|
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Project contains the correct version of subprojects |
|
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Design subproject is correct version |
|
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| LN:
Intended Use: Identify who were the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
KMC:
Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Lucas Wendling |
|
|
| Review Date : |
|
| 01/12/16 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Kathleen Creager |
|
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sheet 3: Source Code
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rev 1.2 | 8-Jun-15 |
| Peer Review Meeting Log (Source Code Review) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Source File Name: |
|
|
| N/A |
|
| Source File Revision: |
|
|
| N/A |
| Header File Name: |
|
|
| Renesas_Compiler.h |
|
| Header File Revision: |
|
|
| kzshz2:
Intended Use: Identify which version of the source file is being review.
Rationale: Required for traceability between source code and review. Auditors will likely require this.
1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| MDD Name: |
|
| N/A |
|
| Revision: |
| N/A |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| FDD/SCIR/DSR/FDR/CM Name: |
|
|
|
|
| N/A |
|
| Revision: |
| N/A |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Quality Check Items: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Rationale is required for all answers of No |
|
|
|
|
|
|
|
|
|
|
| Working EA4 Software Naming Convention followed: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| for variable names |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| for constant names |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| for function names |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| for other names (component, memory |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| mapping handles, typedefs, etc.) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All paths assign a value to outputs, ensuring |
|
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| all outputs are initialized prior to being written |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Requirements Tracability tags in code match the requirements tracability in the FDD |
|
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| requirements tracability in the FDD |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All variables are declared at the function level. |
|
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Synergy version matches change history |
|
|
|
|
|
| kzshz2:
Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s).
Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.
|
|
| | N/A |
| Comments: |
|
|
|
|
| and Version Control version in file comment block |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change log contains detailed description of changes |
|
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
| and Work CR number |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code accurately implements FDD (Document or Model) |
|
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Verified no Compiler Errors or Warnings |
|
|
| KMC:
Intended Use: To confirm no compiler errors or warnings exist for the code under review (warnings from contract header files may be ignored).
Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project should be used; QAC can find compiler errors but not warnings.
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Component.h is included |
|
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All other includes are actually needed. (System includes |
|
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| only allowed in Nexteer library components) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Software Design and Coding Standards followed: |
|
|
|
|
|
|
|
|
|
|
|
| Version: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code comments are clear, correct, and adequate |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| and have been updated for the change: [N40] and |
|
|
|
|
|
|
|
|
|
|
|
|
|
| all other rules in the same section as rule [N40], |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| plus [N75], [N12], [N23], [N33], [N37], [N38], |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| [N48], [N54], [N77], [N79], [N72] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Source file (.c and .h) comment blocks are per |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| standards and contain correct information: [N41], [N42] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Function comment blocks are per standards and |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| contain correct information: [N43] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Code formatting (indentation, placement of |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| braces, etc.) is per standards: [N5], [N55], [N56], |
|
|
|
|
|
|
|
|
|
|
|
|
|
| [N57], [N58], [N59] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Embedded constants used per standards; no |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| "magic numbers": [N12] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Memory mapping for non-RTE code |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| is per standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All execution-order-dependent code can be |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| recognized by the compiler: [N80] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All loops have termination conditions that ensure |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| finite loop iterations: [N63] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All divides protect against divide by zero |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| if needed: [N65] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All integer division and modulus operations |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| handle negative numbers correctly: [N76] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All typecasting and fixed point arithmetic, |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| including all use of fixed point macros and |
|
|
|
|
|
|
|
|
|
|
|
|
|
| timer functions, is correct and has no possibility |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| of unintended overflow or underflow: [N66] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All float-to-unsiged conversions ensure the. |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| float value is non-negative: [N67] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All conversions between signed and unsigned |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| types handle msb==1 as intended: [N78] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All pointer dereferencing protects against |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| null pointer if needed: [N70] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Component outputs are limited to the legal range |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| defined in the FDD DataDict.m file : [N53] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| All code is mapped with FDD (all FDD |
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| subfunctions and/or model blocks identified |
|
|
|
|
|
|
|
|
|
|
|
|
|
| with code comments; all code corresponds to |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| some FDD subfunction and/or model block): [N40] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Review did not identify violations of other |
|
|
|
|
|
|
|
|
| | N/A |
| Comments: |
|
|
|
|
|
|
|
|
|
|
| coding standard rules |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Anomaly or Design Work CR created |
|
|
|
|
|
|
|
|
| | N/A |
| Comments: List Anomaly or CR numbers |
|
|
|
|
|
|
|
|
|
|
| for any FDD corrections needed |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| General Notes / Comments: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Review only delivered file from renesas MCAL vs files to be checked in. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| LN:
Intended Use: Identify who were the reviewers and if the reviewed changes have been approved.
Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits.
KMC:
Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4.
Review Board: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Change Owner: |
|
| Lucas Wendling |
|
|
| Review Date : |
|
| 01/12/16 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Lead Peer Reviewer: |
|
|
| Kathleen Creager |
|
|
| Approved by Reviewer(s): |
|
|
|
| Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Other Reviewer(s): |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|