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

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

Software Component Implementation

Sub-Module Functions

Init:

None

Per:

None

Library/Server Runables

P1M Micro Variants

Protected Write APIs

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

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

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

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

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

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

Design Rationale

Processing

GLOBAL Function/Macro Definitions

GLOBAL Function #1

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

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

References