3 - 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 L
M   AUTOSAR 
 
 
XML 
 
 
 
ECU SPECTRUM 
PROJECT SETTING 
ECU 
 
FILE 
CONFIGURATION 
 
PARAMETER 
 
 
DEFINITION 
 
 
AUTOSAR 
X L
M   
 
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. 
 
 
INF000008: 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

• Chapter 1 Introduction
• Chapter 2 ECU Configuration Editor (ECU  Spectrum)
  • 2.1. Installation Of ECU Configuration Editor (ECU  Spectrum)
  • 2.2. ECU Spectrum Input and Output Files
• Chapter 3 Configuration Using ECU Configuration
• Editor (ECU Spectrum)
  • 3.1. Creating New Project
  • 3.2. Configuration
    • 3.2.1. Parameter Configuration
    • 3.2.2. Distinguish Between Containers
    • 3.2.3. Save Project
    • 3.2.4. Validation
  • 3.3. Generate ECU Configuration Description
• Chapter 4 Generation Tool
  • 4.1. Translation XML File
    • 4.1.1. Translation Header File
    • 4.1.2. Device Specific Header File
  • 4.2. Configuration XML File
  • 4.3. Usage
  • 4.4. Sample Usage
  • 4.5. Tool Installation Requirements
    • 4.5.1. Hardware Requirements
    • 4.5.2. Software Requirements
    • 4.5.3. Limitations
  • 4.6. Tool Installation
    • 4.6.1. Pre Requisite
    • 4.6.2. Installation Steps
  • 4.7. Tool Un-Installation
  • 4.8. Common Messages
    • 4.8.1. Error Messages
    • 4.8.2. Warning Messages
    • 4.8.3. Information Messages
  • 4.9. R3.2.2 Messages
    • 4.9.1. Error Messages
    • 4.9.2. Warning Messages
    • 4.9.3. Information Messages
  • 4.10. R4.0.3 Messages
    • 4.10.1. Error Messages
    • 4.10.2. Warning Messages
    • 4.10.3. Information Messages
  • 4.11. BSWMDT File
• Chapter 5 Application Example
  • 5.1. Folder Structure
  • 5.2. Makefile Description
    • 5.2.1. App_<Msn>_<variant>_Sample.mak
  • 5.3. Integrating The <MSN> Driver Component With  Other Components
  • 5.4. Building The <MSN> Driver Component
    • 5.4.1. Targets Supported By The Sample Base Makefile
      • 5.4.1.1. debug_base_make
      • 5.4.1.2. clean_objs
      • 5.4.1.3. clean
      • 5.4.1.4. clean_all
      • 5.4.1.5. generate_<msn>_config
      • 5.4.1.6. App_<MSN>_< MICRO_SUB_VARIANT >_Sample.out
      • 5.4.1.7. <Msn>_PBcfg.s37
• Chapter 6 Support For Different Interrupt Categories
• Chapter 7 GNU MAKE Environment
  • 7.1. Build Process With GNUMAKE
  • 7.2. Build Process Without GNUMAKE
• Chapter 8 Load Binaries
• Chapter 9 Appendix
  • 9.1. Translation XML File
  • 9.2. Configuration XML File

---

6 - 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. 

---