This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Nvm Proxy

1: NvMProxy_Design_Review
2: NvMProxy_Integration_Manual
3: NvMProxy_MDD

Nvm Proxy

Component Documentation

1 - NvMProxy_Design_Review

Overview

Summary Sheet
Davinci Files
Source Code
MDD
QAC
Integration Manual

Sheet 1: Summary Sheet

Rev 1.0

23-Jul-13

Peer Review Summary Sheet

Component Name:

kzshz2: Intended Use: Identify which component is being reviewed Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. NvMProxy

Component Revision:

kzshz2: Intended Use: Identify which component is being reviewed Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. FDD22_001.6

Change Owner:

kzshz2: Intended Use: Identify the developer who made the change(s) Rationale: A change request may have more than one resolver, this will help identify who made what change. Change owner identification may be required by indusrty standards. Lucas Wendling

Change Request ID:

10844

kzshz2: Intended Use: Intended to identify at a high level to the reviewers which areas of the component have been changed. Rationale: This will be good information to know when ensuring appropriate reviews have been completed. Modified File Types:

kzshz2: Intended Use: Identify who where the reviewers, what they reviewed, and if the reviewed changes have been approved to release the code for testing. Comments here should be at a highlevel, the specific comments should be present on the specific review form sheet. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. ADD DR Level Move reviewer and approval to individual checklist form Review Checklist Summary:

Reviewed:

X

MDD

X

Source Code

Data Dictionary

X

QAC

X

Integration Manual

X

Davinci Files

Comments:

Sheet 2: Davinci Files

Rev 1.0

23-Jul-13

Peer Review Meeting Log (Davinci Review)

Quality Check Items:

Yes

No

Rationale is required for all answers of No

Pre-review checklist for change owners

DCF: Latest StdDef imported

X

Comments:

DCF: Only StdDef Port types are used (if not

X

Comments:

add justification)

DCF: All unused definitions removed

X

Comments:

*Cfg.arxml.TT: Verfied Davinci Configurator imported the

X

Comments:

change correctly

kzshz2: Either a generic sandbox or a baselined integration project can be used to verify

*Cfg.h.TT: Verfied Davinci Configurator generates

X

Comments:

the configuration header(s) file correctly

kzshz2: Either a generic sandbox or a baselined integration project can be used to verify

Group-review for review board

All changed files have been compared against previous

X

Comments:

versions (If available)

kzshz2: Intended Use: Identify if previous version was compared and only the expected change(s) was present. This is for text files only, not binary or GUIs Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.

DCF:Automated validation check is performed

X

Comments:

DCF: Inputs/Outputs match names from requirements

X

Comments:

No I/O, service component.

DCF: Inputs/Outputs configuration paremeters

X

Comments:

No I/O, service component.

reviewed

kzshz2: Intended Use: All changed inputs have been reviewed to ensure configuration parameters (i.e. Buffered vs Direct read/writes) are correct. This includes signal grouping when signal consistency is required by the FDD

DCF: Sender/Reciever Ports type and default values

X

Comments:

No I/O, service component.

macth their corresponding ports (internal/external)

kzshz2: Intended Use: Identify if all the Sender/Reciever ports are compatibale with there connecting ports. Rationale: This will help to avoid errors when this component is being integrated into a project.

DCF: Ports prototype and default values

X

Comments:

No I/O, service component.

macth their corresponding ports (internal/external)

kzshz2: Intended Use: Identify if all the Server/Client ports are compatibale with there connecting ports. Rationale: This will help to avoid errors when this component is being integrated into a project.

DCF: Server runnable variables are using direct

X

Comments:

No I/O, service component.

read/writes

DCF: Runnable calling frequencies match requirements

X

Comments:

No Runnables, service component.

General Notes / Comments:

kzshz2: Intended Use: Identify who where 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. Group Review Level: There are four Design Review States that a document may have as follows: DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required. DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review. DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer. DR4 – The document has passed all peer reviews and is ready for release. Review Board:

Change Owner:

Lucas Wendling

Review Date :

12/03/13

Group Review Level:

DR4

Lead Peer Reviewer:

Kevin Smith

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: Source Code

Rev 1.0

23-Jul-13

Peer Review Meeting Log (Source Code Review)

Source File Name:

kzshz2: Intended Use: Identify which .asm, .c, or .h file is being reviewed Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form. Cd_NvMProxy.c

Source File Revision:

kzshz2: Intended Use: Identify which version of the source file is being review. Rationale: Required for traceability between source code and review. Auditors will likely require this. 7

Module Design Document Name:

