Could you please provide the mapping of failure events to the respective CMU instances (CMU0, CMU1, and CMU2)?
The interrupt documentation lists a total of seven interrupts, but it is not clear which failure events are handled by each CMU instance and their corresponding failure actions.
Please see attached imagessystem clock monitoring.png
Interruptmapping.png
What is the exact meaning of the "Reset Reaction Interrupt"?
Does this interrupt get generated prior to a destructive reset, allowing software intervention before the reset occurs?The clock monitoring latency can be configured from 1 µs to 1 ms.
Does selecting a lower latency effectively reduce the debounce/filtering time and make clock failure detection more sensitive or faster?
Hi@WadkarY
1.Could you please provide the mapping of failure events to the respective CMU instances (CMU0, CMU1, and CMU2)?
As can be seen, only CMU_FC_0，CMU_FM_1,CMU_FM_2 is configurable as an interrupt; the others should be treated by default as sources of a destructive reset, rather than as standard CMU interrupts.
CMU_FC_0->CMU0
CMU_FM_1->CMU1
CMU_FM_2->CMU2
CMU_FC_3->CORE_CLK_FAIL CMU reset reaction interrupt
CMU_FC_4->AIPS_PLAT_CLK_FAIL CMU reset reaction interrupt
CMU_FC_5->HSE_CLK_FAIL CMU reset reaction interrupt
CMU_FC_6->CM7_CORE_CLK_FAIL CMU reset reaction interrupt
2.Does this interrupt get generated prior to a destructive reset, allowing software intervention before the reset occurs?
No， expect destructive reset behavior unless the MC_RGM/DCM destructive-reset interrupt bypass is deliberately configured
for example:
1.CMU_FC_4 detects AIPS_PLAT_CLK frequency exceeding the threshold
↓
Destructive Reset asserted + IRQ 215 issued simultaneously
↓ Almost instantaneously
MCU reset → Restart from Reset Vector
↓
Software reads MC_RGM.DES[AIPS_PLAT_CLK_FAIL] to identify the reset cause
3.Does selecting a lower latency effectively reduce the debounce/filtering time and make clock failure detection more sensitive or faster?
This parameter is related to REF_CNT.
•Higher values of RCCR[REF_CNT] results in longer measurement window, leading to better accuracy in monitored clock check.
•Lower values of RCCR[REF_CNT] results in shorter measurement window, leading to faster FHH and FLL event response, but higher inaccuracy in reported result.
The “CMU reset reaction interrupt” should not be interpreted as an early-warning interrupt before the destructive reset. For these CMU fault sources, when configured with their destructive-reset reaction, the reset request and the corresponding MC_RGM reset-reaction interrupt are generated essentially at the same time. Therefore, software must not rely on entering the ISR and completing recovery actions before the destructive reset occurs.
The interrupt is part of the MC_RGM reset-reaction mechanism and is relevant to configurations where the applicable reset reaction can be redirected/bypassed to an interrupt. If the source remains configured for destructive reset, the normal software strategy is to allow the reset to occur and, after restart, check the corresponding MC_RGM.DES status flag to determine the reset cause.
Thank you for your reply.
Could you help to understand the maximum deviation possible in case of PLL clock?
From data sheet we got maximum deviation allowed in case of FIRC and SIRC i.e. 5% and 10% resp.
Could you please clarify deviation of PLL as it is not mentioned in DS.
There is no separate large deviation spec for the PLL because it is not applicable. The PLL output frequency accuracy equals the reference crystal accuracy, plus a small jitter contribution that the datasheet quantifies as "JPLL_acc" in the PLL characteristics table.
Hello Team,
thank you for your response.
But I am not able to understand the meaning of "Reset Reaction Interrupt" and its purpose?
CMU_FC_3->CORE_CLK_FAIL CMU reset reaction interrupt
CMU_FC_4->AIPS_PLAT_CLK_FAIL CMU reset reaction interrupt
CMU_FC_5->HSE_CLK_FAIL CMU reset reaction interrupt
CMU_FC_6->CM7_CORE_CLK_FAIL CMU reset reaction interrupt
Could you please clarify whether these interrupts provide an opportunity for software intervention before a destructive reset is generated?
- If yes, how can the software intervene and prevent or handle the reset?
- If no, what is the purpose of generating these interrupts if a destructive reset will occur immediately afterward?