Note : Referencing the external components should be avoided in most cases. Only in unavoidable circumstance external components should be referred. Developer should track the references.

Global Functions(Non RTE) to be provided to Integration Project

This component provides the following inline functions in NxtrMcuSuprtLib.h for use as needed in components and integration project. Note that the exact API for usage can be found in the header file.

For P1M devices:

Function Name	Description
WrProtdRegPortJ_u32	Protected Register write sequence for 32bit PortJ peripheral registers
WrProtdRegPort0_u32	Protected Register write sequence for 32bit Port0 peripheral registers
WrProtdRegPort1_u32	Protected Register write sequence for 32bit Port1 peripheral registers
WrProtdRegPort2_u32	Protected Register write sequence for 32bit Port2 peripheral registers
WrProtdRegPort3_u32	Protected Register write sequence for 32bit Port3 peripheral registers
WrProtdRegPort4_u32	Protected Register write sequence for 32bit Port4 peripheral registers
WrProtdRegPort5_u32	Protected Register write sequence for 32bit Port5 peripheral registers
WrProtdRegSys_u08	Protected Register write sequence for 8bit Sys peripheral registers
WrProtdRegSys_u32	Protected Register write sequence for 32bit Sys peripheral registers
WrProtdRegSysClmac_u32	Protected Register write sequence for 32bit Clmac peripheral registers
WrProtdRegClma0_u08	Protected Register write sequence for 8bit Clma0 peripheral registers
WrProtdRegClma1_u08	Protected Register write sequence for 8bit Clma1 peripheral registers
WrProtdRegClma2_u08	Protected Register write sequence for 8bit Clma2 peripheral registers
WrProtdRegClma3_u08	Protected Register write sequence for 8bit Clma3 peripheral registers
WrProtdRegEcmm_u08	Protected Register write sequence for 8bit Ecmm peripheral registers
WrProtdRegEcmc_u08	Protected Register write sequence for 8bit Ecmc peripheral registers
WrProtdRegEcm_u08	Protected Register write sequence for 8bit Ecm peripheral registers
WrProtdRegEcm_u16	Protected Register write sequence for 16bit Ecm peripheral registers
WrProtdRegEcm_u32	Protected Register write sequence for 32bit Ecm peripheral registers
WrProtdRegFlmd_u32	Protected Register write sequence for 32bit Flmd peripheral registers
NxtrSwRst	API to issue a Nexteer Defined Software Reset
NxtrSwRstFromExcpn	API to issue a Nexteer Defined Software Reset for resetting from a hardware exception source

For P1XC devices:

Function Name	Description
WrProtdRegEcmm0_u32	Protected Register write sequence for 32bit Ecmm0 peripheral registers
WrProtdRegEcmc0_u32	Protected Register write sequence for 32bit Ecmc0 peripheral registers
WrProtdRegEcm0_u32	Protected Register write sequence for 32bit Ecm0 peripheral registers
WrProtdRegFlmd_u32	Protected Register write sequence for 32bit Flmd peripheral registers
NxtrSwRst	API to issue a Nexteer Defined Software Reset
NxtrSwRstFromExcpn	API to issue a Nexteer Defined Software Reset for resetting from a hardware exception source

Configuration REQUIREMeNTS

None

Build Time Config

Modules	Notes

Configuration Files to be provided by Integration Project

N/A

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC

DaVinci Interrupt Configuration Changes

ISR Name	Notes

Manual Configuration Changes

Constant	Notes	SWC

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Required Global Data Outputs

Specific Include Path present

Yes – Integrator must properly choose the correct include search path in this component in the integration .gpj file. The path chosen must align with the correct micro family (e.g. P1M vs P1MC) as well as the correct specific micro derivative that is being used in the integration project (e.g. R7F701373A). Additionally, the integration .gpj should only include the correct subproject .gpj file (again aligning to the correct micro family as well as correct micro derivative). Please note that two include paths are required in the integration project for use of this component, one to the base family being used (e.g. “-I..\..\AR202A_MicroCtrlrSuprt_Impl\include\P1XC\”) and one to the exact micro derivative (e.g. “-I..\..\AR202A_MicroCtrlrSuprt_Impl\include\P1XC\R7F701373A\”).

Runnable Scheduling

None.

Init	Scheduling Requirements	Trigger

Runnable	Scheduling Requirements	Trigger

.

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes

* Each …START_SEC… constant is terminated by a …STOP_SEC… constant as specified in the AUTOSAR Memory Mapping requirements.

Usage

Feature	RAM	ROM

NvM Blocks

Compiler Settings

Preprocessor MACRO

Optimization Settings

Appendix

<This section is for appendix>

2 - MicroCtrlrSuprt Module Design Document

Module Design Document

For

MicroCtrlrSuprt

7/19/17

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Lucas Wendling	1	7/19/17

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of NxtrOsErrHndlg (Expected External Intefaces) 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: 9

