TSR Q&A Clarification Confirmation

Project Resource SW Version
77GHz Platform Gen1.2 Aditya Math -

Ashwin Bhat
Jagadish Belliraj
Suresh Chilumuri
Sowjanya Gollu
Sunilkumar Mangali
Vishal Vardhan
Vijayalaxmi S Ulvekar
Nagamani Vangara
Bhushan Telkikar
Usharani Honnavad
Sl No Section Module Requirement ID
1 General NA NA
2 General NA NA
SM Safety Processor PCO_SW_3391

3 13.1.4 - CPU

4 13.1.4 - CPU

5 13.1.6 - DMA

6 13.1.6 - DMA

7 13.1.14 - SPB
8 13.1.19 - PORT

9 13.1.23 - FPI

10 13.1.23 - FPI

11 13.1.13 - SMU

12 13.1.13 - SMU

13 13.1.13 - SMU
Diagnostic Fault
14 13.7.3.6 PCO_SW_3913
Management
Diagnostic Fault
15 13.7.3.6 PCO_SW_3915
Management
Diagnostic Fault PCO_SW_3912

16 13.7.3.6 Management PCO_SW_3920
17 General NA NA
SM Signal Processor
(SPU) - Software
18 13.2.3 PCO_SW_3564
Based Self Test
(SBST)
Diagnostic Fault
19 13.7.3.6 PCO_SW_3922
Management
Radar Signal
20 13.7.3.7 Processing and PCO_SW_3926
Detections
SM Signal Processor
(SPU) - Software
21 13.2.3 PCO_SW_3557
Based Self Test
(SBST)
SM Signal Processor
(SPU) - Software
22 13.2.3 PCO_SW_5325
Based Self Test
(SBST)
SM Signal Processor
(SPU) - Software
23 13.2.3 PCO_SW_3560
Based Self Test
(SBST)
Power Supply
24 13.1.1.2.4 PCO_SW_3377
Configuration
Fault Signaling
25 13.1.1.3.3.1 PCO_SW_3378
Protocol
26 13.1.1.3.3.3 Error out pin PCO_SW_3380

28 13.1.5 - SCU

29 13.1.5 - SCU
30 13.7.3.3 Normal Operations PCO_SW_3890
SM Signal Processor
(SPU) - Software
33 13.2.3 PCO_SW_3561
Based Self Test
(SBST)
36 13.7.3.1 Power-up PCO_SW_4146
37 13.7.3.1 Power-up PCO_SW_3873
38 13.7.3.1 Power-up PCO_SW_4174
39 13.7.3.1 Power-up PCO_SW_3856

40 13.7.3.1 Power-up PCO_SW_3857
PCO_SW_3859
41 13.7.3.1 Power-up
PCO_SW_3861
SM Signal Processor
(SPU) - Software PCO_SW_3563,
42 13.2.3 Based Self Test PCO_SW_3564
(SBST)
43 13.7.7.3 Data domain PCO_SW_3961

Time domain
47 13.7.7.4 PCO_SW_3967
Time domain
48 13.7.7.4 PCO_SW_3968
Time domain
49 13.7.7.4 PCO_SW_3970
Time domain
50 13.7.7.4 PCO_SW_3971
Time domain
51 13.7.7.4 PCO_SW_3973

52 13.1.11 - EMEM

53 13.1.11 - EMEM
54 13.6.2 Run-time BIST PCO_SW_3845

55 13.1.10 - RIF
SM Safety Processor
- DFLASH Error
56 13.1.7.1 PCO_SW_3431
Correction Code
(ECC)
SM Safety Processor
57 13.1.4.1 - CPU - CRC PCO_SW_3400
Instruction
SM Safety Processor
58 13.1.4.1 - CPU - CRC PCO_SW_3404
Instruction
60 13.1.16 - PMS
SM Safety Processor
- PMS - Die
61 13.1.16.4 PCO_SW_3484
Temperature
Monitoring
SM Safety Processor
- PMS - Die
62 13.1.16.4 PCO_SW_3486
Temperature
Monitoring
SM Safety Processor
- PMS - Die
63 13.1.16.4 PCO_SW_3487
Temperature
Monitoring
64 13.7.3.1 Power-up PCO_SW_3860
35 13.7.3.1 Power-up PCO_SW_3858
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
SM Radar Frontend PCO_SW_3616

57 13.3.3.9 - TX Power Monitor
Requirement
Generic
Generic
The Core SW shall verify the correct CPU Bus MPU configuration,
after initial SW initialization and every subsequent configuration
change.
Safety Manual Aurix v0.8:

ESM[SW]:CPU:BUS_MPU_INITCHECK
Note:
The definition of what a correct MPU should be is defined
elsewhere (e.g. SW Design Document).
The Core SW shall verify the correct CPU Bus MPU configuration,
after initial SW initialization and every subsequent configuration
change.
ESM[SW]:CPU:BUS_MPU_INITCHECK
Note:
The definition of what a correct MPU should be is defined
elsewhere (e.g. SW Design Document).
The Core SW shall check for a lost DMA transaction.
If the Core SW determines that the DMA error violates the safety,
the Core SW shall trigger an alarm.

ESM[SW]:DMA:ERROR_HANDLING
The Core SW shall detect SPB protocol errors and provide an error
handler to respond with an appropriate safe state.
On power up, the Core SW shall initialize all GPIO pins to a known
state.
The Core SW shall provide an FPI error handler to handle FPI

errors and trigger the appropriate SMU alarm.
On Power-up, the Core SW shall verify that the FPI related safety
mechanisms are functional.
The Core SW shall configure the SMU in Core and Standby mode
to provide 1) responses to all configured alarms, 2)HW
redundancy, and 3)BIST functionality for SMU.
On powerup, the Core SW shall verify the correct configuration of