kzshz2: Intended Use: Identify which version of the MDD this source file was written against. Rationale: Needed for traceability between source code and MDD NvMProxy_MDD_docx

MDD Revision:

kzshz2: Intended Use: Identify which version of the MDD this source file was written against. Rationale: Needed for traceability between source code and MDD 4

Data Dictionary Revision:

kzshz2: Intended Use: Identify which version of the Data Dictionary was referenced for ranges during the source file review. Rationale: Needed for traceability between source code and DD N/A

Quality Check Items:

Yes

No

Rationale is required for all answers of No

Telelogic Synergy version matches header

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.

X

Comments:

Change log contains detailed description of changes

X

Comments:

Code compared vs requirements (Document or Model)

kzshz2: Intended Use: Identify if previous version was compared and only the expected change(s) was present. Rationale: This is helpful in identifying unapproved (intended or mistaken) changes.

X

Comments:

Analysis performed for Divide by zero

kzshz2: Intended Use: To confirm this defensive coding strategy has been taken into consideration Rationale: Necessary since currently there is no place this is documented

X

Comments:

No divide operations

Naming Convention and Standard followed

kzshz2: Intended Use: To confirm the appropriate variable name formats have been used. Rationale: This is needed to confirm compliance until the QAC tool is updated to automate this check.

X

Comments:

Global Outputs (RTE/Non-RTE) Initialized

X

Comments:

No global outputs

No Compiler Errors verified

kzshz2: Intended Use: To confirm the appropriate variable name formats have been used. Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project may be required to confirm there are no errors until the QAC tool has been evaultated to determine if it can automate this check.

X

Comments:

All buffered outputs are written in every path

X

Comments:

No outputs

Type Casting and Fix Point Macros use reviewed

X

Comments:

Function prototype and passed parameters are

X

Comments:

consistent

General Notes / Comments:

kzshz2: Intended Use: Identify who where 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. Group Review Level: There are four Design Review States that a document may have as follows: DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required. DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review. DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer. DR4 – The document has passed all peer reviews and is ready for release. Review Board:

Change Owner:

Lucas Wendling

Review Date :

12/03/13

Group Review Level:

DR4

Lead Peer Reviewer:

Kevin Smith

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 4: MDD

Rev 1.0

23-Jul-13

Peer Review Meeting Log (MDD Review)

Module Name:

kzshz2: Intended Use: Identify which file is has been reviewed Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form. NvMProxy_MDD.docx

Module

kzshz2: Intended Use: Identify how many source files are being reviewed and trace it to the appropriate MDD. Rationale: Required for traceability between source code and MDD

1

of

1

MDD Revision:

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

Source File Revision:

kzshz2: Intended Use: Identify which version of the source file was this MDD written for. Rationale: Needed for traceability between source code and MDD 7

Data Dictionary Revision:

kzshz2: Intended Use: Identify which version of the Data Dictionary was referenced for ranges during the review. Rationale: Needed for traceability between source code and DD. Note: Maybe this should be moved to the Summary sheet since there is only one Data Dictionary Version for all changes N/A

Quality Check Items:

Yes

No

Rationale is required for all answers of No

Telelogic Synergy version matches header

X

Comments:

Change log contains detailed description of changes

X

Comments:

Changes Highlighted (for Unit Tester)

X

Comments:

High-level Diagrams have been reviewed (Section 2)

X

Comments:

All Design Exceptions and Limitations are listed

X

Comments:

Design Rationale understood captured appropriately

X

Comments:

General Notes / Comments:

kzshz2: Intended Use: Identify who where 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. Group Review Level: There are four Design Review States that a document may have as follows: DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required. DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review. DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer. DR4 – The document has passed all peer reviews and is ready for release. Review Board:

Change Owner:

Lucas Wendling

Review Date :

12/03/13

Group Review Level:

DR4

Lead Peer Reviewer:

Kevin Smith

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 5: QAC

Rev 1.0

23-Jul-13

Peer Review Meeting Log (QAC Review)

Module Name:

kzshz2: Intended Use: Identify which .c file is being analyzed Rationale: Required for traceability. It will help to ensure this sheet is not attached to the wrong design review form. Cd_NvMProxy.c

Source File Revision:

7

Module

1

of

1

Compliance Document Version:

N/A

QAC Tool Version:

8.1.1

kzshz2: Intended Use: Identify specific changes in results (new violation present, previous violation corrected, etc.). Changes to the version of the tool or the way the results were gathered should be described here also. This should be filled out prior to the review by the change owner. Rationale: Gives reviewers an what needs to be focused on. Forces the change owner to compare with previous results to catch any differences that may otherwise go unoticed Brief Summary of Changes (In Results or Tool):

