cancel
Showing results for 
Search instead for 
Did you mean: 

AURIX™

aurther
New Contributor II

In TC37x

I built my code using tricore, when i check the alarm status register inside lauterbach debugger 

aurther_0-1641870611970.jpeg

 

you can see that eg. alm0[10] is already set to reported, even though I haven't even deployed the code yet[ the code is just built].

So I want to know whether this behaviour is expected, and I just clear all status bits before start of my code, or am I missing something

0 Likes
21 Replies
µC_Wrangler
Employee

Hi @aurther .  Per the Safety Manual, some alarms are expected: see Appendix A, Alarm tables after reset.

It lists the expected value for SMU_AG0 as 0x2490 (i.e., AG0[10] is set).

See 5.94 ESM[SW]:SYS:MCU_FW_CHECK, which recommends your application check for the expected values, to ensure the internal firmware completed correctly.  After that, most applications clear all alarm status bits.

0 Likes
aurther
New Contributor II

hi @µC_Wrangler 

Please send the safety manual, as am unable to find it
thanks!

0 Likes
aurther
New Contributor II

Hi @µC_Wrangler 

Due to some reasons am unable to open myipc [ its giving error 404, page not found]

Could you please just share the safety manual on this chat for now
I will try to login myipc later again

Thank You!

 

0 Likes
µC_Wrangler
Employee

Hi aurther.  Sorry, I cannot share documentation with access control outside of MyICP.

0 Likes
aurther
New Contributor II

Actually am getting error404

so what should i do now?

is it not possible to post a screenshot? or is that too not allowed?

 

0 Likes
µC_Wrangler
Employee

Example for TC37x, cold power-on reset values:

C_Wrangler_0-1642012753102.png

 

0 Likes
aurther
New Contributor II

Thank you @µC_Wrangler 

One more thing actually, whenever I try to clear these status bits[ by using "clearAlarmStatus"], they do not get cleared.

so is this function applicable only for software alarms[group 10], for what is that am missing

 

Thank you

0 Likes
µC_Wrangler
Employee

To clear many SMU alarms, the underlying source has to be cleared.  ALM0[10] reflects an SRAM monitor error in CPU0 DSPR/DCACHE/LMU.  To clear that, write 0 to MCi_ECCD  (see the MTU chapter; MC0_ECCD for CPU0_DMEM, MC1_ECCD for CPU0_DTAG, and MC4_ECCD for CPU0_DLMU_STBY).

There's a Safety Kit application note coming out very soon that will have example code for MCU_FW_CHECK, MTU NDIT, and many other safety mechanisms listed in the Safety Manual.

aurther
New Contributor II

Thank You @µC_Wrangler 

so what you mean is find the module, corresponding to each alarm, and clear the register bits of the module.

but, in say Alm7[22-31], the module is FSI, but for this case, theres not mention of FSI module in data manual.

0 Likes
µC_Wrangler
Employee

Exactly right.

For the FSI:

> 6.1 Overview
The Non Volatile Memory (NVM) Subsystem comprises of the Data Memory Unit (DMU), Program Flash Interface
(PFI), and Non Volatile Memory module (comprising of the Flash Standard Interface (FSI), Program and Data Flash
memories and Program Flash Read Write buffer (PFRWB)).

The FSI RAM is the buffer for doing writes and bursts to data flash and PFLASH.  Clearing FSI errors is more sticky than most - see HF_ERRSR.OPER (i.e., Flash array failures like an ECC error in FSI SRAM are cleared with System Reset).

aurther
New Contributor II

Hi @µC_Wrangler 

Thank you for the information. Am still a bit confused though.

Suppose, I want to clear Alm0[9-11] (shown in pic below)

aurther_0-1642334833642.png

 

So I will have to clear the smu alarm, eccd.ucerr and faultsts.operr[0], right?

aurther_0-1642414714220.png

But when i do so i get "Data Access Synchronous Error Trap" trap.

0 Likes
µC_Wrangler
Employee

Per Table 474 Register Overview - MTU (ascending Offset Address), FAULTSTS is Safety ENDINIT protected.  Have you wrapped that register write in a clear/set safety endinit sequence?

ECCD should be easier, but you do have to be in Supervisor mode (CPUx_PSW.IO = 2).  Make sure you're using the SFR definition, so the compiler doesn't generate a bit set/clear instruction: access to ECCD should be just a 16-bit write.

0 Likes
aurther
New Contributor II

hi @µC_Wrangler 

its still the same. No change. Still am getting the same trap error

I checked it, it is giving me some "bus error"

0 Likes
µC_Wrangler
Employee

What's in CPUx_DEADD?

0 Likes
aurther
New Contributor II

hi @µC_Wrangler 

I will check once.

I need to know that, for alm7[0-2] Dam0/fsi_ram, which module is used?

and also for alm7[17] - xbar bus event, SRI module is used and for alm7[20] - SPB bus event, SBCU module is used.

But which module is used for SRI and SBCU mentioned here?

 

 

0 Likes
zs
New Contributor

ALM7[0-2] is set by the SMU from the MTU. You can use the example code in Infineon's github repository to enable the MTU and this function, clear_MTU_MBIST_Errors(), is what you're looking for.

Also in that example code is an enumeration type, IfxMtu_MbistSel. You want to call clear_MTU_MBIST_Errors() and pass in IfxMtu_MbistSel_dam0 (38) and IfxMtu_MbistSel (39). FSI_RAM is 40, but it's not listed in the enumeration and also needs to be passed into the function.

0 Likes
aurther
New Contributor II

@zs 

Thank You

could you please tell where is it written that fsi_ram is 40?

Please can you list the source!

 

Thank you

 

0 Likes
µC_Wrangler
Employee

See SAFETY_TC.H013 in the errata sheet: the FSI MTU instance (SSH) is restricted to just checking FAULTSTS.

0 Likes
aurther
New Contributor II

@µC_Wrangler 

Thank you

 

Can you please tell me that, we have pre-alarm mapping and Tc37x specific mapping in the data sheet. So the pre-alarm mapping refers to this kind of alarms right?[ I mean like MTU ones].

But for Tc37x specific mapping, we just can clear and set the alarm status like we do for software alarms right?

 

Thanks

0 Likes
µC_Wrangler
Employee

The pre-alarm mapping shows you how some alarms are combined.  For MTU alarms, you'll need to clear each of the underlying MTU errors, and then clear the alarm within the SMU.

For example: ALM0[9] is a combination of CPU0.DMEM, CPU0.DLMU, and CPU0.DMEM1.  In the SSH Instances table, CPU0_DMEM is MC0, CPU0_DLMU_STBY is MC4, and CPU0_DMEM1 is MC34.  Clear those ECCD registers and then write 0x200 (bit 9) to SMU_AG0 to clear the alarm.

0 Likes