AURIX™ Forum Discussions

[User19104]

Hi,

I'm debugging the TC399B, and get a reset that's given from the SMU and FSP. (PSA)



BUT, I cannot catch the point in the SW it occurs, I have no view of the stack or PC, nor have the reset reason for this issue.

How can I collect the reason? which register holds the data?

[NeMa_4793301]

Have a look at the Trap System chapter in the TriCore Architecture Manual 1.6.2 volume 1.

[User19104]

Only at the TC39cB RM v1.4, and AURICTC3xx RM v1.4

[NeMa_4793301]

In general, I only recommend having the SMU reaction configured to reset for a select few alarms, such as the watchdog recovery timers. Nothing captures the trap cause or PC across a system reset. It's much easier to track things down if your SMU reaction is NMI, and then the NMI handler can cause a system reset.

What is the alarm that caused the reset?

[User19104]

I have no idea, it just says that the SMU is to blame, couldn't find any register that can explain the the why or what?

[NeMa_4793301]

After the reset, SMU_ADx will have a snapshot from before the reset. That might give you a clue like "SRI bus error", but the details will be lost.

If you can change the SMU reaction to NMI, your NMI handler can capture the details.

[User19104]

UC_wrangler wrote:
After the reset, SMU_ADx will have a snapshot from before the reset. That might give you a clue like "SRI bus error", but the details will be lost.

If you can change the SMU reaction to NMI, your NMI handler can capture the details.

All SMU_ADx regs stay 0 after the reset occurs:


How can I set the NMI trap?

[User19104]

kfir wrote:
All SMU_ADx regs stay 0 after the reset occurs:


How can I set the NMI trap?

Diving a bit deeper it might be something to do with the ECC correction?

[NeMa_4793301]

How can I set the NMI trap?

The SMU reaction to each alarm is configured in SMU_AGiCFj: see Table 529 SMU Alarm Configuration. The three bits are spread out over the three registers SMU_AGiCF0..2. As an example, to set the SMU reaction to an SRI bus error (ALM7[17]) to NMI (5 per Table 529):

// NMI = 5 = 1 0 1 binary
SMU_AG7CF0.U |= (1 << 17);
SMU_AG7CF1.U &= ~(1 << 17);
SMU_AG7CF2.U |= (1 << 17);

[User19104]

UC_wrangler wrote:
The SMU reaction to each alarm is configured in SMU_AGiCFj: see Table 529 SMU Alarm Configuration. The three bits are spread out over the three registers SMU_AGiCF0..2. As an example, to set the SMU reaction to an SRI bus error (ALM7[17]) to NMI (5 per Table 529):

// NMI = 5 = 1 0 1 binary
SMU_AG7CF0.U |= (1 << 17);
SMU_AG7CF1.U &= ~(1 << 17);
SMU_AG7CF2.U |= (1 << 17);

Thanks, very helpffu.

So you chose here ALM7[17], how to I know which one to choose?

No, alarm in SMU_ADi reports a fault condition.

From the configuration, it seems that omly AG10 is set by default, for FSP as reset. meaning :


Trying to update it by:
// NMI = 5 = 1 0 1 binary
SMU_AG10CF0.U |= (1 << 17);
SMU_AG10CF1.U &= ~(1 << 17);
SMU_AG10CF2.U |= (1 << 17);
creates a weird behavior

[NeMa_4793301]

The way to interpret this is:

SMU_AG10FSP = 0x00030000 => bits 16 and 17
FSP is asserted for ALM10[16] (Recovery Timer 0)
FSP is asserted for ALM10[17] (Recovery Timer 1)

SMU_AG10CF0 = 0x00000000, SMU_AG10CF1=0x00030000, SMU_AG10CF2=0x00030000
ALM10[16] reaction is 110b (0x6 RESET)
ALM10[17] reaction is 110b (0x6 RESET)

Perhaps the "weird behavior" you are seeing is because the SMU registers are Safety ENDINIT protected, so you need to clear/set that protection to be able to perform a write.

[User19104]

UC_wrangler wrote:
The way to interpret this is:

SMU_AG10FSP = 0x00030000 => bits 16 and 17
FSP is asserted for ALM10[16] (Recovery Timer 0)
FSP is asserted for ALM10[17] (Recovery Timer 1)

SMU_AG10CF0 = 0x00000000, SMU_AG10CF1=0x00030000, SMU_AG10CF2=0x00030000
ALM10[16] reaction is 110b (0x6 RESET)
ALM10[17] reaction is 110b (0x6 RESET)

Perhaps the "weird behavior" you are seeing is because the SMU registers are Safety ENDINIT protected, so you need to clear/set that protection to be able to perform a write.

Excellent, so the code is written:

	    IfxScuWdt_clearSafetyEndinit(safetyWdtPassword);
			// NMI = 5 = 1 0 1 binary
			SMU_AG10CF0.U |= (1 << 17);
			SMU_AG10CF1.U &= ~(1 << 17);
			SMU_AG10CF2.U |= (1 << 17);
		    IfxScuWdt_setSafetyEndinit(safetyWdtPassword);
			_isync();

but unfortunately it has no effect over the registers...

[NeMa_4793301]

Is the SMU locked? Check SMU_KEYS.CFGLCK. Once the SMU is locked, alarm configuration cannot be changed - see 15.3.1.10.1 Register Write Protection.

[User20083]

Was this solved?