Announcements

Help us improve the Power & Sensing Selection Guide. Share feedback

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User19104
Level 3
Level 3
First like received
Hi,

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

4639.attach

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?
0 Likes
13 Replies
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Have a look at the Trap System chapter in the TriCore Architecture Manual 1.6.2 volume 1.
0 Likes
User19104
Level 3
Level 3
First like received
Only at the TC39cB RM v1.4, and AURICTC3xx RM v1.4
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
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?
0 Likes
User19104
Level 3
Level 3
First like received
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?
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
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.
0 Likes
User19104
Level 3
Level 3
First like received
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:
4320.attach

How can I set the NMI trap?
0 Likes
User19104
Level 3
Level 3
First like received
kfir wrote:
All SMU_ADx regs stay 0 after the reset occurs:
4320.attach

How can I set the NMI trap?


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

4321.attach4321.attach
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
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);
0 Likes
User19104
Level 3
Level 3
First like received
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 :
4322.attach

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
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
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.
0 Likes
User19104
Level 3
Level 3
First like received
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...
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
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.
0 Likes
User20083
Level 3
Level 3
25 replies posted 10 replies posted 5 replies posted
Was this solved?
0 Likes