- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In TC37x
I built my code using tricore, when i check the alarm status register inside lauterbach debugger
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
Solved! Go to Solution.
- Labels:
-
AURIX
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here's a link to it on MyICP:
If you don't have MyICP access, follow the instructions here:
https://www.infineon.com/cms/en/product/promopages/MyICP-platform-for-Microcontroller/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi aurther. Sorry, I cannot share documentation with access control outside of MyICP.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Actually am getting error404
so what should i do now?
is it not possible to post a screenshot? or is that too not allowed?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Example for TC37x, cold power-on reset values:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
So I will have to clear the smu alarm, eccd.ucerr and faultsts.operr[0], right?
But when i do so i get "Data Access Synchronous Error Trap" trap.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What's in CPUx_DEADD?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank You
could you please tell where is it written that fsi_ram is 40?
Please can you list the source!
Thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
See SAFETY_TC.H013 in the errata sheet: the FSI MTU instance (SSH) is restricted to just checking FAULTSTS.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.