S32K3 Clock init too long time The clock initialization time for a single App test or a single Boot test is not long, but after the Boot jumps to the App, the App clock initialization time is longer. The system process is as follows: The MCU is powered on, enters the boot, and then configures the clock, checks the integrity of the App program, and then resets the watchdog if the program is OK. After the reset, the Boot detects the flag bit, does not initialize the clock, and directly jumps to the App. (Crystal oscillator 16MHz, no HSE function) Re: S32K3 Clock init too long time It is described in RM that the 42 registers MUX_0_CSC/CSS ~ MUX_20_CSC/CSS are all "reset on destructive reset only". In the application, when the current reset type needs to be determined and a functional reset needs to be confirmed, there is no need to set the clock MUX-x again, and the "reset-set" process can be skipped. However, the software complexity this brings needs to be balanced with the impact of timeout and the integrity of RTD. You can pay attention to the macro switch CLOCK_IP_CGM_X_CSC_CSS_CS_GRIP in Clock_Ip_axSelectorCallbacks in Clock_Ip_Selector.c.
View full article