Quality Check Items:

Yes

No

Rationale is required for all answers of No

All Results reviewed

X

Comments:

QAC version is correct and did not change (List version)

X

Comments:

Contract Folder's header files are appropriate

X

Comments:

100% Compliance to the MISRA Compliance Document

X

Comments:

General Notes / Comments:

kzshz2: Intended Use: Identify who where 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. Group Review Level: There are four Design Review States that a document may have as follows: DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required. DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review. DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer. DR4 – The document has passed all peer reviews and is ready for release. Review Board:

Change Owner:

Lucas Wendling

Review Date :

12/03/13

Group Review Level:

DR4

Lead Peer Reviewer:

Kevin Smith

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 6: Integration Manual

Rev 1.0

23-Jul-13

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. NvMProxy_Integration_Manual.docx

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

Quality Check Items:

Yes

No

Rationale is required for all answers of No

Telelogic Synergy version matches header

X

Comments:

Latest template used

X

Comments:

Change log contains detailed description of changes

X

Comments:

Changes Highlighted (for Integrator)

X

Comments:

General Notes / Comments:

kzshz2: Intended Use: Identify who where 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. Group Review Level: There are four Design Review States that a document may have as follows: DR1 – Un-reviewed document. The DR1 reviews usually require larger, cross functional review teams (i.e. Management, Hardware Engineering, etc.) It is usually advisable, but not required to include outside representation as well such as system engineers. It is up to the document owner to decide on the scope of the review, however, the peer group can decide that a re-review with additional team member is required. DR2 – The Document has previously passed through the peer review process, but requires design changes significant enough to require another group peer review. DR3 – The Document has passed group peer review but needs minor corrections that can be re-reviewed with the Lead Peer Reviewer. DR4 – The document has passed all peer reviews and is ready for release. Review Board:

Change Owner:

Lucas Wendling

Review Date :

12/03/13

Group Review Level:

DR4

Lead Peer Reviewer:

Kevin Smith

Approved by Reviewer(s):

Yes

Other Reviewer(s):

2 - NvMProxy_Integration_Manual

1 Dependencies 2

1.1 SWCs 2

1.2 Functions to be provided to Integration Project 2

2 Configuration 3

2.1 Build Time Config 3

2.2 Configuration Files to be provided by Integration Project 3

2.2.1 Da Vinci Config generation 3

2.2.2 Manual Configuration Changes 3

3 Integration 4

3.1 Required Global Data Inputs 4

3.2 Optional Global Data Inputs 4

3.3 Specific Include Path present 4

4 Runnable Scheduling 5

6 Compiler Settings 6

6.1 Preprocessor MACRO 6

6.2 Optimization Settings 6

7 Revision Control Log 7

Dependencies

SWCs

Module	Required Feature
NvM	NvM_WriteBlock() NvM_GetBlockStatus()
DiagMgr	NxtrDiagMgr#_ReportNTCStatus()
Crc	Crc_CalculateCRC16()

Module

Required Feature

NvM

NvM_WriteBlock()

NvM_GetBlockStatus()

DiagMgr

NxtrDiagMgr#_ReportNTCStatus()

Crc

Crc_CalculateCRC16()

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

NvMProxy_Init

NvMProxy_MainFunction

NvMProxy_WriteBlock

NvMProxy_WriteAll

NvMProxy_GetErrorStatus

NvMProxy_SetRamBlockStatus

Configuration

Build Time Config

Modules	Notes
None