5.1.2 Per: 9

5.2 Server Runables 9

5.2.1 NxtrOsErrHndlg 9

5.2.1.1 Design Rationale 9

5.2.1.2 Processing 9

5.3 Interrupt Functions 13

5.4 Module Internal (Local) Functions 13

5.4.1 Local Function #1 13

5.4.1.1 Design Rationale 13

5.4.1.2 Processing 13

5.5 GLOBAL Function/Macro Definitions 13

5.5.1 GLOBAL Function #1 13

5.5.1.1 Design Rationale 13

5.5.1.2 Processing 13

6 Known Limitations with Design 14

7 UNIT TEST CONSIDERATION 15

Appendix A Abbreviations and Acronyms 16

Appendix B Glossary 17

Appendix C References 18

Introduction

Purpose

This design document will capture the design of the Nexteer Mcu Support Library (NxtrMcuSuprtLib) functionality. This is the only portion of this component that is designed by Nexteer rather than generated by a 3^rd party tool.

Scope

The following definitions are used throughout this document:

Shall: indicates a mandatory requirement without exception in compliance.
Should: indicates a mandatory requirement; exceptions allowed only with documented justification.
May: indicates an optional action.

High-Level Description

The Nexteer designed portions of this component include the definition of some inline functions for supporting the Renesas microcontroller. These are described in detail in the following sections. Note that this component supports multiple files to support the different microcontroller variants used by Nexteer.

Design details of software module

Graphical representation of Protected Register Write Functions

In general, the design of all protected write functions contained in this module follow the following high-level flow:

Graphical representation of Nexteer Software Reset Function

Graphical representation of Nexteer Software Reset From Exception Function

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
None

Software Component Implementation

Sub-Module Functions

Init:

None

Per:

None

Library/Server Runables

P1M Micro Variants

Protected Write APIs

Function Name	WrProtdRegPortJ_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFC24014 0xFFC24018 0xFFC24028
Return Value	N/A (void)

Function Name	WrProtdRegPort0_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFC14014 0xFFC14018 0xFFC1403C 0xFFC14028 0xFFC10030
Return Value	N/A (void)

Function Name	WrProtdRegPort1_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFC14054 0xFFC14058 0xFFC1407C 0xFFC14068 0xFFC10070
Return Value	N/A (void)

Function Name	WrProtdRegPort2_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFC14094 0xFFC14098 0xFFC140BC 0xFFC140A8 0xFFC100B0
Return Value	N/A (void)

Function Name	WrProtdRegPort3_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFC140D4 0xFFC140D8 0xFFC140FC 0xFFC140E8 0xFFC100F0
Return Value	N/A (void)

Function Name	WrProtdRegPort4_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFC14114 0xFFC14118 0xFFC1413C 0xFFC14128 0xFFC10130
Return Value	N/A (void)

Function Name	WrProtdRegPort5_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFC14154 0xFFC14158 0xFFC1417C 0xFFC14168 0xFFC10170
Return Value	N/A (void)

Function Name	WrProtdRegSys_u08	Type	Min	Max
Arguments Passed	WrVal_Arg	uint8	Full	Full
	WrAddr_Arg	pointer to volatile uint8	Valid values: 0xFFF82838 0xFFF82830 0xFFF8282C 0xFFF8283C
Return Value	N/A (void)

Function Name	WrProtdRegSys_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFF82840
Return Value	N/A (void)

Function Name	WrProtdRegSysClmac_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFF82C00 0xFFF8AC18 0xFFF89080 0xFFF890C0 0xFFF89200 0xFFF8A440 0xFFF88204
Return Value	N/A (void)

Function Name	WrProtdRegClma0_u08	Type	Min	Max
Arguments Passed	WrVal_Arg	uint8	Full	Full
	WrAddr_Arg	pointer to volatile uint8	Valid values: 0xFFF88400
Return Value	N/A (void)

Function Name	WrProtdRegClma1_u08	Type	Min	Max
Arguments Passed	WrVal_Arg	uint8	Full	Full
	WrAddr_Arg	pointer to volatile uint8	Valid values: 0xFFF88420
Return Value	N/A (void)

Function Name	WrProtdRegClma2_u08	Type	Min	Max
Arguments Passed	WrVal_Arg	uint8	Full	Full
	WrAddr_Arg	pointer to volatile uint8	Valid values: 0xFFF88440
Return Value	N/A (void)

Function Name	WrProtdRegClma3_u08	Type	Min	Max
Arguments Passed	WrVal_Arg	uint8	Full	Full
	WrAddr_Arg	pointer to volatile uint8	Valid values: 0xFFF88460
Return Value	N/A (void)

Function Name	WrProtdRegEcmm_u08	Type	Min	Max
Arguments Passed	WrVal_Arg	uint8	Full	Full
	WrAddr_Arg	pointer to volatile uint8	Valid values: 0xFFD60000 0xFFD60004
