S32K3 Clock init too long time

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

S32K3 Clock init too long time

跳至解决方案
531 次查看
simonliu
Contributor III

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

系统流程如下:

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

    (晶振16MHz,无HSE功能)

0 项奖励
回复
1 解答
525 次查看
simonliu
Contributor III

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

在原帖中查看解决方案

0 项奖励
回复
2 回复数
526 次查看
simonliu
Contributor III

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

0 项奖励
回复
527 次查看
simonliu
Contributor III

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

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

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

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

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

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

   

 

 

0 项奖励
回复