Configuration Files to be provided by Integration Project

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC
NvMProxyConfigSet/NvMProxyBlock/NvmRamBlockDataAddressSecure	The symbol name of the secured buffer location for the block data NOTE: For blocks defined by PIM memory in the Rte, this parameter is the symbol name that Developer inserts into the NvM Ram block configuration parameter for the associated NvM block)	NvMProxy
NvMProxyConfigSet/NvMProxyBlock/InitBlockHandling	This parameter chooses the type of protection handling done on the block at initialization: None: No specific handling needed CRC16: Run a 16 bit CRC on the NvM block and check it against the CRC stored in the NvM block (last two bytes). Failures will trigger the fail action specified in the “InitCheckFailResponse” configuration Redundant: Run redundant storage check on the NvM block. The 1’s compliment of the block data is stored in the NvM block to protect against corruption. Failures will trigger the fail action specified in the “InitCheckFailResponse” configuration ZeroData: Ignore what is stored in NvM and always over-ride the NvM RAM buffer with zeros. This is useful for blocks that may be un	NvMProxy
NvMProxyConfigSet/NvMProxyBlock/InitCheckFailResponse	Defines the type of response to occur if the NvM block fails either the CRC16 or Redundant check at initialization: N/A: This should be chosen if the block doesn’t have CRC16 or Redundant InitBlockHandling turned on SetNTC_0x0A: This should be chosen to set NTC 0x0A (should be calibrated to a critical shutdown fault- F1) SetNTC_0x08_LoadROMDefaults: This should be chosen to set NTC 0x08 (should be calibrated to be a non-shutdown fault (F3) and mapped to a CTC that lights lamp). Also, default values will be loaded from FLASH memory at the symbolic location specified in the “ROMDefault_Or_NotificationFunction_Symbol” configuration parameter. SetNTC_0x08_CallNotificationFunction: This should be chosen to set NTC 0x08 (should be calibrated to be a non-shutdown fault (F3) and mapped to a CTC that lights lamp). Also, a user defined function will be called. The function name is to be specified in the the “ROMDefault_Or_NotificationFunction_Symbol” configuration parameter. SetNTC_0x07_LoadROMDefaults: This should be chosen to set NTC 0x07 (should be calibrated to be a non-shutdown fault (F3) and mapped to a CTC that does not light lamp). Also, default values will be loaded from FLASH memory at the symbolic location specified in the “ROMDefault_Or_NotificationFunction_Symbol” configuration parameter. SetNTC_0x07_CallNotificationFunction: This should be chosen to set NTC 0x07 (should be calibrated to be a non-shutdown fault (F3) and mapped to a CTC that does not light lamp). Also, a user defined function will be called. The function name is to be specified in the the “ROMDefault_Or_NotificationFunction_Symbol” configuration parameter. SetNTC_0x06_LoadROMDefaults: This should be chosen to set NTC 0x06 (should be calibrated to be a non-shutdown fault (F3) and not mapped to a CTC). Also, default values will be loaded from FLASH memory at the symbolic location specified in the “ROMDefault_Or_NotificationFunction_Symbol” configuration parameter. SetNTC_0x06_CallNotificationFunction: This should be chosen to set NTC 0x06 (should be calibrated to be a non-shutdown fault (F3) and not mapped to a CTC). Also, a user defined function will be called. The function name is to be specified in the the “ROMDefault_Or_NotificationFunction_Symbol” configuration parameter.	NvMProxy
NvMProxyConfigSet/NvMProxyBlock/ROMDefault_Or_NotificationFunction_Symbol	This parameter defines the symbolic name of the FLASH constant that contains the default values to load into NvM RAM if the block fails its CRC16 or Redundant check at initialization in the case of the “InitCheckFailResponse” parameter being either “SetNTC_0x08_LoadROMDefaults”, “SetNTC_0x07_LoadROMDefaults” or “SetNTC_0x06_LoadROMDefaults”. It defines the symbolic name of the notification function in the case of the “InitCheckFailResponse” parameter being either “SetNTC_0x08_CallNotificationFunction”, “SetNTC_0x07_CallNotificationFunction” or “SetNTC_0x06_CallNotificationFunction”. This parameter should be set to “NULL_PTR” if CRC16 or Redundant block initialization handling is not turned on.	NvMProxy
NvMProxyConfigSet/NvMProxyBlock/NvMRamGlobalShared	Set to “True” if the NvM block’s RAM is already in “Global Shared” memory. This avoids creating another buffer. This is typically the case for “TypeH” blocks and the EEPROM close check block.	NvMProxy
NvMProxyConfigSet/NvMProxyBlock/NvMBlockDescriptorRef	Reference to the NvMBlockDescriptor container that defines the NvM block linked to this proxy configuration.	NvMProxy
NvMProxyGeneral/ NvMProxyIncludes	This contains a list of project specific include files that need to be compiled into the NvMProxy	NvMProxy
NvMProxyGeneral/ FailureAPI	This should be set to the diagnostic manager’s API for setting faults. This should be set to the “ReportNTCStatus” API since it is called during initialization. It is configurable because the API depends on the application number. Typically this should be set to “NxtrDiagMgr10_ReportNTCStatus” (assuming Ap 10 is the ASILD application)	NvMProxy
DiagMgrConfigSet/DiagMgrEventParameter	This module needs four DiagMgr NTCs added to the configuration: NTC 0x0A, NTC 0x08, NTC 0x07, and NTC 0x06. These need to be configured as “DIAGMGR_EVENT_KIND_BSW”	DiagMgr

