<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Clock Failure in MPC5746C in MPC5xxx</title>
    <link>https://community.nxp.com/t5/MPC5xxx/Clock-Failure-in-MPC5746C/m-p/1778021#M24656</link>
    <description>&lt;P&gt;The frequency of the IRCOSC clock is monitored by the frequency meter in the CMU_0. There is no automated trigger of the FCCU error condition if the IRCOSC fails. Because the IRCOSC is both the boot and the backup clock, the failure is catastrophic.&lt;BR /&gt;&lt;BR /&gt;Each CMU’s FHH and FLL event indicator is connected solely to the FCCU. Therefore, the CMU_0’s connection to the FCCU in the following figure represents all CMU instances. &lt;BR /&gt;The period of the IRCOSC can be measured in the CMU0, using the XOSC as a reference. This enables the application trimming of the IRCOSC frequency.&lt;/P&gt;
&lt;P&gt;Loosing of IRCOSC clok is considered as rare situation. I am not aware that specific description of the mechanism of the error would be described (probably it is not). In general we could say 'device malfunction' whichever the reason of that would be (operating out of specification whatever way, ESD and so).&lt;/P&gt;</description>
    <pubDate>Wed, 20 Dec 2023 14:34:57 GMT</pubDate>
    <dc:creator>davidtosenovjan</dc:creator>
    <dc:date>2023-12-20T14:34:57Z</dc:date>
    <item>
      <title>Clock Failure in MPC5746C</title>
      <link>https://community.nxp.com/t5/MPC5xxx/Clock-Failure-in-MPC5746C/m-p/1776983#M24643</link>
      <description>&lt;P&gt;What are the possible reasons for a clock failure in the microcontroller,&amp;nbsp;&lt;SPAN&gt;that lead to either of the following scenarios:&lt;/SPAN&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;SPAN&gt;CMU_ISR[FLLI] bit or&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN&gt;CMU_ISR[FHHI] bit is set.&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;FIRC measured frequency is out of a prefixed range in software.&lt;/SPAN&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 19 Dec 2023 11:57:31 GMT</pubDate>
      <guid>https://community.nxp.com/t5/MPC5xxx/Clock-Failure-in-MPC5746C/m-p/1776983#M24643</guid>
      <dc:creator>Sagar10</dc:creator>
      <dc:date>2023-12-19T11:57:31Z</dc:date>
    </item>
    <item>
      <title>Re: Clock Failure in MPC5746C</title>
      <link>https://community.nxp.com/t5/MPC5xxx/Clock-Failure-in-MPC5746C/m-p/1778021#M24656</link>
      <description>&lt;P&gt;The frequency of the IRCOSC clock is monitored by the frequency meter in the CMU_0. There is no automated trigger of the FCCU error condition if the IRCOSC fails. Because the IRCOSC is both the boot and the backup clock, the failure is catastrophic.&lt;BR /&gt;&lt;BR /&gt;Each CMU’s FHH and FLL event indicator is connected solely to the FCCU. Therefore, the CMU_0’s connection to the FCCU in the following figure represents all CMU instances. &lt;BR /&gt;The period of the IRCOSC can be measured in the CMU0, using the XOSC as a reference. This enables the application trimming of the IRCOSC frequency.&lt;/P&gt;
&lt;P&gt;Loosing of IRCOSC clok is considered as rare situation. I am not aware that specific description of the mechanism of the error would be described (probably it is not). In general we could say 'device malfunction' whichever the reason of that would be (operating out of specification whatever way, ESD and so).&lt;/P&gt;</description>
      <pubDate>Wed, 20 Dec 2023 14:34:57 GMT</pubDate>
      <guid>https://community.nxp.com/t5/MPC5xxx/Clock-Failure-in-MPC5746C/m-p/1778021#M24656</guid>
      <dc:creator>davidtosenovjan</dc:creator>
      <dc:date>2023-12-20T14:34:57Z</dc:date>
    </item>
  </channel>
</rss>

