AURIX controller reset

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

cross mob
User17900
Level 1
Level 1
5 questions asked First reply posted First question asked
Hi,
Application reset occurring when we are using CAN module in TC 233. When reset happening global and local variables are not resetting, only GPIO is getting reset. Help as to fix this issue.

Thanks and Regards,
Narayanan R
0 Likes
7 Replies
Darren_Galpin
Employee
Employee
First solution authored First like received
Hi Narayanan,

So where are your global and local variables stored? Maybe they are in a location which is only reset by a system reset?

Cheers,

Darren
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
How are you configuring RSTCON?
What's in RSTSTAT after the reset?
Are you configuring the SMU?
0 Likes
User17900
Level 1
Level 1
5 questions asked First reply posted First question asked
Exactly from this we are getting in application reset our entier memory will not get reset. but cause of application reset we are not getting in user manual it written "internal/external hardware and software
can also request for application reset. but when we are adding CAN transmit that time reset coming randomly like after 1hr. our watch dog is disabled.
0 Likes
User17900
Level 1
Level 1
5 questions asked First reply posted First question asked
We are getting from RSTSTAT - EVR13 is requested reset. if EVR13 requesting means it will be a cold reset or system reset. in that software should start from initial. We kept local variable in main function
initialized with 0, inside while loop we are incrementing variable and sending in CAN continuously. When reset time local variable not getting 0 it still continuing as previous count.
RSTCON is configured as no reset but when reset occurs it is updating as application reset.

RSTSAT and RSTCON completely misleading us because if any problem in EVR13 it will trigger power on reset not application reset. from user manual we got this information. our understanding is proper or not?
0 Likes
User17900
Level 1
Level 1
5 questions asked First reply posted First question asked
What configuration i need to do in SMU. Can you give little more detail on SMU configuration?
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored


You don't have to do any SMU configuration, unless your application has Functional Safety requirements.

I brought up the SMU because it's important to understand where the reset is coming from. The default SMU alarm configuration is:

- AG2[29] Safety Recovery Timer 0: SMU_AG2CF0=0, SMU_AG2CF1=0x20000000, SMU_AG2CF2=0x20000000 => 110b => SMU_RESET reaction

- AG3[18,17] CPU0 watchdog error or Safety Watchdog error: SMU_AG3CF0=0x001E0000, SMU_AG3CF1=0, SMU_AG3CF2=0x001E0000 => 101b => SMU_NMI reaction


To track this down further, try these tips:

- Make sure Safety Watchdogs are disabled in addition to CPU watchdogs

- At the start of your application, clear the RSTSTAT cold start bits with RSTCON2.CLRC=1. That will help you tell what kind of reset you're seeing later.

- Make sure your trap vector table (BTV) is set correctly by adding a SYSCALL (trap 6) to your program. With the Tasking compiler, that's __syscallfunc(0). At runtime, that should stop the debugger in a default trap handler. If it does something else (like cause a reset), perhaps BTV is not pointing to a valid trap table. Ideally BTV should be aligned to a 256-byte address, or you may have strange results (since the trap number * 32 bytes is ORed into the BTV value).

- Change the SMU from the default START state to the RUN state with SMU_CMD.U = 0. That way you can look at the alarm debug registers SMU_ADx after the reset to see which alarm caused the reset.

- Consider changing the SMU reset reaction from the default Application Reset to a System Reset via SCU_RSTCON.B.SMU=1. That way you can look at RSTSTAT and see if the SMU bit is set after a reset.
0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked
Hi all,

if the application reset is coming randomly it might be somehow related to an external dependency, internal overflow or memory access violation.
This reset type could be related to ESR0/ESR1, SMU or STMx.

If you use an external monitoring device, the reset could be triggered by that device.
Poor connections on the ESR paths, could also lead to that event.

In terms of sending CAN messages, you might have used the STM to send your messages within a time base.
Problems here could also lead to an application reset.

Regards,

Jens
0 Likes