DaVinci Interrupt Configuration Changes

ISR Name	VIM #	Priority Dependency	Notes
N/A

Manual Configuration Changes

Constant	Notes	SWC
NVMPROXY_EXCLUSIVE_AREA_0	This exclusive are covers the areas of execution within the component that are operating on the request buffer. The buffer is operated on by the MainFunction and the WriteBlock functions. An appropriate level of protection must be employed to maintain exclusive usage of the buffer data.	SchM

Integration

The following import steps must be completed :

Place CBD project structure to appropriate integration folder
Execute the “Integrate.bat” script from the Tools directory of this component to perform the necessary integration steps:
1. The script creates the required directories in the integration project, “Generators/Artt/NvMProxy” and “Generators/Components/_Schemes/NvMProxy/bswmd”
2. The script then copies the required files from the CBD generate directory into the new directories.
If this is the first time integration, then perform the Davinci Configurator 3rd party component integration procedure.
Configure NvM proxy component per program needs
Generate NvM proxy and import generated Cd_NvMProxy_swc.arxml into davinci developer and map all NvM service needs on the blocks needing proxies to the NvM Proxy service component (instead of the NvM service component)

SPECIAL INTEGRATION NOTES:

NvM Block Sizes

If CRC16 protection is chosen on a block, the NvM configuration needs to be increased by “2” to hold the CRC. The CRC value will be stored in the last two bytes of the data block.
Similarly, if Redundant protection is chosen on a block, the NvM configuration needs to be doubled to hold the redundant data.
Because of compiler alignment restrictions, it is HIGHLY recommended to use the debugger in Code Composer to analyze the compiled size of the NvM block. This can be done by using the sizeof(<NvMRamShadowName>) in the expressions window. The resulting size shown should get the added “2” or doubling in the NvM Configuration.

NvM Configuration

The NvM configuration parameter “NvMRamBlockDataAddress” configuration for all blocks using the NvM proxy need to have “NvMP_” pre-pended to the normal name of the RAM shadow symbol. Please note that if the block is linked through Davinci Developer Per-Instance Memory Mapping, this name will automatically revert back (remove the “NvMP_”) every time the Davinci Developer project is saved and the block size may be reverted to the original size (without the added CRC size or doubling for redundant store).

ROM Defaults and Notification Functions

If “ROM defaults” or “Notification Functions” are configured via the “InitCheckFailResponse” parameter, it is up to the integration project to provide the ROM default data or the notification function named per the “ROMDefault_Or_NotificationFunction_Symbol” parameter. The ROM default option will use a blind memory copy, so it is important that the same NvM RAM Shadow datatype is used for ROM constant to ensure proper data alignment.

Required Global Data Inputs

N/A

Required Global Data Outputs

N/A

Specific Include Path present

Yes

Runnable Scheduling

This section specifies the required runnable scheduling.

Init	Scheduling Requirements	Trigger
NvMProxy_Init()	Must be executed after NvM driver has initialized the unsecured block data to be forwarded to the secured memory by this component.	Init

Runnable	Scheduling Requirements	Trigger
NvMProxy_MainFunction()	Run prior to NvM_MainFunction for minimal request processing latency	Same as NvM_MainFunction

.

Memory Mapping

Mapping

Memory Section	Contents	Notes
NVMPROXY_START_SEC_VAR_NOINIT_8		Typically allocated to application in which NvM driver resides. Not required to be allocated to Global shared memeory.
NVMPROXY_START_SEC_VAR_CLEARED_16		Must be allocated into Global Shared memory
NVMPROXY_START_SEC_VAR_CLEARED_UNSPECIFIED		Must be allocated into Global Shared memory
NVMPROXY_START_SEC_CODE
NVMPROXY_START_SEC_CONST_UNSPECIFIED

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

Usage

Table 1: ARM Cortex R4 Memory Usage
Feature	RAM	ROM

Non RTE NvM Blocks

Block Name
<NVM block used Non RTE functions >

Note : Size of the NVM block if configured in developer

RTE NvM Blocks

Block Name
<NVM block used in RTE functions >

Note : Size of the NVM block if configured in developer

Compiler Settings

Preprocessor MACRO

<Define all the preprocessor Macros needed and conditions when needed>.

Optimization Settings

<Define Optimization levels that are needed and conditions when needed>.

Revision Control Log

Rev #	Change Description	Date	Author
1	Initial version		JJW
2	Updates per generation definition	10/18/12	JJW
3	Updates for CRC and Redundant checking feature	12/02/13	LWW

3 - NvMProxy_MDD

Module -- NvM Proxy

