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

cross mob
DownyK
Level 5
Level 5
100 replies posted 10 solutions authored 250 sign-ins

Hi members,

Currently, I am developing a controller by applying TC387AE.

I set the system reset by the SMU, and suppose that the SMU alarm occurs during the run time.

In this case, does the system reset occur indefinitely in the case of permanent failure?

I wonder if I should set SMU reset to Application Reset to avoid this situation.

DownyK_0-1682065917650.png

 

DownyK_1-1682065939331.png

Then, the question is, when setting SMU reset to Application Reset, what should I look at carefully compared to System Reset?

 

The second question. If you look at Appendix A of the Safety Manual, you can see the Alarm Table according to the MCU reset type.

In the stage of naming it FW check, I check this pattern to see if the MCU is turned on normally.

I found that I often fail to pass that step while turning on and off the MCU.

What I'm curious about is in what environment the MCU can represent this kind of failure.

I'd like to hear the general view. (e.g. low voltage situation)

 

Thanks

0 Likes
1 Solution
Jeremy_Z
Moderator
Moderator
Moderator
250 sign-ins 100 likes received 750 replies posted

Hi @DownyK ,
Thanks for your reply.
According to the testing, you guess that the FW check step can't pass through if an SMU-induced Application reset occurs twice, as AURIX is held in permanent application reset until a Power-on or System reset occurs, is my understanding right?
Back to your question, do you want to know whether the ROM code handles the Alarm phenomenon to cause the permanent reset? If yes, in my opinion, the ROM code will handle the SMU alarm during the start-up process, however, the ROM code is confidential, and even I don't know the details.
So it's better to choose the System reset as the action for the SMU alarm to avoid the aforementioned phenomenon.
BR,
Jeremy

View solution in original post

6 Replies
Jeremy_Z
Moderator
Moderator
Moderator
250 sign-ins 100 likes received 750 replies posted

Hi @DownyK ,
1) What should I look at carefully compared to System Reset?
Compared with the System reset, the benefit of application reset is costs less time during the start-up process, so it's important to have an idea of know how to handle the previous Alarms and their trigger source, otherwise, it may encounter the aforementioned phenomena and needs system reset to get out of this 'trap', it's a conflict with the original design purpose.
2) I'm not very clear with the second question, can you clarify it again?
BR,
Jeremy

0 Likes

Hi Jeremy_Zhou,

Let me explain what I encountered in the situation on TC387AE.

The controller I have developed has the VB & IG(Battery and Ignition) voltage level[5.5v] for Turning off.

when I insert the minimum Turn voltage into the controller, it wakes up and goes to the start-up sequence. At this point, I swing VB and IG fast based on Turn Off voltage. and The controller is supposed to go to Application Reset instead of Shutdown if it is larger than 5.5V at the time of turn-off SW.

So if I swing to 5.5V, in some cases the controller goes to the Shutdown and in some cases, the controller wakes up with Application Reset.

If I try to test continuously like this, the MCU suddenly falls into an infinite reset.

So when I checked what kind of problem happened, the SMU reset(System Reset) occurred because the SMU alarm pattern that fits the reset type did not match in the FW check stage. Because I didn't configure the SMU alarm status initialization code if the reset type and pattern were different. This part will be added.

Therefore, I was asking you when different SMU Alarm Patterns(Information related to the pattern is here. : Appendix A of the Safety Manual) can occur from the Reset type.

 

 

 

0 Likes
Jeremy_Z
Moderator
Moderator
Moderator
250 sign-ins 100 likes received 750 replies posted

Hi @DownyK ,
Thanks for your clarification.
In your project, it has the FW check phase to check the status of the alarms (SMU_AG register) based on the application reset, however, it has not been compatible with the system reset, is my understanding right?
Back to your second question, I've no idea why SMU_AG registers do not become 0x0000_0000 after the reset event occurs, I guess it's related to the IP module, however, If no action is specified for the alarm, no action will take place, in another word, it will affect the subsequent code function.
And you can also clear the alarm status bits to avoid any potential interference.
BR,
Jeremy

0 Likes

Hi @Jeremy_Z ,

To be more precise, I implemented the FW check step to check the pattern for all Reset types. [After the Reset, check the RSTSTAT in the RCU to determine the pattern corresponding to the Reset Type]

Therefore, in normal, after performing the Warm Power On Reset, Cold Power On Reset, System Reset, and Application Reset, the FW Check step is passed without any problems.

However, some of the specific tests mentioned above may not pass the FW Check.

So the question is, after a reset in this particular environment, why the SMU alarm pattern may differ from what was pre-defined mechanically?

I asked if there was anything that Infineon had checked in advance in this regard.

Of course, I can delete the alarm flag without taking the reaction as you said.

But I want to know the fundamental reason.

thanks.

0 Likes
Jeremy_Z
Moderator
Moderator
Moderator
250 sign-ins 100 likes received 750 replies posted

Hi @DownyK ,
Thanks for your reply.
According to the testing, you guess that the FW check step can't pass through if an SMU-induced Application reset occurs twice, as AURIX is held in permanent application reset until a Power-on or System reset occurs, is my understanding right?
Back to your question, do you want to know whether the ROM code handles the Alarm phenomenon to cause the permanent reset? If yes, in my opinion, the ROM code will handle the SMU alarm during the start-up process, however, the ROM code is confidential, and even I don't know the details.
So it's better to choose the System reset as the action for the SMU alarm to avoid the aforementioned phenomenon.
BR,
Jeremy

Hi @Jeremy_Z 

Thank you for your reply.

you are right.

 

if I could get more information about this phenomenon, it would be good for me. 

But I think it is enough for developing the controller. 

 

I hope you get more information about this. please let me know. anytime.

Thanks.