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.
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
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)
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
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?
Could you share your exact clock configuration? What is the crystal frequency?
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
Please take a look at this post:
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
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?
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.
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.
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
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.