High-Level Description

(Description must be within 8-10 lines.)

Figures

This diagram depicts the physical memory allocation for the various parts of the NvM Proxy system. 3 application RAM areas are shown for illustrative purposes, however, this module can handle any number of application RAM areas.

The memory stack components below the NvM are not shown in this diagram to promote clarity.

The NvMProxy_CmdQueue is required to be allocated to global shared memory to provide write access to the Proxy server function that is designed to be called from any application.

Diagram – NvM Data Initialization

Depiction of the Nv Data initialization sequence from the perspective of which application is active (i.e. MPU configuration at the time of operation execution)

Only pertinent initialization functions and steps are shown to promote clarity.

Diagram – NvM Runtime

Following is a depiction of the write Motor Position EOL calibrations via diagnostic service request. The MtrPos component is assumed to be running in the ASIL D application and its server runnable for processing an EOL motor cal write request is assumed to invoke the NvM_WriteBlock operation.

The lifelines in this diagram represent execution within the Os or an application. The details of the diagnostic service request are omitted from this diagram for clarity purposes.

Variable Data Dictionary

For details on module input / output variable, refer to the Data Dictionary for the application. Input / output variable names are listed here for reference.

Module Inputs	Module Outputs
Configured by NvMProxyCfg		None

Module Internal Variables

This section identifies the name, range and resolutions for module specific data created by this module. If there are no range restrictions on the variable, the term “FULL” is placed into the table for legal range.

Variable Name	Resolution	Legal Range (min)	Legal Range (max)	Software Segment
NvMPWriteRqst_Cnt_M_Str[D_NUMPRXYBLOCKS_CNT_U16]	See NvMPWriteBuff_Type	See NvMPWriteBuff_Type	See NvMPWriteBuff_Type	NVMPROXY_START_SEC_VAR_CLEARED_UNSPECIFIED
NvMPSetRBSRqst_Cnt_M_Str[D_NUMPRXYBLOCKS_CNT_U16]	See NvMPSetRBSBuff_Type	See NvMPSetRBSBuff_Type	See NvMPSetRBSBuff_Type	NVMPROXY_START_SEC_VAR_CLEARED_UNSPECIFIED

Variable Name

Resolution

Legal Range

(min)

Legal Range

(max)

Software Segment

NvMPWriteRqst_Cnt_M_Str[D_NUMPRXYBLOCKS_CNT_U16]

See NvMPWriteBuff_Type

NVMPROXY_START_SEC_VAR_CLEARED_UNSPECIFIED

NvMPSetRBSRqst_Cnt_M_Str[D_NUMPRXYBLOCKS_CNT_U16]

See NvMPSetRBSBuff_Type

NVMPROXY_START_SEC_VAR_CLEARED_UNSPECIFIED

User defined typedef definition/declaration

This section documents any user types uniquely used for the module.

Typedef Name	Element Name	User Defined Type	Legal Range (min)	Legal Range (max)
NvMProxyCfg_Type	NvMBlock	NvM_BlockIdType	0	FULL
	unsecurePtr	constant uint8* to variable data	NA	NA
	securePtr	constant uint8* to variable data	NA	NA
	secureSize	uint16	0	FULL
	initHandling	NvMProxy_InitHandling	See Datatype	See Datatype
	failResponse	NvMProxy_FailResponse	See Datatype	See Datatype
	failActData	NvMP_FailActionDataType	See Datatype	See Datatype
	failActFunc	NvMP_FailActionFuncType	See Datatype	See Datatype
NvMProxy_InitHandling	NVMPROXY_NONE	uint8	0	0
	NVMPROXY_CRC16	uint8	1	1
	NVMPROXY_REDUNDANT	uint8	2	2
	NVMPROXY_ZERODATA	uint8	3	3
NvMProxy_FailResponse	NVMPROXY_NOTAPPLICABLE	uint8	0	0
	NVMPROXY_NTC_0A	uint8	1	1
	NVMPROXY_NTC_08_ROMDEF	uint8	2	2
	NVMPROXY_NTC_08_NOTIFFUNC	uint8	3	3
	NVMPROXY_NTC_07_ROMDEF	uint8	4	4
	NVMPROXY_NTC_07_NOTIFFUNC	uint8	5	5
	NVMPROXY_NTC_06_ROMDEF	uint8	6	6
	NVMPROXY_NTC_06_NOTIFFUNC	uint8	7	7