the SMU.
On power-up, the Core SW shall check that the SMU register

alarm and alarm handlers are functional.
See TSR 7615 Register Monitor Test

ESM[SW]:SMU:REG_MONITOR_TEST
The Core SW shall log all faults to NVM

The Core SW shall log all asserts to NVM.
On power-up, the Core SW shall configure all fault reactions based

on configuration specified by the application SW.
Note:
The possible reactions are:
None - log fault only
Safe Comm - disable communication except for diagnostics
Safe Silent - disable all communication
Safe Silent FSP - disable all communication and enable FSP
Safe Reset - perform an application reset
Generic
Description:
The SPU0 configuration registers
shall be stored before the SPUx test and restored after the SPUx
test.
The Core SW shall ensure that the system transitions to the

correct safe state within a fault tolerant time interval of
FTTI_TIME_INTERVAL.
The Core SW shall perform plausibility checks on RF Detection

data before sending information to Feature/Application SW.
Rationale:
SW should not publish wrong/misleading information. For
example, if core sw is reporting incorrect detection information
based on mounting position.
The Core SW shall run a software based selftest to detect faults in

the SPU hardware and the interfaces between the SPU and the
Radar Memory.
Requirement:
The Core SW shall generate a fault upon failure of the execution of
the self-test patterns through SPU0 during the
DIAGNOSTIC_INTERVAL.
The Core SW shall generate a fault for the errors reported by the
SBST.
NOTE:
The Core SW will provide an error handler to disposition errors
reported by SBST.
If the indictated power supply mode configuration does not match

the flag settings (identified by PMSWSTAT.HWCFGEVR status flags),
the system shall transition to safe-silent.
On power-up, the Core SW shall configure the SMU to trigger the

error out pin based on the application specific configuration data
provided.
At power on or reset, if any alarms are configured for FSP safe off
reactions by the application SW, then the FSP0 error pin shall be
re-configured to be an open drain FSP configuration driven high.
On power-up, the Core SW shall test the error out pin by doing the
following:
Reading back the state of the error out pin and verifying its state.
Toggling the state of the pin and verifying that the CAN Tx is
enabled/disabled accordingly.
The Core SW shall configure ERU parameters and start external

request processing by the ERU according to handle external
interrupts.
The Core SW shall use the internal password protected safety

watchdog to monitor program flow.
The Core SW shall control and monitor the functional program
sequence for safety-relevant software parts.
The Core SW shall control and monitor the temporal program flow
for Core, Feature and Application SW (e.g. deadline monitoring
and run time budget monitoring for software parts relevant for
functional safety).
The Core SW shall verify that data transmission between the

software components on different cores/tasks is safe (i.e., Errors in
data transmission are detected) and in accordance with the ASIL
classification of the data being transmitted.
Description:
The EMEM: address range: 0x99000000 .. 0x9903FFFF, size: 256
KBytes shall be stored before the SPUx test and restored after the
SPUx test.
The Core SW shall evaluate the following conditions in order to
prove the MCU startup sequence executed correctly:
• verify that SCU_STMEM4, 5 checks do not report any fail found

by CHSW.
• verify that SCU_STMEM3, 6 indicate that CHSW was successfully

executed.
• check that the lockstep enable in SCU_LCLCONx.LSy (where y

identifies the lockstep-CPU) has been correctly configured.
• check that ALM0[0] (where x identifies the lockstep-CPU) does

not report a lockstep alarm.
• check that ALM1[0] (where x identifies the lockstep-CPU) does
not report a lockstep alarm.
• check that MC0_ECCD.UCERR register does not report

uncorrectable ECC errors and MC0_ECCS[4:0] is set to all one to
enable ECC error handling.
• for all SRAM used by the Application, check MCi_ECCD.UERR = 1

and MCi_FAULTSTS.OPERR[0]= 1 (i = SRAM instance).
• for all CPU and LMU SRAM used by the Application, check that
MCi_FAULTSTS.OPERR[3] matches the corresponding setting of
PROCONRAM RAMINSEL and LMUINSEL bitfields.
ESM[SW]:SYS:MCU_FW_CHECK
If an Error is detected in the initialization of any safety mechanism

then the system shall raise a fault and transition to Safe Silent.
If an Error is detected in the MCU startup sequence, the system

shall raise a fault and transition to Safe Silent.
On power-up, (Immediately after PORST is released), the Core SW

(bootloader) shall be started on CPU Core 0 while all other CPUs
are held in halt state.
On power-up, the Core SW (Bootloader) shall be booted from a
lockstep core.
On power-up, the Core SW (Bootloader) shall enable the ECC

(Error Code Correction) functionality on the Aurix processor.
On power-up, The Core SW shall verify ECC (Error Code

Correction) is enabled on the Aurix processor.
The EMEM configuration registers shall be stored before the SPUx

test and restored after the SPUx test.
The SPU0 configuration registers shall be stored before the SPUx
test and restored after the SPUx test.
The Core SW shall partition all available memory in the sensor into
the following regions:
SAFE_DATA (ASIL B)
CORE_DATA (ASIL B)
AFT_DATA (QM or ASIL B)
SHARED_DATA (QM or ASIL B)
Note: Due to safety concerns, the application and feature teams

have a predefined memory allocation
The Core SW shall define the memory map for the sensor
(including Core, Feature and Application SW).
This includes.
Number of sections
Naming conventions
Access rights for each section
The safety related Core SW Tasks shall have R/W access to

SAFE_DATA, CORE_DATA and Shared_DATA and READ_ONLY access
to AFT_DATA.
The Application and Features SW related tasks shall have R/W

