S32K312-Reset interface problem

[Simon-Liu]

Hello

When I use two interfaces to reset the K312, I found that the reset reasons read by the interface Power_Ip_GetResetReason are different:
1. When using the Power_Ip_PerformReset interface, the reset reason can be read as 13 or 26 (depending on whether the configuration is DestructiveReset or FunctionalReset).
2. When using the Power_Ip_SetMode interface, when the mode is configured as DEST_RESET, the reset reason can be read as 13 after reset, but when the mode is configured as FUNC_RESET, the reset reason read after reset is 0 instead of 26.

What is the reason why the reset reason is 0 instead of 26 after using Power_Ip_SetMode to reset?

BestRegards

Simon

[Liuliyuan]

@Simon-Liu @danielmartynek  Got a lot from your discussion.  We are wondering whether there is a test interface to set reset-reason manually before calling performreset. Do you have idea on it? Thanks a lot.

[danielmartynek]

Hi @Liuliyuan,

Destructive and functional SW resets can be configured and called by the Power_Ip driver only.

BR, Daniel

[JonAnder_Amante]

Hi, 

I am using the microprocessor S32K344 and the evaluation board called MR-CANHUBK344. I am using the project "S32K344_CAN_bootlloader_RTD2d0" and I have achieved the jump from this project to some application. To send the different services I have used the application "ECUBUS" but I have problems when I try to send the "ECURESET" service. I receive an error (In the next picture you can see the error) and I don´t know the reason of this mixtake. Although the program reset correctly, I don´t want to receive this message and I want to receive the positive reply. I need the reply as soon as possible as I have to send the project very soon. 

Thank you for all,

[danielmartynek]

Hello @Simon-Liu,

Reason 0 is the power-on reset.

These are the sources:

Can you read the DCM_GPR[DCMROPP1] register?

More information about POR_WDG in the RM rev.6, Chapter 34

Regards,

Daniel

[Simon-Liu]

Hi @danielmartynek 

Thank you for your answer.

After my test, the value of IP_DCM_GPR->DCMROPP1 read after reset is 0x30000013.

The interface used for reset is Power_Ip_SetMode(&Power_Ip_aModeConfigPB[2]), and the configuration of DS is as follows:

BestRegards

Simon

[danielmartynek]

Hi @Simon-Liu,

Can you share the whole project so that I can test it on my side?

Thanks,

BR, Daniel

[Simon-Liu]

Hi @danielmartynek 

Thank you for your answer, the attachment is the project I used, please check it.

BestRegards

Simon

[danielmartynek]

Hi Simon,

I have difficulties to compile the project, probably becasue incompatible RTD versions.

Anyway, can you clear the DCMROPP1 register before the reset, just to make sure the register is updated correctly. It reports in which FUNCn the counter overflowed.

It could be becasue of the Clock configuration:

31.3.6 Functional reset sequence descriptions

Regards,

Daniel

[Simon-Liu]

Hi @danielmartynek 

Thank you for your answer.

I cleared the register DCMROPP1 before Reset (writing all Bits to 1), and the value of DCMROPP1 after Reset is 0x00000013。

BestRegards

Simon

[danielmartynek]

Hi @Simon-Liu,

Have you tried changing the clock?

BR, Daniel

[Simon-Liu]

Hi @danielmartynek 

Thank you for your response.

Does the modification clock you mentioned above refer to the clock of the PLL?
At present, the clock frequency of PLL0 I configured is 120MHz, how much does it need to be changed?

BestRegards

Simon

[danielmartynek]

Hi @Simon-Liu,

I'm sorry for the delay.

Please refer to the excerpt from the RM I posted in my last response.

There are examples of clock configurations in the RM, Section 24.7.2.

I would recommend using just the examples of clock configuration without any modifications.

If the examples are modified, it must be in a way where the ratios between the clock frequencies are maintained.

As I wrote beofre, I could not compile your project that seems to be rather complex.

If the recommended clock configuration does help, can you remove components from the project one by one to identify the root cause?

Thank you,

BR, Daniel

[Simon-Liu]

Hi @danielmartynek 

Thank you for your response.

I used a sample project that I have used before to test, without modifying the clock configuration in the sample, the result is the same: the ResetReson read after using the Power_Ip_SetMode interface to perform a destructive reset is still 0.
After the code is powered on, the ResetReson is read and output through the UART, and the reset is performed after a period of delay.
Please refer to the attachment for the project used, this should be able to be compiled.

BestRegards

Simon

[danielmartynek]

Hi @Simon-Liu,

Thanks for the project.

I'm testig it now and if I comment this function out, it works.

Clock_Ip_Init(&Clock_Ip_aClockConfig[0]);

The clock configuration is clearly not correct.

Please have a look at the RM:

Table 145. System clock frequency limitations

Table 148. Option B - Reduced Speed mode (CORE_CLK @ 120 MHz)

Table 153. Option F - Operation in 1:1 mode with CORE_CLK and AXBS_CLK at same speed

Regards,

Daniel

[Simon-Liu]

Hi @danielmartynek 

Thank you for your answer.

I commented out the function Clock_Ip_Init according to your method, and the reset reason can indeed be read. Then I modified the configuration items according to the content in the [Option B - Reduced Speed mode (CORE_CLK @ 120 MHz)] table, but after testing, I found that there are still problems. Please help me to see where my configuration items are incorrect? Please see the attachment for my project, thank you very much.

BestRegards,

Simon

[danielmartynek · Accepted solution]

Hi @Simon-Liu,

Can you enable this:

Let me know,

BR, Daniel

[Simon-Liu]

Hi @danielmartynek 

Thank you for your response.

In my previous project, SXOSC and FXOSC were enabled, but the PLL was not enabled. After I enabled the PLL according to your method, I can read the reset reason as 22. The problem is solved. Thank you very much. If possible, could you please tell me the reason for this problem? And why can FunctionalReset be read out when PLL is enabled? And why is DestructiveReset unaffected?

Thank you again for your help.

BestRegards

Simmon

[danielmartynek]

Hi @Simon-Liu,

The POR_WDG overflow was reported in FUNC4, which is the Functional reset sequence not Destructive.

Out of reset, PRTN1_CONFB1_CLKEN[REQ56] = 0, it is set by the Clock_Ip_Init() function and it should stay enabled as long as the PLL is enabled.

BR, Daniel

[Simon-Liu]

Hi @danielmartynek 

Thank you for your answer.

Why is there no such problem when using the interface Power_Ip_PerformReset for FunctionalReset?

BestRegards

Simon

[danielmartynek]

Hi @Simon-Liu,

This function does not change the power mode, it just triggers the reset.

Compare the source code of the two functions in Power_Ip.c

Regards,

Daniel