NvMP_FailActFuncType	Pointer to void function	pointer	N/A	N/A
NvMP_FailActionDataType	Pointer to uint8	pointer	N/A	N/A
NvMPWriteBuff_Type	Pend	boolean	0	FULL
	BlkStatus	NvM_RequestResultType	0	FULL
	SrcPtr	uint8*	NA	NA
NvMPSetRBSBuff_Type	Pend	boolean	0	FULL
	BlockChanged	boolean	NA	NA

Constant Data Dictionary

Calibration Constants

This section lists the calibrations used by the module. For details on calibration constants, refer to the Data Dictionary for the application.

Constant Name
<None>

Configuration Constants

This section lists the configuration constants used by the module. For details on configuration constants, refer to the Module User Guide. The values are set by the integration project specific configuration files Cd_NvMProxy_Cfg.h and Cd_NvMProxy_PBcfg.c

Constant Name	Type
NvMProxyCfg [D_NUMPRXYBLOCKS_CNT_U16]	NvMProxyCfg_Type

Program(fixed) Constants

Embedded Constants

All embedded constants whose values are provided in Eng units will be evaluated to the equivalent counts by using the FPM_InitFixedPoint_m() macro within the #define statement.

Local

Constant Name	Resolution	Units	Value
D_NUMPRXYBLOCKS_CNT_U16	1	Count	Configured in integration project
NVMPROXY_EXCLUSIVE_AREA_0	NA	NA	Generated by SchM
D_CRC16SIZE_CNT_U16	1	Count	2

Global

This section lists the global constants used by the module. For details on global constants, refer to the Data Dictionary for the application.

Constant Name
<None>

Module specific Lookup Tables Constants

(This is for lookup tables (arrays) with fixed values, same name as other tables)

Constant Name	Resolution	Value	Software Segment
None

Functions/Macros used by the Sub-Modules

Library Functions / Macros

The library and functions / Macros that are called by the various sub modules are identified below,

Data Hiding Functions

NvM_WriteAll()
NvM_WriteBlock()
NvM_SetRamBlockStatus()
NvM_GetErrorStatus()
SchM_Enter_NvMProxy()
SchM_Exit_NvMProxy()

Global Functions/Macros Defined by this Module

NvMProxy_WriteAll

Function Name	NvMProxy_WriteAll	Type	Min	Max	UTP Tol.
Arguments Passed	None
Return Value	N one

Description

This function implements the AUTOSAR standard API for the NvM BSW WriteAll service. The interface must adhere to the AUTOSAR standard to allow mapping service port needs of SWC’s located in outside the QM application to this component’s service interface via the Rte.

NvMProxy_WriteBlock

Function Name	NvMProxy_WriteBlock	Type	Min	Max	UTP Tol.
Arguments Passed	Block	NvM_BlockIdType
	SrcPtr	uint8
Return Value	result	Std_ReturnType

Description

This function implements the AUTOSAR standard API for the NvM BSW WriteBlock service. The interface must adhere to the AUTOSAR standard to allow mapping service port needs of SWC’s located in outside the QM application to this component’s service interface via the Rte.

NvMProxy_GetErrorStatus

Function Name	NvMProxy_GetErrorStatus	Type	Min	Max	UTP Tol.
Arguments Passed	Block	NvM_BlockIdType
	RequestResultPtr	uint8*
Return Value	N one

Description

This function implements the AUTOSAR standard API for the NvM BSW GetErrorStatus service. The interface must adhere to the AUTOSAR standard to allow mapping service port needs of SWC’s located in outside the QM application to this component’s service interface via the Rte.

NvMProxy_SetRamBlockStatus

Function Name	NvMProxy_SetRamBlockStatus	Type	Min	Max	UTP Tol.
Arguments Passed	Block	NvM_BlockIdType
	BlockChanged	boolean
Return Value	N one

Description

This function implements the AUTOSAR standard API for the NvM BSW SetRamBlockStatus service. The interface must adhere to the AUTOSAR standard to allow mapping service port needs of SWC’s located in outside the QM application to this component’s service interface via the Rte.

Local Functions/Macros Used by this MDD only

Software Module Implementation

Runtime Environment (RTE) Initial Values

This section lists the initial values of data written by this module but controlled by the RTE. After RTE initialization, the data in this table will contain these values.

Data	Value
<None>

Initialization Functions

Init: NvMProxy_Init

Design Rationale

Transfer the data from the unsecured Nv Data memory buffer to the secured Nv Data memory buffer and initialize the block status shadow to the values returned by the NvM API.

Module Outputs

Module Internal

NvMPWriteRqst_Cnt_M_Str = 0*

NvMPSetRBSRqst_Cnt_M_Str = 0*