access to AFT_DATA and Shared_DATA and READ_ONLY access to
CORE_DATA and SAFE_DATA.
The Core SW shall enable timing protection attributes in the RTOS
for all Tasks and ISRs.
The Core SW shall monitor the cycle time and execution budget of
each periodic OS Task.
Note: execution budget deals with the amount of time a TASK is

allowed to block a Category 2 ISR.
The Core SW shall monitor CPU idle time.

Note:
Most systems do not want 100% CPU utilization since there is
always need for future growth.
With non-periodic background tasks in Gen1.2 the CPU idle time is
typcially zero.
The Core SW shall publish the run time measurements via the
interfaces available.
The Core SW shall raise a timing fault if a task or ISR misses its
time deadline.
On power-up, the Core SW shall configure the EMEM and access

to EMEM.
The Core SW shall calculate CRC for the EMEM data and store the
CRC value with the EMEM data.
Once per DIAGNOSTIC_INTERVAL, the Core SW shall execute the
Software Based Self Test (SBST) of the SPUs.
See Aurix TC39x Safety Manual v0.8

SM[SW]:SPU:SBST
Rationale
The SPU Software Based Self Test (SBST) detects random hardware
faults in a non-lockstep SPU. SBST should be executed cyclically, at
least once in a diagnostic test interval. SBST is a non-destructive
test designed to preserve the state of the SPU, therefore SBST can
be used cyclically during runtime. SBST is a measure against
permanent faults to support the single point fault metric.
After power-on, the Core SW shall enable the RIF to generate an

interrupt and provide an ISR to handle radar data CRC check
failures.
NOTE:
SMC[SW]:RIF:INIT_ERROR_HANDLING
The Core SW shall provide a robust algorithm for DFLASH usage to

protect against word-line failures.
NOTE:
The DFLASH with its TECQED ECC algorithm protects perfectly
against bit or bit-line oriented failures. The ECC mechanism does
not protect against wordline oriented failures.
On power up, during initialization, the Core SW shall verify that

the CPU CRC instruction is functioning correctly using a known
test data vector
After OS starting, the Core SW shall configure the tasks related to

Application & Feature SW to have User Mode 0 privilege.
NOTE:
If a task is not to access peripherals, the task should be configured
with CPU privilege level user mode 0 access protection. Tasks
configured for user mode 0 cannot enable or disable interrupts.
The Core SW shall generate a fault if the temperature difference
between the Aurix DIE temperature and the core temperature is
greater than 3degC.
The Core SW shall monitor the Radar Frontend temperature and

generate a fault if the temperature exceeds the supported
operational range.
In case the device die temperature exceeds the specified

temperature range an interrupt / SMU trigger shall be generated.
The Core SW shall generate a fault and activate Safe_Silent if the

temperature exceeds specified limits.
On power-up, the Core SW shall ensure Lockstep of the boot core

(CPU0) is active
On power-up, the Core SW (Bootloader) shall enable the Lockstep

safety mechanism on CPU0, CPU1.
Note CPU2 is a non-lockstep core and does not require lock step
processing enabled.
On start-up, as part of Radar Frontend initialization, the Core SW
shall enable the TX Power monitoring of the Radar Frontend for all
available TX channels.
NOTE:
This test is enabled using the
AWR_MONITOR_TX[n]_POWER_CONF_SB API.
The values for n = 0,1,2
Question Question date Raised by
Is Safe Silent mode nothing but a Stand By mode?
Please provide reference doc if available. 6/13/2018 Aditya Math
Need information regarding the Error Out Pin and its Modes
6/14/2018 Aditya Math
Req: Check CPU bus MPU configuration is correct or not.
Ques: for this memory mapping architecture is needed and how
to check particular memory region is protected or not.
6/18/2018 Jagadish
is this possible to change CPU bus MPU configurations
6/18/2018 Jagadish
loss of DMA transaction can be found using TIMESTAMP written in

Aurix v0.8 but in design document TIMESTAMP function is unused
function. 7/2/2018 jagadish
"violates the safety" what it is mean ?
7/2/2018 Jagadish
Separate Design documents and source code not found for

TSR_8410 (SM Safety Processor - SPB)
7/6/2018 Ashwin
What is meant by known state?
7/12/2018 Sowjanya
Design documents and source code not found for FPI Module(SM
Safety Processor - FPI) 7/16/2018 Suresh Chilumuri
Design documents and source code not found for FPI Module(SM
Safety Processor - FPI) 7/16/2018 Suresh Chilumuri
1) 'Design documents and source code not found for "HW
redundancy" and also for standby mode in PCO_SW_3457
7/17/2018 Ashwin
Is there any difference between the requirement of 1st element

of PCO_SW_3457 and PCO_SW_3841 requirement (Both the
requirements are saying about the configuration of the SMU) 7/17/2018 Ashwin
Below explanation is missing in the Source code but there only in

the Safety Manual Aurix v0.8:
ESM[SW]:SMU:REG_MONITOR_TEST-----
a. set a related bit in RMCTL register to check a particular
functional block
b. check REGISTER_MONITOR test execution time .
c. Check that the test execution time does not exceed expected
value.
d. Check self-test results by reading RMEF 7/17/2018 Ashwin
NA
7/17/2018 Ashwin
NA
7/17/2018 Ashwin
Requirement for below fault reactions is not present in the code:

Safe Silent - disable all communication
Safe Silent FSP - disable all communication and enable FSP
None - log fault only
7/19/2018 Ashwin
Please let us know the code implementation status for SPU.
7/18/2018 Sowjanya
What is SPUx test?
7/18/2018 Sowjanya
Time related variable fault tolerant time interval (FTTI) is not

present in the code
7/18/2018 Ashwin
Sending information to Feature/Application SW is not present in

