S32K312 HSE_SWT_RST issue

[Yiming2]

hello all

we just found that when the MCU is power up, it would be continuously reset 6 times at the beginning, after 6 times it would be going into normal status,HSE seems work correctly after continuous 6 times . and we also read the reason of reset, it showed that HSE_SWT_RST. We don't know why it would reset 6 times.  Note : We did install the HSE-firmware for random number generation. The MCU we are using is S32K312. but we also check the HSE_CLK=60MHz and Core_CLK=120MHz AIPS_SLOW_CLK=30. And also checked the DCF config the CLK option is "00". We don't know why HSE_SWT is triggered 6 times. How to fix this issue.

[lukaszadrapa]

Hi @Yiming2 
I saw in the past that HSE SW RST could be triggered on S32K312 if the clocks are not configured appropriately. But it seems to be OK according to your description. Could you try to configure the clocks after the HSE_STATUS_INIT_OK bit gets set in the FSR of any of the MU? Does it make a difference?
Regards,
Lukas

[Yiming2]

hello, @lukaszadrapa 

I think it is related with clock setting. because when I don't do the Clock seting, the reset shall not be happen. So I want to know the reason.(IVT seq_boot = disable. So PLL in boot stage is also not worked, and the clock settings in DCM are also not worked.)

1:HSE shall always use FIRC to run or just start from FIRC and it shall switch to PLL once PLL is avaiable?(Is it automatically done before enter to application?)

2:When does the clock source used by HSE shall be switched to PLL from FIRC?

3:And if it causes a reset by HSE when clock source switched to PLL from FIRC?

4:When should we configure the clocks for our application to use?(The timing)

[lukaszadrapa]

Hi @Yiming2 

the system runs from FIRC after reset by default. Clock should be initialized using this procedure:

To change HSE_CLK, it's important to wait till HSE is in idle state:

 and

Regards,

Lukas

[Yiming2]

hello @lukaszadrapa 

thanks for your solution . We tried this method. It seems worked for power up (cold start). But when we performed a functional reset, it still caused one more time reset, the reason show that   HSE_SWT_RST caused this reset.  is there any other checks for this issues?

[lukaszadrapa]

Could you share your exact clock configuration? What is the crystal frequency?

[Yiming2]

Hello, @lukaszadrapa  here it is the current configurations of CLK

PLL_VCO: 640MHz

PLL_PHI1: 64MHz

PLL_PHI0_CLK: 80MHz

CORE_CLK(=PLL_PHI0_CLK): 80MHz

AIPS_PLAT_CLK: 40MHz

AIPS_SLOW_CLK: 40MHz

HSE_CLK: 80MHz

DCF_CLK: 20MHz

[lukaszadrapa]

Please take a look at this post:

https://community.nxp.com/t5/S32K/HSE-provides-RSP-NOT-SUPPORTED-response/m-p/1712323/highlight/true...

I can see it's a question from your colleague.

I have never met a case when 80MHz is used, only 60MHz or 120MHz (only these two frequencies are mentioned in all the tables). And 120MHz can be set only in a way as described in the post. 80MHz is the same case, most likely. Can you try to use 60MHz only for HSE_CLK? I'm sure this will make the difference.

Regards,

Lukas

[Yiming2]

hello @lukaszadrapa 

I need to add some information that I just found in RM.

In RM(Rev8). The Table 145 Option F is set to 80MHz for HSE_CLK. But inTable 160 option F, The HSE_CLK is set for 60Mhz for S32K312. can you tell me which one I should follow?

[lukaszadrapa]

OK, but Option F expects HSE_CLK 60MHz:

But you wrote earlier that your HSE_CLK is 80MHz. I believe that it will work if you lower the HSE_CLK to 60MHz. 

[Yiming2]

I think there are something is wrong in Table 160(option F). Because as the description of Figure 57. In the PLL_PHI0_CLK=80MHz, When MC_CGM.MUX_0_DC_0[DIV](used for CORE_CLK) = '000b' and CORE_CLK=80MHz but why MC_CGM.MUX_0_DC_3[DIV](Used for HSE_CLK)='000b' and HSE_CLK=60MHZ? it is unbelievable for us.

[lukaszadrapa]

Well, it will be fixed in next revision of RM and it will look like this:

I'm still waiting for confirmation if HSE_CLK 80MHz can be set by software or if it is necessary to configure FXOSC in UTEST etc. I will let you know later.

Regards,

Lukas

[lukaszadrapa]

Ah, ok, good point. There's obviously something wrong and it needs to be fixed. Let me check this with AE team. I will let you know later. Notice that it may take some time.

[Yiming2]

@lukaszadrapa  thanks for your information, I will try the 60MHz. But in the RM(Rev.8) the 80MHz also has been added as Option F(Table 160). that is why we tried to use 80MHz.