Return Value	N/A (void)

Function Name	WrProtdRegEcmc_u08	Type	Min	Max
Arguments Passed	WrVal_Arg	uint8	Full	Full
	WrAddr_Arg	pointer to volatile uint8	Valid values: 0xFFD61000 0xFFD61004
Return Value	N/A (void)

Function Name	WrProtdRegEcm_u08	Type	Min	Max
Arguments Passed	WrVal_Arg	uint8	Full	Full
	WrAddr_Arg	pointer to volatile uint8	Valid values: 0xFFD62000 0xFFD6203C
Return Value	N/A (void)

Function Name	WrProtdRegEcm_u16	Type	Min	Max
Arguments Passed	WrVal_Arg	uint16	Full	Full
	WrAddr_Arg	pointer to volatile uint16	Valid values: 0xFFD62044
Return Value	N/A (void)

Function Name	WrProtdRegEcm_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFD62004 0xFFD62008 0xFFD6200C 0xFFD62010 0xFFD62014 0xFFD62018 0xFFD6201C 0xFFD62020 0xFFD62024 0xFFD62028 0xFFD62034 0xFFD62038 0xFFD62048 0xFFD6204C 0xFFD62050 0xFFD62054
Return Value	N/A (void)

Function Name	WrProtdRegFlmd_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFA00000
Return Value	N/A (void)

Design Rationale

These functions will perform the correct sequence of writes to protected registers. These are designed such that the function attempts the write sequence up to 3 times with increasing levels of interrupt disabling for each attempt (no interrupts disabled->Os interrupts disabled->All interrupts disabled). Since these functions are broken out based on the peripheral register set to be written and width of register write, DET error checking is done to ensure the implementer is using the correct API. A DET error is also set if for some reason the 3 write attempts all fail.

Processing

See source code for implementation.

Nexteer Software Reset

Function Name	NxtrSwRst	Type	Min	Max
Arguments Passed	McuDiagcData0_Arg	McuDiagc1	Full	Full
	McuDiagcData1_Arg	uint32	Full	Full
Return Value	N/A (void)

Design Rationale

This function exists to ensure that before calling a reset, the caller is properly indicating what the source of the reset is and that this type of reset is part of the known list of reset causes. Additionally, the second parameter is able to store more information along with the reset. This processing is done in a separate component, but the interface is the “SetMcuDiagcIdnData” API. Additionally, the Renesas SAN indicates that before any software reset, the register containing the reset cause flags shall be cleared. The Mcu_PerformReset() function is then called to perform the actual reset. In the event that there is an issue where this function doesn’t actually perform a reset as expected, a while loop is entered at the end of this function, which could likely lead to a hardware watchdog timeout if this loop is entered.

Processing

See source code for implementation.

Nexteer Software Reset From Exception

Function Name	NxtrSwRstFromExcpn	Type	Min	Max
Arguments Passed	McuDiagcData0_Arg	McuDiagc1	Full	Full
	McuDiagcData1_Arg	uint32	Full	Full
Return Value	N/A (void)

Design Rationale

This function exists to ensure that before calling a reset from a hardware exception, the caller is properly indicating what the source of the reset is and that this type of reset is part of the known list of reset causes. This function will clear all ECM status registers prior to issuing a reset to ensure a known state of these registers after the reset. Additionally, the second parameter to this function is used to store more information along with the reset.

In an effort to try to capture useful data relating to the exception, the internal logic of this function will attempt to at least store the register value that contains the program counter of when the exception occurred. In order for this to work, a value of “0x0000000” must be passed to the “McuDiagcData1_Arg” argument in the case of an FE exception, and an value of “0xFFFFFFFF” must be passed to the “McuDiagcData1_Arg” argument in the case of an EI exception. In case of any other values in the “McuDiagcData1_Arg” , this function assumes the caller of this function has already setup data that is desired to be stored in this argument, and therefore leaves it unmodified.

This storage of this reset information is done in a separate component, but the interface is the “SetMcuDiagcIdnData” API.

This function also intentionally attempts to write the error output pin to an “error” state as a redundant mechanisms for putting the system into a safe state in the event that the software reset (which also should drive the system to a safe state) doesn’t properly execute.

Additionally, the Renesas SAN indicates that before any software reset, the register containing the reset cause flags shall be cleared. The Mcu_PerformReset() function is then called to perform the actual reset. In the event that there is an issue where this function doesn’t actually perform a reset as expected, a while loop is entered at the end of this function, which could likely lead to a hardware watchdog timeout if this loop is entered.

Processing

See source code for implementation.

P1XC Micro Variants

Protected Write APIs

Function Name	WrProtdRegEcmm0_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFD60000 0xFFD60004
Return Value	N/A (void)

