Can I dynamically switch between Clock Option A and Option F (A ↔ F) during runtime on S32K322

[KirillSchwez]

Hello,

I am working with the S32K322 and using the predefined clocking options (Option A currently) described in the S32K3xx datasheet and reference manual.

I would like to confirm whether it is supported to dynamically switch during runtime between Option A (PLL @160 MHz) and Option F (PLL @80 MHz) — in both directions (A → F and F → A) — without performing a full device reset.

Specifically, could you please clarify:

1. Can the MC_ME (Mode Entry Module) and MC_CGM (Clock Generation Module) safely handle this clock transition while the system is running?

2. Are there any required steps for updating the AHB gasket / interconnect configuration or other bus domain isolation settings when switching between these options?

3. What are the recommended sequences (e.g., via RUN mode transitions) to ensure the PLL, peripheral clocks, and flash wait states are correctly reconfigured during both A → F and F → A transitions?

4. Are there any limitations or errata related to changing between these PLL configurations at runtime for S32K322?

Any guidance, application notes, or SDK configuration examples for safely performing runtime clock switching between Option A and Option F would be greatly appreciated.

Basically I want to change only CORE_CLK (160 to 80 and back) for power saving applications (Dynamical  Downclocking)

Thank you

[davidtosenovjan]

1) Yes, such switching can be done with using of ME module. It is needed run system for IRC during the transition.

2) Not really, but you have to check in every step clock configuration is valid. For instance to have se valid flash wait states.

3) Sequence is to switch ME mode from PLL clocked to IRC clocked, change PLL and dividers settings, and switch ME mode back to new configuration. This cannot be done when modules are active (for instance in the middle of transmission of certain communication module unless this is clocked by IRC).

4) I am not aware of any errata.

[KirillSchwez]

Hello davidtosenovjan,

Many thanks for your reply,

I have the following main point:

according to the RM (S32K322):

Table 170. Gasket configurations in various clocking modes (for S32K344, S32K324, S32K314, S32K342, S32K341, and
S32K322)

For clock option A:

Gasket configurations for HSE_B is : 1 : 2

For clock option F:

Gasket configurations for HSE_B is : Bypass

HSE Mode Selection and Bypass HSE IAHB gasket control (HSE_CLK_MODE_AND_GSKT_CTRL) register values:

00 - Applicable for Mode A Ratio 1 : 2

01 -  Applicable for Mode F Ratio 1 : 2 is bypassed

But HSE Mode Selection is OTP (One Time Programming) is my understanding correct?

In my Application CAN Subsystem is running and for reducing the current, I was thinking about down clocking of CORE_CLK.

All  clock setting and limitations are valid according to the  

Table 150. System clock frequency limitations (For S32K344, S32K324, S32K314, S32K342, S32K322, and S32K341)

My questions are:

1) Is clock switching from Option A to F and back (dynamically during system runtime, CAN is active, many times by low system load) on S32K322 still possible without any negative impact? (Gasket configurations for HSE_B is : 1 : 2)

2) Gasket configurations for HSE_B is OTP and cannot be changed during runtime many times (from 00 to 01 and back), is my understanding correct?

3) Depending on the answers, will you still recommend switching of CORE_CLOCK or should I search for other ideas, like lower CPU Load, or switch off peripherals for saving the current ?

Many thanks for your support

[davidtosenovjan]

1) I would not see any issue by the fact that CAN is active, unless there is not communication is progress.

2) Yes, it is.

3) You can apply all approaches. A frequency chance has basically main impact to power consumption (as dynamic current is the most important portion of overall consumption).

[KirillSchwez]

Hello davidtosenovjan,

Many thanks for your quick reply,

So I just to sum up everything what we discussed before:

1) It means that dynamically switching from Clock Option A to Option F (A ↔ F) an back is not possible dynamically, because in this HSE Mode Selection Gasket cannot be changed during runtime
2) If Mode A Ratio 1 : 2 is set, then by scaling down the CORE_CLK, I need to scale down also HSE_CLK, AIPS_PLAT_CLK and AIPS_SLOW_CLK to keep the ratio 1 : 2.

Mode A: CORE_CLK == 160 Mhz, HSE_CLK = 80 Mhz (Ratio 1 : 2)

If I scale down CORE_CLK == 80 Mhz, HSE_CLK needs to be also down scaled to 40 Mhz to keep the ratio (1 : 2)

Scaling down only CORE_CLK to 80 Mhz, without adapting HSE_CLK and other Clocks (HSE Mode Selection: 00 - Applicable for Mode A Ratio 1 : 2), in Clock Mode A is not allowed/not recommended.

All Modules clocked by above clock should be not in communication Mode.

3) If CAN communication is active (Sending and Receiving is ongoing) clock down scaling is not recommended, as this can break the receive/transmission process.
Ideally it should be checked if CAN is idle (SW Side) and make a transition in a critical section.

You helped me a already a lot, please confirm if I got all the points correctly.

Many thanks for your patience and support

[davidtosenovjan]

1) Yes, actually you are right. This hasn’t crossed my mind. You can only change setting which are not DCF configured.

2)  You will change overall system frequency and yes, all ratios must be kept i.e. you are not changing clocking option

3) Yes, correct.