the code for the plausibility checks
7/19/2018 Ashwin
How to check for software based selftest and interfaces between

the SPU and the Radar Memory?Any particular Fault is raised?
7/18/2018 Sowjanya
Where is this variable "DIAGNOSTIC_INTERVAL" is defined?
7/18/2018 Sowjanya
Please provide the reference in design for this requirement?
7/18/2018 Sowjanya
Requirement is not implemented. The Start Up CSC should call the

IfxPMS
Function Call for PES activation is not implemented at the Start Up
Function Call for Error out pin config is not implemented at the
Start Up
Please provide CAN database which handles the error out pin
enable/disable
It's mentioned that "currently ERU feature is not being used."

Please clarify
Internal password protected safety watchdog should be used only

at the start up or for every entry point to the particular functions?

Please provide the details of Order of the Safety related Tasks to
be executed
Please provide more information on the deadline monitoring and

run time budget monitoring.
Please provide more information on the ASIL classification of the

data transmission
Please provide more information on SPUx test
7/18/2018 Sowjanya
3rd point-- SCU_LCLCONx.Lsy is just defined no where called and
no function definition
4th & 5th point- not clear
7th point -- MCi_ECCD.UERR = 1 and MCi_FAULTSTS.OPERR[0]= 1

is just defined but no where called and no function definition
8th point -- PROCONRAM RAMINSEL and LMUINSELis just defined

but no where called and no function definition
7/25/2018 Jagadish
code is not implemented for "Safe Silent"
7/25/2018 Jagadish
dummy function used … cant able to find the code

and "Safe Silent" function is not implemented
7/25/2018 Jagadish
COLD reset, WARM reset ,system reset, application reset , module

reset -
1)on which reset mode the SW should start?
2)NO proper design document for bootloader. 7/25/2018 Jagadish
3)not able to find the code for this requirement
1)No proper design document for bootloader
2) not able to find the code for this requirement 7/25/2018 Jagadish
1) ECC enable for which module ?

2) ECC functionality means ECC working process?
If it is ECC working process no where code found
7/25/2018 Jagadish
It’s mentioned that SPUx test. Is it Software Based Self Test or

Lockstep Self Test or any other test.
7/25/2018 Vishal
1)where I can find the partition of Memory regions in code?

2)what is the range for the each partition?ex: SAFE_DATA range
7/26/2018 SunilKumar Mangali
1)Where the memory map is defined for the sensor (including

Core, Feature and Application SW) and
Number of sections
Naming conventions
Access rights for each section 7/26/2018 SunilKumar Mangali
1)As per requirements, R/W access is available for Safety related

tasks what is meant by Safety related Tasks
2) what is meant by Non Safety related Tasks
1)What are the Tasks allocated for Application and Features

1)what are the timing protection attributes that needs to be
enabled in RTOS 7/26/2018 SunilKumar Mangali
1)What is Execution budget time where I can find the code?
1)Where I can check the CPU Idle time in Code ?

2) As per Requirement the CPU Idle time is zero for Non periodic
background but what is the CPU Idle time for Periodic background
Taks 7/26/2018 SunilKumar Mangali
1) How we can verify that the Run Time measurements got

Published?
2) What are the interfaces is available to test?
1) Where I can find the deadline Time ?
ESM[SW]:EMEM:INIT_EMEM' is a changed to
'ESM[SW]:EMEM:READ_CONFIGURATION' in AURIX TC3xx Safety
Manual v0.9. 'ESM[SW]:EMEM:INIT_EMEM' has its own
discripton in 'AURIX TC3xx Safety Manual v0.8'. Since both are
separate requirements mentioned in doors but according to AURIX 7/12/2018 Vishal
TC3xx Safety Manual v0.9 both are same so what shall we
consider here?
in 'AURIX TC3xx Safety Manual v0.8'

--ESM[SW]:EMEM:DATA_INTEGRITY-- In case ASIL-D high integrity
data are stored in the
EMEM, the Application SW shall use EMEM CRC and 7/12/2018 Vishal
store it together with data. Here ASIL-D is being considered hence
is this applicable?
Need more clarification on the requirement.Is it cyclic,If so it
should be called from Task?
Please confirm whether functionality isimplemented?
8/1/2018 Sowjanya
RIF design document says IfxRif_Rif_isrError( ) &

IfxRif_Rif_isrInterrupt( ) functions are unused.
It is to be tested or not? 7/6/2018 Jagadish
Need clarification on TECQED ECC algorithm ? Cannot find any info

in code and design doc .
7/6/2018 Jagadish
what is known test data vector? No where found in design

document as well in code 7/12/2018 Jagadish
did not understand the requirement (need clarification)
generic requirement
7/12/2018 jagadish
Code is not implemented for checking the difference between the
temperature values
In diag_temp_monitor.c file, the code is implemented for

generating the fault for DTS but not for Radar Frontened
Temperature 8/8/2018 SunilKumar Mangali
To Generate the SMU trigger for temperature, the function

"IfxSmu_setAlarmStatus(alarm)" it has to call in the
diag_temp_monitor.c file, but it is not calling in the file
In diag_temp_monitor.c file, the code is not implemented for

generating the fault and Safe_Silent for Radar Frontened
Temperature
comment: no where function in code , only macro is defined in

code 7/25/2018 Jagadish
key: LSEN0 register
comment: no where function in code , only macro is defined in

code
key: LSEN0, LSEN1 register
7/25/2018 Jagadish
SM Radar Frontend - (PCO_SW_3616) :TX Power Monitor: How to
enable TX0, TX1 and TX2 Power configuration as per the
requirement
9/5/2018 Suresh Chilumuri