Function Name	WrProtdRegEcmc0_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFD61000 0xFFD61004
Return Value	N/A (void)

Function Name	WrProtdRegEcm0_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFD62000 0xFFD62004 0xFFD62008 0xFFD6200C 0xFFD62010 0xFFD62014 0xFFD62018 0xFFD6201C 0xFFD62020 0xFFD62024 0xFFD62028 0xFFD6202C 0xFFD62030 0xFFD62034 0xFFD62038 0xFFD6203C 0xFFD62048 0xFFD6204C 0xFFD62050 0xFFD62054 0xFFD6205C 0xFFD62060 0xFFD62064 0xFFD62068 0xFFD6206C 0xFFD62070 0xFFD62074 0xFFD62078
Return Value	N/A (void)

Function Name	WrProtdRegFlmd_u32	Type	Min	Max
Arguments Passed	WrVal_Arg	uint32	Full	Full
	WrAddr_Arg	pointer to volatile uint32	Valid values: 0xFFA00000
Return Value	N/A (void)

Design Rationale

These functions will perform the correct sequence of writes to protected registers. These are designed such that the function attempts the write sequence up to 3 times with increasing levels of interrupt disabling for each attempt (no interrupts disabled->Os interrupts disabled->All interrupts disabled). Since these functions are broken out based on the peripheral register set to be written and width of register write, DET error checking is done to ensure the implementer is using the correct API. A DET error is also set if for some reason the 3 write attempts all fail.

Processing

See source code for implementation.

Nexteer Software Reset

Function Name	NxtrSwRst	Type	Min	Max
Arguments Passed	McuDiagcData0_Arg	P1mcDiagc1	Full	Full
	McuDiagcData1_Arg	uint32	Full	Full
Return Value	N/A (void)

Design Rationale

This function exists to ensure that before calling a reset, the caller is properly indicating what the source of the reset is and that this type of reset is part of the known list of reset causes. Additionally, the second parameter is able to store more information along with the reset. This processing is done in a separate component, but the interface is the “SetMcuDiagcIdnData” API. Additionally, the Renesas SAN indicates that before any software reset, the register containing the reset cause flags shall be cleared. The Mcu_PerformReset() function is then called to perform the actual reset. In the event that there is an issue where this function doesn’t actually perform a reset as expected, a while loop is entered at the end of this function, which could likely lead to a hardware watchdog timeout if this loop is entered.

Processing

See source code for implementation.

Nexteer Software Reset From Exception

Function Name	NxtrSwRstFromExcpn	Type	Min	Max
Arguments Passed	McuDiagcData0_Arg	P1mcDiagc1	Full	Full
	McuDiagcData1_Arg	uint32	Full	Full
Return Value	N/A (void)

Design Rationale

This function exists to ensure that before calling a reset from a hardware exception, the caller is properly indicating what the source of the reset is and that this type of reset is part of the known list of reset causes. This function will clear all ECM status registers prior to issuing a reset to ensure a known state of these registers after the reset. Additionally, the second parameter to this function is used to store more information along with the reset.

In an effort to try to capture useful data relating to the exception, the internal logic of this function will attempt to at least store the register value that contains the program counter of when the exception occurred. In order for this to work, a value of “0x0000000” must be passed to the “McuDiagcData1_Arg” argument in the case of an FE exception, and an value of “0xFFFFFFFF” must be passed to the “McuDiagcData1_Arg” argument in the case of an EI exception. In case of any other values in the “McuDiagcData1_Arg” , this function assumes the caller of this function has already setup data that is desired to be stored in this argument, and therefore leaves it unmodified.

This storage of this reset information is done in a separate component, but the interface is the “SetMcuDiagcIdnData” API.

This function also intentionally attempts to write the error output pin to an “error” state as a redundant mechanisms for putting the system into a safe state in the event that the software reset (which also should drive the system to a safe state) doesn’t properly execute.

Additionally, the Renesas SAN indicates that before any software reset, the register containing the reset cause flags shall be cleared. The Mcu_PerformReset() function is then called to perform the actual reset. In the event that there is an issue where this function doesn’t actually perform a reset as expected, a while loop is entered at the end of this function, which could likely lead to a hardware watchdog timeout if this loop is entered.

Processing

See source code for implementation.

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	Type	Min	Max
Arguments Passed

Return Value

Design Rationale

Processing

GLOBAL Function/Macro Definitions

GLOBAL Function #1

Function Name	Type	Min	Max
Arguments Passed

Return Value

Design Rationale

Processing

Known Limitations with Design

Functionality for P1XC devices that is currently supported by this component is only targeted for P1MC variants (not designed for P1HC variants).

UNIT TEST CONSIDERATION

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