* Cleared by memory clear function and not explicitly cleared in this init function

Periodic Functions

Per: NvMProxy_MainFunction

Design Rationale

This function is responsible for forwarding the queued NvM requests to the NvM driver in a SchM task running the NvM BSW.

This function copies the secured data area to the unsecured data area.

Program Flow Start

None

Store Module Inputs to Local copies

None

Processing of function

Store Local copy of outputs into Module Outputs

None

Program Flow End

None

Fault Recovery Functions

None

Shutdown Functions

None

Interrupt Functions

None

Serial Communication Functions

None

Execution Requirements

Execution Sequence of the Module

NvMProxy_Init must be scheduled after to NvM_ReadAll is completed. Additionaly NvMProxy_Init must be executed as a trusted function to grant rights for initializing the secured memory. This would typically be accomplished via an Os trusted function call API.

NvMProxy_MainFunction should be scheduled prior to NvM_MainFunction. This provides the minimal amount of lag in forwarding and processing NvM service requests.

Execution Rates for sub-modules called by the Scheduler

This table serves as reference for the Scheduler design

Function Name	Calling Frequency	System State(s) in which the function is called
NvMProxy_Init	Once during startup	COLD INIT
NvMProxy_MainFunction	Same as NvM_MainFunction	Same as NvM_MainFunction

Execution Requirements for Serial Communication Functions

Function Name	Sub-Module called by (Serial Comm Function Name)
<None>

Memory Map Definition Requirements

Sub Modules (Functions)

This table identifies the software segments for functions identified in this module.

Name of Sub Module	Software Segment
NvMProxy_Init	NVMPROXY_START_SEC_CODE
NvMProxy_MainFunction	NVMPROXY_START_SEC_CODE
NvMProxy_WriteAll	NVMPROXY_START_SEC_CODE
NvMProxy_WriteBlock	NVMPROXY_START_SEC_CODE
NvMProxy_SetRamBlockStatus	NVMPROXY_START_SEC_CODE
NvMProxy_GetErrorStatus	NVMPROXY_START_SEC_CODE

Local Functions

This table identifies the software segments for local functions identified in this module.

Name of Sub Module	Software Segment
None

Known Issues / Limitations With Design

Revision Control Log

Item #	Rev #	Change Description	Date	Author Initials
1		Initial creation	21-Mar-12	JJW
2		Corrected anomaly 4437 in NvMProxy init routine	01-Mar-13	KJS
3			30-May-13	JJW
4		Added CRC and Redundant block checking ability	22-Nov-13	LWW

Nvm Proxy

Nvm Proxy

Component Documentation

1 - NvMProxy_Design_Review

Overview

Sheet 1: Summary Sheet

Sheet 2: Davinci Files

Sheet 3: Source Code

Sheet 4: MDD

Sheet 5: QAC

Sheet 6: Integration Manual

2 - NvMProxy_Integration_Manual

Dependencies

SWCs

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

Configuration

Build Time Config

Configuration Files to be provided by Integration Project

Da Vinci Parameter Configuration Changes

DaVinci Interrupt Configuration Changes

Manual Configuration Changes

Integration

Required Global Data Inputs

Required Global Data Outputs

Specific Include Path present

Runnable Scheduling

Memory Mapping

Mapping

Usage

Non RTE NvM Blocks

RTE NvM Blocks

Compiler Settings

Preprocessor MACRO

Optimization Settings

Revision Control Log

3 - NvMProxy_MDD

Module -- NvM Proxy

High-Level Description

Figures

Diagram – Function Data Sharing

Diagram – NvM Data Initialization

Diagram – NvM Runtime

Variable Data Dictionary

Module Internal Variables

User defined typedef definition/declaration

Constant Data Dictionary

Calibration Constants

Configuration Constants

Program(fixed) Constants

Embedded Constants

Local

Global

Module specific Lookup Tables Constants

Functions/Macros used by the Sub-Modules

Library Functions / Macros

Data Hiding Functions

Global Functions/Macros Defined by this Module

NvMProxy_WriteAll

Description

NvMProxy_WriteBlock

Description

NvMProxy_GetErrorStatus

Description

NvMProxy_SetRamBlockStatus

Description

Local Functions/Macros Used by this MDD only

Software Module Implementation

Runtime Environment (RTE) Initial Values

Initialization Functions

Init: NvMProxy_Init

Design Rationale

Module Outputs

Module Internal

Periodic Functions

Per: NvMProxy_MainFunction

Design Rationale

Program Flow Start

Store Module Inputs to Local copies

Processing of function

Store Local copy of outputs into Module Outputs