Reference Document Answer Answer date
Refer to '77GHz Platform FuSa Concept' 6/15/2018
FSC_8543
Refer to '77GHz Platform SW Reqs - Core' 6/15/2018
TSR_9068
AURIXTC3XX_ts_part1_V2.5.1 We can check the protection register values 8/2/2018

Section --->5.3.4.17
It is possible change CPU bus MPU configuation 8/2/2018

but as a tester we should not do
Need to check DMA transaction completes with

error or without error may suits this 8/14/2018
requirement. We need to send to Steeve for
rewording the requirement.
We need to send to Steeve for rewording the 8/14/2018

requirement. In doors it is under SME review
No design documents and code There are none yet 8/14/2018

Known state is nothing but either the state
defined by the project or defaultly by the
controller. We can read the GPIO configration
registers after reset and confirm. 8/2/2018
Module_Init_Core0= contains initialization of all
GPIO's. Read IOCR register to know the GPIO
configuration done by code.
There are none yet 8/14/2018
There are none yet 8/14/2018
C:\Sandbox\Checkpoints\Tricore\Cor
e_Library_20.10\SW\Common\Suppli
ed_SW\ILLD\iLLD_1_0_1_4_0_TC39B
\Src\BaseSw\iLLD\TC39B\Tricore\Sm HW redundancy is due to the 2 SMUs: Core & 8/14/2018
u\Smu Standby
C:\Sandbox\Checkpoints\Tricore\Cor Yes, there is. One is to configure and other is

e_Library_20.10\SW\Core_SW\Diagn verify configuration. 8/14/2018
ostic_Manager\source (diag_bist.c)
Register monitoring and register monitor test

code needs to be developed.
C:\Sandbox\Checkpoints\Tricore\Cor Comments from Nagamani:
e_Library_20.10\SW\Common\Suppli ifxSMU.h file
ed_SW\ILLD\iLLD_1_0_1_4_0_TC39B IfxSmu_setRegMonTestModeEnable() 8/14/2018
\Src\BaseSw\iLLD\TC39B\Tricore\Sm IfxSmu_clearRegMonTestModeEnable()
u\Std (IfxSmu) These functions are used to start the test and
stop the test. But not called from anywhere in
code.
Generic need to make it as non-functional requriment 8/14/2018

Generic need to make it as non-functional requriment 8/14/2018
e_Library_20.10\SW\Core_SW\Diagn
ostic_Manager\source
(TestGuardian.c)
[SA] Is this status for the SPU SBST? The code is 8/29/2018
currently in collaborator review.
e_Library_20.10\SW\Core_SW\Diagn
ostic_Manager\source
(TestGuardian.c)
Generic Still under discussion with SME 8/29/2018
[SA] The SBST code is currently in collaborator 8/29/2018

review.
DIAGNOSTIC_INTERVAL is defined as 50ms in 7/30/2018
DOORS
[SA] Should a Fault 9. Event number to be 8/29/2018

defined.
[SA] This requirement should be reworded to say 8/29/2018

generate a fault instead of safe silent.
[SA] This requirement is marked for deletion by 8/29/2018

SME in doors.
[SA] To be clarified by SMEs. Most likely be 8/29/2018

deleted.
[SA] The ERU is currently being used to process

Design Document: the SPI IRQ between the MMIC and Aurix. See
Gen1_2_IfxScu_Design.docx Section 8/29/2018
function RFC_Init_Interrupts_AR1243() in
3.1 "rfc_drv_ar1243.c"
[SA] They should be used anytime access to

Special Function Registers (SFRs) is required. The
program flow mentioned here is for when these 8/29/2018
SFRs can be accessed. There is SafetyEndInit,
EndInit etc.
[SA] Comment by SME in DOORs says to move 8/29/2018
the requirement to L20.


I think the verification of LSy is not implemented
currently. 4th & 5th point mean that the SMU
alarms ALM0 & ALM1 will be checked for the 7/30/2018
presence of Lockstep alarms. Look under
IfxMtu.c for item 7. Not sure if item 8 is
implemented. Ask Janin Rider for details.
e_Library_20.10\SW\Core_SW\Diagn Please look at Test Guardian Code and design 7/30/2018
ostic_Manager\source document. Safe Silent = Safe CAN OFF
(TestGuardian.c)
C:\Sandbox\Checkpoints\Tricore\Cor Code is implemented. Please check for code that

e_Library_20.10\SW\Core_SW\Diagn sets the fault event numbers under the 7/30/2018
ostic_Manager\source ERR_SENS_HARDWARE_FAILURE_INTEGRITY_BIS
(TestGuardian.c) T fault.
This should be on Cold System, & Application

Reset. Code is implemented in Ifx_Ssw_TC0. The
No design documents and code assembly function, which runs internally will look 7/30/2018
for _START symbol. So you can start tracing code
through that point in this file.
Same as above. Probably can be a Non functional
No design documents and code 7/30/2018
reqt.
ECC is enable for all Aurix internal memories. This

No design documents and code is done as part of running MBIST. Check 7/30/2018
Ifx_Ssw_TC0 for MBIST
This is Software Based Self Test for SPU 0 & SPU1.

SPUx implies for all SPUs present. In this case 'x' 7/30/2018
is 0 & 1
[SA] MPU implementation still ongoing. Will have

major edits based on SME review.
[SA] Suggest making it a non-functional

requirement.
[SA] Requirement reqorded by SME.

Implementation status not available.
[SA] SME reworded and made it to a non-

functional requirement.
No design documents and code [SA] SME marked requirement obsolete. 8/29/2018
No design documents and code [SA] This requirement is in TBC state. 8/29/2018
[SA] Check for Keepalive in

Gen1_2_Core_Diag_Manager_CSC.pptx
[SA] You should go by the V0.9 safety manual.