Note: Terms and definitions from the source “Nexteer Automotive” take precedence over all other definitions of the same term. Terms and definitions from the source “Nexteer Automotive” are formulated from multiple sources, including the following:

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline EA4 01.00.01.docx	EA4 01.00.01
3	Software Naming Conventions.doc	1.0
4	EA4 Software Naming Conventions 01.01.00.docx	01.01.00

3 - MicroCtrlrSuprt Peer Review Checklists

Overview

Summary Sheet
Synergy Project
3rd Party Files
Integration Manual
Nexteer Source Code
MDD
PolySpace

Sheet 1: Summary Sheet

Rev 1.0

19-Apr-17

Peer Review Summary Sheet

Synergy Project Name:

Windows User: Intended Use: Identify which component is being reviewed. This should match the component short name and the middle part of the Synergy project name MicroCtrlrSuprt

Revision / Baseline:

Windows User: Intended Use: Identify the implementation baseline name intended to be used for the changed component when changes are approved. AR202A_MicroCtrlrSuprt_Impl_2.0.0

Change Owner:

Windows User: Intended Use: Identify the developer who made the change(s) being reviewed Lucas Wendling

Work CR ID:

Windows User: Intended Use: Identify the Implementation Work CR whose work is being reviewed (may be more than one) EA4#13868

3rd party delivery package identifier:

Intended Use: This is a reference to the identifier of the 3rd party delivery package(s) that the component was extracted/created from. Rationale: This will allow easier tracing back to 3rd party deliveries. N/A

Windows User: Identifiy which type of 3rd party component this is so as to provide appropriate review checklist sheets Component Type:

Windows User: General section for summarizing review comments or review notes. Review Checklist Summary:

Comments:

Sheet 2: Synergy Project

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

naming convention for 3rd Party Software Components

Project contains necessary subprojects

Yes

Comments:

Requires dependencies for

included header files

Project contains the correct version of subprojects

Yes

Comments:

General Notes / Comments:

LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:

Change Owner:

Lucas Wendling

Review Date :

07/20/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: 3rd Party Files

Peer Review Meeting Log (3rd Party File Review)

Quality Check Items:

Rationale is required for all answers of No

(e.g. component_bswmd.arxml) Component "autosar" folder contains autosar module description file from 3rd party delivery package

N/A

Comments:

(e.g. component_preo.arxml) Component "autosar" folder contains any relevant preconfiguration files from 3rd party delivery package(s)

N/A

Comments:

If needed as in the case with Renesas MCAL (e.g. MCALcomponent_bswmd_rec.arxml taken from Vector delivery) Component "autosar" folder contains any needed supplemental autosar module description file(s)

N/A

Comments:

Component "doc" folder contains all documentation related to this component from 3rd party delivery package

N/A

Comments:

Modifications from delivery to be reviewed (e.g. path changes) Component "generate" folder contains all external generation files from 3rd party delivery package

N/A

Comments:

Component "include" and "src" folder contains exact component files from 3rd party delivery package

Yes

Comments:

Tool generated headers contained in

include folder for P1XC devices

Component "make" folder contains any makefiles included from 3rd party delivery package

N/A

Comments:

1) All source and headers of component should be referenced in .gpj 2) Compiler settings may need to be tailored to source component (e.g. Renesas MCAL vs Vector BSWs) Component "tools" folder contains GHS project file with appropriate files referenced with appropriate compiler settings

Yes

Comments:

Should delete old existing files/directories from integration project and copy new ones into integration project May also contain logic for integrator user interaction if required. (e.g. selection of micro variant on MCAL) Component "tools" folder contains Integrate.bat with appropriate logic in it for integration into project

N/A

Comments:

Headers only in component, so no need

of integration batch file

For external generation and internal behavior definition for use with Vector Davinci tools. Typically only desired/needed for non-Vector developed components. This file should be copied as part of Integrate.bat. Components optionally contains settings xml file with appropriate contents

N/A

Comments:

Headers only in component, so no need

of settings xml file

General Notes / Comments:

LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:

Change Owner:

Lucas Wendling

Review Date :

07/20/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: Integration Manual

Peer Review Meeting Log (Integration Manual Review)

Integration Manual Name:

kzshz2: Intended Use: Identify which file is being reviewed Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form. MicroCtrlrSuprt Integration Manual.doc

Integration Manual Revision:

kzshz2: Intended Use: Identify which version of the integration manual has been reviewed. Rationale: Required for traceability between the MDD and review. Auditors will likely require this. 1

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches header

Yes

Comments:

Latest template used

Yes

Comments:

Change log contains detailed description of changes

Yes

Comments:

Changes Highlighted (for Integrator)

N/A

Comments:

Initial Version

General Notes / Comments:

LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:

Change Owner:

Lucas Wendling

Review Date :

07/20/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: Nexteer Source Code

Peer Review Meeting Log (Source Code Review)

Source File Name:

N/A

Source File Revision:

