topic S32K3 Clock init too long time in S32K

S32K3 Clock init too long time

simonliu — Thu, 10 Oct 2024 06:00:38 GMT

单独App测试，或单独Boot测试时钟初始化时间也不长，但是在Boot跳转App后，App时钟初始化时间就比较久。

系统流程如下：

MCU上电，进boot，然后配置时钟，检查App程序完整性，然后程序无问题，看门狗复位。复位后，Boot里面检测到标志位后，不初始化时钟，直接跳转App。

（晶振16MHz，无HSE功能）

Re: S32K3 Clock init too long time

simonliu — Thu, 10 Oct 2024 06:03:05 GMT

经过测试出来发现是复位类型的影响，使用功能性复位就会出现时钟初始化时间过长问题。

不使用看门狗复位，改成破坏性复位，时钟初始化就不会时间变长。

经过进一步的测试，发现是这个时钟复位函数这里超时。

对应到寄存器，是MUX_6_CSS寄存器。

同时发现clock这部分寄存器复位会区分破坏性复位和功能性复位，寄存器仅在破坏性复位下复位，功能性复位是保持不变的。

所以实测时发现调用破坏性复位，时钟初始化的时间是正常的。

Re: S32K3 Clock init too long time

simonliu — Thu, 10 Oct 2024 06:04:03 GMT

在RM里面描述， MUX_0_CSC/CSS ~ MUX_20_CSC/CSS这个42个寄存器都是”reset on destructive reset only”。

在应用里面，需要判定当前复位类型，且需要确认功能性复位时，无需对时钟MUX-x进行再次设置，可以跳过再次“复位-设置”的过程。
但这带来的软件复杂度需要和超时的影响及RTD的完整性进行平衡。
可关注Clock_Ip_Selector.c 里面Clock_Ip_axSelectorCallbacks的宏开关CLOCK_IP_CGM_X_CSC_CSS_CS_GRIP。