The 2 requirements still make sense as the
in 'AURIX TC3xx Safety Manual v0.8' 8/29/2018
language in the safety manual v0.9 has 'and' that
means 2 requirements.
[SA] As it is for ASIL D it is not applicable and

in 'AURIX TC3xx Safety Manual v0.8' 8/29/2018
should be marked obsolete
Function name: static void [SA] Yes it is a cyclic task but it will be called from
__Core0_startPhase4(void) the background task. Code is currently under 8/29/2018
File Name: Ifx_Ssw_Tc0 review.
[SA]Functionality currently not implemented. 8/29/2018

Will be done by mid-September.
[SA] Requirement in under SME review and

bound to change. FYI, test vector can be any 8/29/2018
data set for wich the CRC value is known.
[SA] Requirement in under SME review and 8/29/2018

bound to change.
[SA] Based on the new safety manual V0.9, the
temperature difference is 9degC. Code is 8/29/2018
currently implemented and checked into PTC
under diag_temp_monitor.c
[SA] Code is currently implemented and checked

into PTC. Necessary DDs and architecture PPTs 8/29/2018
are also updated.
[SA] DTS and DTSC limits are set at -42 & 146 deg
C. If temperature exceeds these limits, SMU
alarm will be generated. Code is currently in 8/29/2018
review and expected to be checked in PTC by end
of this week.
[SA] Temperature monitoring of bot Aurix and

Radar Frontend is complete. See
77GHz_Gen1_2_Sensor_Fault.ppt (Fault 1 for 8/29/2018
more information). The requirement is probably
reworded to remove reference to Safe Silent.
Core SW will only generate fault.
ref: aurix 2.5.1 and Os_StartCores.c This should be marked redundant as it will be 7/30/2018
file covered in 4146.
ref: aurix 2.5.1 and Os_StartCores.c This should be marked obsolete. Lockstep is
enabled by Aurix Startup SW (aka its Firmware), 7/30/2018
file which is not our SW development responsibility.
File Neme:
AWR1xxx_Radar_Interface_Control.p
df
Answered by State Comment
Vijayalaxmi Closed NA
Vijayalaxmi Closed NA
1) CPU0_PSW.PRS contains information about CPU bus

MPU configuration.Code implementation status is
required.MPU configuration is also required to compare.
Nagamani Open 2)Need code implementation status.
Nagamani: Start up design document is there
8/29/2018 Jagadish : No inputs are available in the
startup design document.
Nagamani Closed NA
Satyajit Open Code implementation status is needed

Adhyapak
1)Should we check all the possible DMA errore with their

maturity time?
Satyajit Open 2)Which alarm has to be mapped for this requirement?
Adhyapak (77GHz_Gen1_2_Sensor_Fault)
3)Need code implemenation status
Need sour ce code and design document implementation

Satyajit status
Open
Adhyapak Satyajit: SPB protocol will cover in SPU errros, need to
check SMU design document
Nagamani: pin mapper design document will have details
Nagamani Closed of PIN configuration
Need code implementation Status?

Satyajit Open [SA] Check diag_smu.c for generation of SMU alarms
Adhyapak related to FPI errors.
Satyajit Satyajit: SMU_diagnostics_manager will have the related
Open
Adhyapak code.
1)Core and Standby are they Core running and core stand
by mode?
2)How to achieve HW redundancy ?Need code and
Satyajit Open design implementation status?
Adhyapak Satyajit: There are two SMU's one is main(core) SMU,
stand by SMU. Need to check whether stand by SMU is
working fine when main SMU is faulty
Satyajit Closed NA
Adhyapak
Need source code implementation status

Satyajit [SA] Currently in implementation in progress. Core review
Open
Adhyapak is complete sho checkin to PTC shortly. Check diag_bist.c
for details.
Need to test for all faults with all events or testing few
Satyajit Closed faults are sufficient?
Adhyapak 9/5/2018 Viji : Requirement marked as Non-Functional.
Need to test for all asserts ws or testing few asserts are
Satyajit sufficient?
Closed
Adhyapak Nagamani: need to make it as non-functional requriment
9/5/2018 Viji : Requirement marked as Non-Functional.
The naming convention in the implemnetation

and the requirement are not matching. Please check
Open once.
Safe silent FSP -Still underdevelopment
SafeCAN off - safe silent

Open Sowjanya: By end of this week will check and comeback
Sowjanya: Code is not implemented.

Satyajit Sowjanya: By end of this week will check and comeback
Open
Adhyapak Sowjanya: Please let us know what is SPU test?We have
to check for SBST?
FTTI is not defined in the code.

Open Please give some reference if it is implemented
Satyajit: Will check and relpy back
Please let us know the status of

design and code implementation status.
9/5/2018 Viji : 9/5/2018 Viji : Requirement moved to
Satyajit Closed 'Move' state. No need to verify.
Adhyapak

Satyajit Open Sowjanya: By end of this week will check and comeback
Adhyapak Sowjanya: Code is not implemented.
Satyajit Closed NA
Adhyapak
This fault is referred in 77GHz_Gen1_2_Sensor_Fault.ppt?

Satyajit If so what is the fault number?
Open
Adhyapak Sowjanya: By end of this week will check and comeback
Sowjanay: Code is not implemented.
Requirement is not implemented. The Start Up CSC

Satyajit should call the IfxPMS
Closed
Adhyapak 9/5/2018 Viji : Requirement has been updated.
Function Call for PES activation is not implemented at the

Start Up
Satyajit Closed 9/4/2018 Viji : This requirement is marked as Non-
Adhyapak Functional.
Function Call for Error out pin config is not implemented

Open at the Start Up
Please provide CAN database which handles the error out