Windows User: Intended Use: Synergy version number of the file being reviewed. (Version number that Synergy displays on the checked out or unmodified file in the working project) N/A

Header File Name:

NxtrMcuSuprtLib.h (P1XC version)

Header File Revision:

Windows User: Intended Use: Synergy version number of the file being reviewed. (Version number that Synergy displays on the checked out or unmodified file in the working project) 1

MDD Name:

MicroCtrlrSuprt Module Design Document.docx

Revision:

Windows User: Intended Use: Synergy version number of the file being reviewed. (Version number that Synergy displays on the checked out or unmodified file in the working project) 1

Quality Check Items:

Rationale is required for all answers of No

EA4 Software Naming Convention followed:

Windows User: Intended Use: list version/revision of latest released EA4 Software Naming Conventions document. (Listing version of the EA4 Common Naming Conventions is not needed since it is called out by the Software Naming Conventions document) Version:

for variable names

Yes

Comments:

for constant names

N/A

Comments:

for function names

Yes

Comments:

for other names (component, memory

Yes

Comments:

mapping handles, typedefs, etc.)

Verified no possibility of uninitialized variables being

N/A

Comments:

written to component outputs or IRVs

All variables are declared at the function level.

N/A

Comments:

Synergy version matches change history

kzshz2: Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s). Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.

Yes

Comments:

and Version Control version in file comment block

Change log contains detailed description of changes

Yes

Comments:

(including any anomaly number(s) being fixed) and

Work CR number

Code accurately implements MDD

Yes

Comments:

Verified no Compiler Errors or Warnings

KMC: Intended Use: To confirm no compiler errors or warnings exist for the code under review (warnings from contract header files may be ignored). Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project should be used; QAC can find compiler errors but not warnings.

Yes

Comments:

(and verified for all possible combinations of any

conditionally compiled code)

Component.h is included

N/A

Comments:

All includes are actually needed. (System includes

Yes

Comments:

only allowed in Nexteer library components)

Software Design and Coding Standards followed:

Version: 2.1

Code comments are clear, correct, and adequate

Yes

Comments:

and have been updated for the change: [N40] and

all other rules in the same section as rule [N40],

plus [N75], [N12], [N23], [N33], [N37], [N38],

[N48], [N54], [N77], [N79], [N72]

Source file (.c and .h) comment blocks are per

Yes

Comments:

standards and contain correct information: [N41], [N42]

Function comment blocks are per standards and

Yes

Comments:

contain correct information: [N43]

Code formatting (indentation, placement of

Yes

Comments:

braces, etc.) is per standards: [N5], [N55], [N56],

[N57], [N58], [N59]

Embedded constants used per standards; no

N/A

Comments:

"magic numbers": [N12]

Memory mapping for non-RTE code

N/A

Comments:

is per standard

All execution-order-dependent code can be

Yes

Comments:

recognized by the compiler: [N80]

All loops have termination conditions that ensure

No

Comments:

There are intentional loop forever

finite loop iterations: [N63]

loops in this component after issuing software reset

All divides protect against divide by zero

N/A

Comments:

if needed: [N65]

All integer division and modulus operations

N/A

Comments:

handle negative numbers correctly: [N76]

All typecasting and fixed point arithmetic,

Yes

Comments:

including all use of fixed point macros and

timer functions, is correct and has no possibility

of unintended overflow or underflow: [N66]

All float-to-unsiged conversions ensure the.

N/A

Comments:

float value is non-negative: [N67]

All conversions between signed and unsigned

N/A

Comments:

types handle msb==1 as intended: [N78]

All pointer dereferencing protects against

Yes

Comments:

DET mechanism will check for

null pointer if needed: [N70]

bad pointers in this component

Component outputs are limited to the legal range

N/A

Comments:

No Outputs

defined in the design (MDD) : [N53]

All code is mapped with MDD (all MDD

Yes

Comments:

subfunctions and/or model blocks identified

with code comments; all code corresponds to

some MDD subfunction and/or model block): [N40]

Review did not identify violations of other

Yes

Comments:

coding standard rules

General Notes / Comments:

Note only P1XC version of header was reviewed under this peer review, as no changes were done to the P1M version.

LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:

Change Owner:

Lucas Wendling

Review Date :

07/20/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 6: MDD

Peer Review Meeting Log (MDD Review)

MDD Name:

MicroCtrlrSuprt Module Design Document.docx

MDD Revision:

1

Source File Name:

NxtrMcuSuprtLib.h (P1M version)

Source File Revision:

3

Source File Name:

NxtrMcuSuprtLib.h (P1XC version)

Source File Revision:

1

Source File Name:

Source File Revision:

Quality Check Items:

Rationale is required for all answers of No

Synergy version matches document

Yes

Comments:

Change log contains detailed description of changes

N/A

Comments:

Initial Version

Changes Highlighted (for Unit Tester)

N/A

Comments:

Initial Version

