S32K3 Clock init too long time

[simonliu]

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

系统流程如下：

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

    （晶振16MHz，无HSE功能）

[simonliu · Accepted solution]

在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。

[simonliu]

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

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

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

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

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

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