pin enable/disable
Satyajit Closed 9/5/2018 Viji : 9/5/2018 Viji : Requirement moved to
Adhyapak 'Move' state. No need to verify.
It's mentioned that "currently ERU feature is not being

Satyajit Open used." Please clarify
Adhyapak
Internal password protected safety watchdog should be

Satyajit used only at the start up or for every entry point to the
Open
Adhyapak particular functions?
Please provide the details of Order of the Safety related
Tasks to be executed
Satyajit Closed 9/5/2018 Viji : Requirement moved to 'Move' state. No
Adhyapak need to verify.
Please provide more information on the deadline

monitoring and run time budget monitoring.
Please provide more information on the ASIL classification

of the data transmission
These macros are used in Ifx_mtu.c and the function

IfxMtu_getSystemAddress () is not called.
Open Sowjanya: Code is under review, need to check after one
week.
Sowjanya: Code is not implemented.
Jagadish: Please let us know LSy code implementation
status .
Satyajit Jagadish: status of 8th point need to be discussed with
Closed
Adhyapak Janin Rider .
9/5/2018 Viji : Requirement moved to 'Move' state. No
need to verify.
Which safety mechanisam violation will transiti to Safe

Silent?
Satyajit 8/22/2018 : [Jagadish] Requirement has been deleted, so
Closed can mark it as closed
Adhyapak [SA] Requirement is reworded to generate a fault. Check
the register check functionality in Startup design
(Gen1_2_Startup_Design.docx)
Reference for this fault and event numberis not found in

77GHz_Gen1_2_Sensor_Fault.ppt
Satyajit Open [SA] See events under fault 9
Adhyapak Jagadish: How to check the error in MCU start up
sequence?Please proivide reference.
Satyajit Closed NA
Adhyapak
Please confirm with Jack
Satyajit Closed 9/5/2018 Viji : Requirement in 'To Be Clarified' state.
Adhyapak Hence will not be verified.
Satyajit Closed NA
Adhyapak
Satyajit Closed NA
Adhyapak
Satyajit Please let us know the status of

Open
Adhyapak design and code implementation status.

Satyajit design and code implementation status.
Closed

Closed

Closed
Adhyapak 8/31/2018 [Viji] : This requirement is marked as Non-
functional.
Satyajit Closed design and code implementation status.
Adhyapak 8/31/2018 [Viji] : This requirement is deleted.

Closed

Satyajit Closed design and code implementation status.

Satyajit Closed 9/5/2018 Viji : Requirement moved to 'Move' state. No
Adhyapak need to verify.

8/31/2018 [Sunil Kumar Mangali] : I had checked for
Satyajit "Keepalive" in this document and idid not find "deadline
Closed
Adhyapak Time"
9/5/2018 Viji : Requirement has been deleted.
Satyajit
Open
Adhyapak
Satyajit Closed 9/4/2018 Viji : Requirement has been deleted.

Adhyapak
Need more clarification on the requirement.Is it cyclic,If
Satyajit Open so it should be called from Task?
Adhyapak Sowjanya: Code is not implemented.
Satyajit Please confirm whether functionality isimplemented?

Open
Adhyapak
Open NA
what is known test data vector?

How to test tasks privilege level?

Need code implementation status
8/31/2018 [Sunil Kumar Mangali] :Requirement is not
Satyajit Closed updated in DOORS
Adhyapak 9/5/2018 Viji : Requirement has been updated in DOORS.
Satyajit Closed NA
Adhyapak
Satyajit 9/5/2018 Viji : Requirement in 'To Be Clarified' state.

Closed
8/31/2018 [Sunil Kumar Mangali] :Requirement is not

Satyajit updated in DOORS
Closed
Adhyapak 9/5/2018 Viji : Requirement in 'To Be Clarified' state.
Hence will not be verified.
Satyajit Closed This requirement is obsoleted.

Adhyapak
Satyajit Closed This requirement is obsoleted.

Adhyapak
Open
Sl No Section Module Requirement ID
1 13.1.1.2.4 Power Supply Configuration PCO_SW_3377
SM Safety Processor - CPU - PCO_SW_3400

3 13.1.4.1 CRC Instruction
SM Safety Processor - CPU - PCO_SW_3404

4 13.1.4.1 CRC Instruction
5 13.1.16 SM Safety Processor - PMS PCO_SW_3483
6 13.7.3.6 Diagnostic Fault PCO_SW_3913

Management
Diagnostic Fault
7 13.7.3.6 PCO_SW_3915
Management
11 13.7.3.1 Power-up PCO_SW_3857

13 13.7.7.4 Time domain PCO_SW_3971
14
Requirement
If the indictated power supply mode configuration does not match the flag
settings (identified by PMSWSTAT.HWCFGEVR status flags), the system shall
transition to safe-silent.
On power-up, the Core SW shall test the error out pin by doing the
following:
Reading back the state of the error out pin and verifying its state.
Toggling the state of the pin and verifying that the CAN Tx is
enabled/disabled accordingly.
On power up, during initialization, the Core SW shall verify that the CPU
CRC instruction is functioning correctly using a known test data vector
After OS starting, the Core SW shall configure the tasks related to

Application & Feature SW to have User Mode 0 privilege.
NOTE:
If a task is not to access peripherals, the task should be configured with
CPU privilege level user mode 0 access protection. Tasks configured for
user mode 0 cannot enable or disable interrupts.
The Core SW shall generate a fault if the temperature difference between

the Aurix DIE temperature and the core temperature is greater than
3degC.
The Core SW shall log all faults to NVM
The Core SW shall log all asserts to NVM.
The Core SW shall control and monitor the functional program sequence
for safety-relevant software parts.
The Core SW shall control and monitor the temporal program flow for
Core, Feature and Application SW (e.g. deadline monitoring and run time
budget monitoring for software parts relevant for functional safety).
The Core SW shall verify that data transmission between the software
components on different cores/tasks is safe (i.e., Errors in data
transmission are detected) and in accordance with the ASIL classification
of the data being transmitted.
On power-up, the Core SW (Bootloader) shall be booted from a lockstep