Diagrams have been included per MDD Guideline

Yes

Comments:

and reviewed

All Design Exceptions and Limitations are listed

Yes

Comments:

Design rationale given for all global

N/A

Comments:

data not communicated through RTE ports, per

Design and Coding Standards rules [N9] and [N10].

All Unit Test Considerations have been described

Yes

Comments:

General Notes / Comments:

LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:

Change Owner:

Lucas Wendling

Review Date :

07/20/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 7: PolySpace

Peer Review Meeting Log (PolySpace Review)

Source File Name:

NxtrMcuSuprtLib.h (P1M version)

Source File Revision:

3

Source File Name:

NxtrMcuSuprtLib.h (P1XC version)

Source File Revision:

1

Source File Name:

Source File Revision:

EA4 Static Analysis Compliance Guideline version:

01.02.00

Poly Space version:

Windows User: eg. 2013b 2013b

Quality Check Items:

Rationale is required for all answers of No

Contract Folder's header files are appropriate and

kzshz2: Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed. Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.

Yes

Comments:

function prototypes match the latest component version

100% Compliance to the EA4 Static Analysis

Yes

Comments:

Compliance Guideline

Are previously added justification and deviation

Yes

Comments:

comments still appropriate

Do all MISRA deviation comments use approved

Yes

Comments:

deviation tags

Cyclomatic complexity and Static path count OK

Creager, Kathleen: use Browse Function Metrics, STCYC and STPTH

Yes

Comments:

for all functions in the component per Design

and Coding Standards rule [N47]

General Notes / Comments:

Red polyspace errors for inifinite loops. This is acceptable since it is intended to have these after attempting to issue a software reset.

LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:

Change Owner:

Lucas Wendling

Review Date :

07/20/17

Lead Peer Reviewer:

Avinash James

Approved by Reviewer(s):

Yes

Other Reviewer(s):

4 - HeaderGen

Rev. 1.2

April 20th, 2016

Introduction

This document describes installation and usage of the C code header file generation script (HeaderGen) created by Renesas. The HeaderGen script is a Python based script that utilizes one external Python module for parsing Excel files. The purpose of the tool is to enable more configurable and consistent header file generation for our customers, as well as to provide some useful formatting options within the header files themselves.

Contents

1. Installation 1

2. Usage 2

2.1 Configuration File 2

Installation

The following tools are needed for execution of the Script

Python

v2.7.9

Visit the Python Install site and download the latest v2.x.x Windows version:

https://www.python.org/downloads/

openpyxl

v2.3.0

(1) Download easy_install from Windows from this link: https://bootstrap.pypa.io/ez_setup.py

(2) execute the file ez_setup.py:

>python ez_setup.py

(3) Navigate to C:\PythonXX\Script and execute

> easy_install openpyxl

.

Excel

2013

Script requires use of the .xlsx Excel file format

Table 1: Required SW Packages

Usage

Configuration File

The script takes as an input a text configuration file. Required fields in the file are:

Field	Description	Example
Input_file_name	Excel input file name and full or relative path	./dr7f701310_matrix_smaller.xlsx
Tab_name	Excel tab name with relevant data – typically “APB area2”	APB area2
Output_file_location	Location where the resulting header files will be written with full or relative path. NOTE: this is currently unsupported	./
Base_type_byte	Base type for byte variables	uint8
Base_type_short	Base type for short (two byte) variables	uint16
Base_type_long	Base type for long (four byte) type variables	uint32
Base_union_name_byte	Name for byte variable access within union of register access types	UINT8
Base_union_name_short	Name for short variable access within union of register access types	UINT16
Base_union_name_long	Name for long variable access within union of register access types	UINT32
Base_union_name_bits	Name for bit variable access within union of register access types. This will provide access to the bitfield structure.	BITS
[prefix] (sample text)	Anything following a line starting with [prefix] will be printed exactly at the start of the header file, after the inclusion guard #ifdef
[groups] (sample group)	By default, all register access structures, address binding pragmas, and access macros will be placed into the default output file. Adding a group to the configuration file will place any register whose name starts with the text following [groups] into a separate file. More than one piece of text can follow a group name, as shown in the example.	[groups] ADC_FILE = ADCD0, ADCD1 This will place all registers starting with either “ADC0” or “ADCD1” into an output file called dr7f701310_ADC_FILE.h, and cause them to skip the default header file. [groups] DEFAULT = This is the default group for all register information. It must be present in the configuration file. This will place all unmatched registers into an output file called dr7f701310_DEFAULT.h.
[suffix] (sample text)	Anything following a line starting with [suffix] will be printed exactly at the end of the header file, before the inclusion guard #endif
[skip] (address)	Only hexadecimal addresses are allowed to follow the [skip] tag. Any register whose address overlaps with this address will be placed into a group labeled “skip” and generate into a _SKIP.h file	[skip] DEADBEEF
use_module_names = <True/False>	Setting this argument to true will ignore all [groups] arguments and use the module column from the Excel file as register grouping names.	use_module_names = True
gen_address_macros = <True/False>	Setting this argument to true will generate macros for each register mapping their address to the register name followed by “_ADDR”	gen_address_macros = True

Table 2: configuration file entries

Execution

The script can be executed by issuing this command from the command line:

> python headerGen.py config.txt

Note: this assumes (1) the python executable has been added to your system path, and (2) the headerGen,py script and config file are resident in your current directory.

The script will print several informative messages to the command line as it runs. Because the Excel file for a typical micro is very large (>50,000 lines), the script can take up to 10 minutes to execute. It will print percentage complete status messages during long running sections.

You will see these messages when the command line script has completed:

Output

Figure 1: header file contents and usage

Revision Record

Rev.	Date	Description
Rev.	Date	Page	Summary
1.0	2/8/2016	All	Initial Draft
1.1	2/25/2016	Multiple	Adding support for multiple groups, marking output file directory config option as unsupported.
1.2	4/20/2016	Multiple	Adding support for register address macro generation as well as register grouping based on module name column from Excel

Testing

Due to the size of the input Excel file, it is not feasible for Renesas or a customer (user) of the script to test each of the registers generated. Therefore, we have identified a sub-set of registers that represent interesting register layout permutations for testing. As long as these registers have generated fine, we can assume that all other register, being of identical pattern to these registers, are fine as well.

The registers in the test suite are:

Number	Register size	Base access type	Bit access type	P1M example
1	8-bit	8-bit	8-bit	15.3.10 – SCI30BRR

NOTE: SCI30BRR and SCI30MDDR are allocated to the same address, so the script will parse this incorrectly.

2	8-bit	8-bit	< 8-bit, single	10.4.2 – CVMF


3	8-bit	8-bit	< 8-bit, multiple	16.3.2.1 – RLN30LWBR


3a	8-bit	8-bit, 1-bit	< 8-bit, single	14.3.2 – CSIH0CTL0


4	16-bit	16-bit	16-bit	13.3.10 – CSIG0TX0H


5	16-bit	16-bit	8-bit	16.3.3.18 – RLN30LUTDR


6	16-bit	16-bit	< 8-bit, single	13.3.6 – CSIG0STCR0


7	16-bit	16-bit	< 8-bit, multiple, cross byte boundaries	13.3.4 – CSIG0CTL2


8	16-bit	16-bit, 8-bit	16-bit

9	16-bit	16-bit, 8-bit	8-bit

10	16-bit	16-bit, 8-bit	< 8-bit, single

11	16-bit	16-bit, 8-bit	< 8-bit, multiple

12	32-bit	32-bit	32-bit	19.3.2 – RSENTT0TSC


13	32-bit	32-bit	16-bit	13.3.9 – CSIG0TX0W


14	32-bit	32-bit	8-bit	14.3.5 – CSIH0STR0


15	32-bit	32-bit	< 8-bit, single	7.9.2.1 – DMACTL


15b	32-bit	32-bit	< 8-bit, single, all 32-bits	7.9.2.13 – DTSPR0

Note: Excel and .pdf UM don’t match exactly, Excel shows these as 2-bit entries, while UM shows them as single bit entries that are clearly paired via name.

16	32-bit	32-bit	< 8-bit, multiple	7.9.2.9 – DM0CMV


16b	32-bit	32-bit	< 8-bit, multiple, crossing byte boundaries	11.3.5 – TSNREFD


17	32-bit	32-bit, 16-bit	32-bit

18	32-bit	32-bit, 16-bit	16-bit

19	32-bit	32-bit, 16-bit	8-bit

20	32-bit	32-bit, 16-bit	< 8-bit, single

21	32-bit	32-bit, 16-bit	< 8-bit, multiple

22	32-bit	32-bit, 16-bit, 8-bit	32-bit	18.2.7.12 – FLXA0FRNMV1


23	32-bit	32-bit, 16-bit, 8-bit	16-bit	18.2.6.2 – FLXA0FRSUCC2


24	32-bit	32-bit, 16-bit, 8-bit	8-bit	18.2.3.1 – FLXA0FRLCK


25	32-bit	32-bit, 16-bit, 8-bit	< 8-bit, single	18.2.2.1 – FLXA0FROC


26	32-bit	32-bit, 16-bit, 8-bit	< 8-bit, multiple, crossing byte boundaries	18.2.5.1 – FLXA0FRT0C


27	Multiple	32-bit, 16-bit, 8-bit		17.3.3 – RSCAN0C0CTR

28	Multiple	16-bit, 8-bit		16.3.3.2 – RLN30LBRP01

Note: The Excel file shows this split into two 8-bit named entries: LBRP0 and LBRP1, while the UM shows a single entry.