core.
The Core SW shall partition all available memory in the sensor into the
following regions:
SAFE_DATA (ASIL B)
CORE_DATA (ASIL B)
AFT_DATA (QM or ASIL B)
SHARED_DATA (QM or ASIL B)
Note: Due to safety concerns, the application and feature teams have a
predefined memory allocation
The Core SW shall publish the run time measurements via the interfaces
available.
Question
Requirement is not implemented. The Start Up CSC should call the IfxPMS
Please provide CAN database which handles the error out pin
enable/disable
what is known test data vector? No where found in design document as

well in code
did not understand the requirement (need clarification)

generic requirement
Code is not implemented for checking the difference between the

temperature values
Please provide the details of Order of the Safety related Tasks to be

executed
Please provide more information on the deadline monitoring and run time
budget monitoring.
Please provide more information on the ASIL classification of the data

transmission
1)No proper design document for bootloader

2) not able to find the code for this requirement
1)where I can find the partition of Memory regions in code?
2)what is the range for the each partition?ex: SAFE_DATA range
1) What is the Run Time measurements

Comments by Satyajit
[SA] This requirement should be reworded to say generate a fault instead

of safe silent.
[SA] To be clarified by SMEs. Most likely be deleted.
[SA] Requirement in under SME review and bound to change. FYI, test
vector can be any data set for wich the CRC value is known.
[SA] Requirement in under SME review and bound to change.
[SA] Based on the new safety manual V0.9, the temperature difference is
9degC. Code is currently implemented and checked into PTC under
diag_temp_monitor.c
need to make it as non-functional requriment
need to make it as non-functional requriment
[SA] Comment by SME in DOORs says to move the requirement to L20.
Probably can be a Non functional reqt.

[SA] MPU implementation still ongoing. Will have major edits based on
SME review.
[SA] This requirement is in TBC state.

TSR Q&amp;A Clarification Confirmation

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TSR Q&amp;A Clarification Confirmation

Uploaded by

Copyright:

Available Formats

Project Resource SW Version

77GHz Platform Gen1.2 Aditya Math -

SM Safety Processor PCO_SW_3391

SM Safety Processor PCO_SW_3391

SM Safety Processor PCO_SW_3425

SM Safety Processor PCO_SW_5183

SM Safety Processor PCO_SW_3464

SM Safety Processor PCO_SW_3511

SM Safety Processor PCO_SW_3512

SM Safety Processor PCO_SW_3457

SM Safety Processor PCO_SW_3841

SM Safety Processor PCO_SW_3454

Diagnostic Fault PCO_SW_3912

26 13.1.1.3.3.3 Error out pin PCO_SW_3380

27 13.1.1.3.3.3 Error out pin PCO_SW_3382

SM Safety Processor PCO_SW_3410

SM Safety Processor PCO_SW_3413

31 13.7.3.3 Normal Operations PCO_SW_3891

32 13.7.3.3 Normal Operations PCO_SW_3892

37 13.7.3.1 Power-up PCO_SW_3873

38 13.7.3.1 Power-up PCO_SW_4174

39 13.7.3.1 Power-up PCO_SW_3856

43 13.7.7.3 Data domain PCO_SW_3961

44 13.7.7.3 Data domain PCO_SW_3959

45 13.7.7.3 Data domain PCO_SW_3964

46 13.7.7.3 Data domain PCO_SW_3966

SM Safety Processor PCO_SW_3450

SM Safety Processor PCO_SW_3449

SM Safety Processor PCO_SW_3445

64 13.7.3.1 Power-up PCO_SW_3860

35 13.7.3.1 Power-up PCO_SW_3858

SM Radar Frontend PCO_SW_3616

Safety Manual Aurix v0.8:

The Core SW shall check for a lost DMA transaction.

Safety Manual Aurix v0.8:

The Core SW shall provide an FPI error handler to handle FPI

On powerup, the Core SW shall verify the correct configuration of

On power-up, the Core SW shall check that the SMU register

Safety Manual Aurix v0.8:

The Core SW shall log all faults to NVM

On power-up, the Core SW shall configure all fault reactions based

The Core SW shall ensure that the system transitions to the

The Core SW shall perform plausibility checks on RF Detection

The Core SW shall run a software based selftest to detect faults in

If the indictated power supply mode configuration does not match

On power-up, the Core SW shall configure the SMU to trigger the

The Core SW shall configure ERU parameters and start external

The Core SW shall use the internal password protected safety

The Core SW shall verify that data transmission between the

• verify that SCU_STMEM4, 5 checks do not report any fail found

• verify that SCU_STMEM3, 6 indicate that CHSW was successfully

• check that the lockstep enable in SCU_LCLCONx.LSy (where y

• check that ALM0[0] (where x identifies the lockstep-CPU) does

• check that MC0_ECCD.UCERR register does not report

• for all SRAM used by the Application, check MCi_ECCD.UERR = 1

If an Error is detected in the initialization of any safety mechanism

If an Error is detected in the MCU startup sequence, the system

On power-up, (Immediately after PORST is released), the Core SW

On power-up, the Core SW (Bootloader) shall enable the ECC

On power-up, The Core SW shall verify ECC (Error Code

The EMEM configuration registers shall be stored before the SPUx

Note: Due to safety concerns, the application and feature teams

The safety related Core SW Tasks shall have R/W access to

TSR Q&A Clarification Confirmation

TSR Q&A Clarification Confirmation