<?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>S32KのトピックNXP S32k312 HSE reset issue Understanding</title>
    <link>https://community.nxp.com/t5/S32K/NXP-S32k312-HSE-reset-issue-Understanding/m-p/2157509#M52130</link>
    <description>&lt;P&gt;Hi,&amp;nbsp;&lt;A href="https://community.nxp.com/t5/user/viewprofilepage/user-id/37795" target="_blank"&gt;@lukaszadrapa&lt;/A&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;A href="https://community.nxp.com/t5/Other-NXP-Products/NXP-s32k312-HSE-Reset-Issue/m-p/2148312#M29567" target="_blank" rel="noopener"&gt;Solved: Re: NXP s32k312 HSE Reset Issue - NXP Community&lt;/A&gt;&lt;/P&gt;&lt;P&gt;We are currently using RTD 4.0.0 and do not have the option to upgrade to a newer version. To address the HSE reset issue occurring without a debugger connection, we implemented the following&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;STRONG&gt;solution 1&lt;/STRONG&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;based on your earlier suggestion:&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Solution 1:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;/* Before configuring HSE_CLK and accessing the CONFIG_REG_GPR register,&lt;BR /&gt;the driver should wait for Secure BAF to enter WFI state by checking&lt;BR /&gt;the PRTN0_CORE2_STAT register. */&lt;BR /&gt;do {&lt;BR /&gt;WfiStatus = (BOARD_MC_ME-&amp;gt;prtn0_core2_stat &amp;amp; MC_ME_PRTN0_CORE2_STAT_WFI_MASK);&lt;BR /&gt;} while (WfiStatus != MC_ME_PRTN0_CORE2_STAT_WFI_MASK);&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;This solution is implemented during clock initialization to ensure proper reset behavior without the debugger.&lt;/P&gt;&lt;P&gt;However, the NXP community also suggests an alternate approach:&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Solution 2:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;#define MU_FSR_ADDRESS (volatile os_uint32_t*)0x4038c104U&lt;BR /&gt;#define HSE_INIT_OK_SHIFT 24U&lt;BR /&gt;#define UTEST_HSE_ENABLED_ADDRESS (volatile os_uint32_t*)0x1B000000U&lt;BR /&gt;#define UTEST_HSE_ENABLED_DEFAULT 0xFFFFFFFFU&lt;/P&gt;&lt;P&gt;if (UTEST_HSE_ENABLED_ADDRESS != UTEST_HSE_ENABLED_DEFAULT)&lt;BR /&gt;{&lt;BR /&gt;board_waitforHSEinit();&lt;BR /&gt;}&lt;/P&gt;&lt;P&gt;void board_waitforHSEinit(void)&lt;BR /&gt;{&lt;BR /&gt;volatile os_uint32_t* Mu_FSR_Address = MU_FSR_ADDRESS;&lt;BR /&gt;while (((*Mu_FSR_Address &amp;gt;&amp;gt; HSE_INIT_OK_SHIFT) &amp;amp; 0x01) != 0x01U);&lt;BR /&gt;}&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Although both solutions resolve the reset issue without a debugger, we are concerned that in&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;STRONG&gt;Solution 2&lt;/STRONG&gt;, if the HSE status bit is unexpectedly corrupted or never set (e.g., due to hardware fault), the software could get stuck indefinitely in the while loop.&lt;/P&gt;&lt;P&gt;Could you please advise which of these two approaches is more appropriate and robust for handling HSE reset issues without debugger support?&lt;/P&gt;</description>
    <pubDate>Mon, 25 Aug 2025 10:30:51 GMT</pubDate>
    <dc:creator>Anitha7</dc:creator>
    <dc:date>2025-08-25T10:30:51Z</dc:date>
    <item>
      <title>NXP S32k312 HSE reset issue Understanding</title>
      <link>https://community.nxp.com/t5/S32K/NXP-S32k312-HSE-reset-issue-Understanding/m-p/2157509#M52130</link>
      <description>&lt;P&gt;Hi,&amp;nbsp;&lt;A href="https://community.nxp.com/t5/user/viewprofilepage/user-id/37795" target="_blank"&gt;@lukaszadrapa&lt;/A&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;A href="https://community.nxp.com/t5/Other-NXP-Products/NXP-s32k312-HSE-Reset-Issue/m-p/2148312#M29567" target="_blank" rel="noopener"&gt;Solved: Re: NXP s32k312 HSE Reset Issue - NXP Community&lt;/A&gt;&lt;/P&gt;&lt;P&gt;We are currently using RTD 4.0.0 and do not have the option to upgrade to a newer version. To address the HSE reset issue occurring without a debugger connection, we implemented the following&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;STRONG&gt;solution 1&lt;/STRONG&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;based on your earlier suggestion:&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Solution 1:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;/* Before configuring HSE_CLK and accessing the CONFIG_REG_GPR register,&lt;BR /&gt;the driver should wait for Secure BAF to enter WFI state by checking&lt;BR /&gt;the PRTN0_CORE2_STAT register. */&lt;BR /&gt;do {&lt;BR /&gt;WfiStatus = (BOARD_MC_ME-&amp;gt;prtn0_core2_stat &amp;amp; MC_ME_PRTN0_CORE2_STAT_WFI_MASK);&lt;BR /&gt;} while (WfiStatus != MC_ME_PRTN0_CORE2_STAT_WFI_MASK);&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;This solution is implemented during clock initialization to ensure proper reset behavior without the debugger.&lt;/P&gt;&lt;P&gt;However, the NXP community also suggests an alternate approach:&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Solution 2:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;#define MU_FSR_ADDRESS (volatile os_uint32_t*)0x4038c104U&lt;BR /&gt;#define HSE_INIT_OK_SHIFT 24U&lt;BR /&gt;#define UTEST_HSE_ENABLED_ADDRESS (volatile os_uint32_t*)0x1B000000U&lt;BR /&gt;#define UTEST_HSE_ENABLED_DEFAULT 0xFFFFFFFFU&lt;/P&gt;&lt;P&gt;if (UTEST_HSE_ENABLED_ADDRESS != UTEST_HSE_ENABLED_DEFAULT)&lt;BR /&gt;{&lt;BR /&gt;board_waitforHSEinit();&lt;BR /&gt;}&lt;/P&gt;&lt;P&gt;void board_waitforHSEinit(void)&lt;BR /&gt;{&lt;BR /&gt;volatile os_uint32_t* Mu_FSR_Address = MU_FSR_ADDRESS;&lt;BR /&gt;while (((*Mu_FSR_Address &amp;gt;&amp;gt; HSE_INIT_OK_SHIFT) &amp;amp; 0x01) != 0x01U);&lt;BR /&gt;}&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Although both solutions resolve the reset issue without a debugger, we are concerned that in&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;STRONG&gt;Solution 2&lt;/STRONG&gt;, if the HSE status bit is unexpectedly corrupted or never set (e.g., due to hardware fault), the software could get stuck indefinitely in the while loop.&lt;/P&gt;&lt;P&gt;Could you please advise which of these two approaches is more appropriate and robust for handling HSE reset issues without debugger support?&lt;/P&gt;</description>
      <pubDate>Mon, 25 Aug 2025 10:30:51 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/NXP-S32k312-HSE-reset-issue-Understanding/m-p/2157509#M52130</guid>
      <dc:creator>Anitha7</dc:creator>
      <dc:date>2025-08-25T10:30:51Z</dc:date>
    </item>
    <item>
      <title>Re: NXP S32k312 HSE reset issue Understanding</title>
      <link>https://community.nxp.com/t5/S32K/NXP-S32k312-HSE-reset-issue-Understanding/m-p/2157584#M52136</link>
      <description>&lt;P&gt;&lt;A href="https://community.nxp.com/t5/S32K/NXPs32k312-HSE-reset-issue/m-p/2157583/highlight/true#M52135" target="_blank"&gt;https://community.nxp.com/t5/S32K/NXPs32k312-HSE-reset-issue/m-p/2157583/highlight/true#M52135&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 25 Aug 2025 13:33:53 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/NXP-S32k312-HSE-reset-issue-Understanding/m-p/2157584#M52136</guid>
      <dc:creator>lukaszadrapa</dc:creator>
      <dc:date>2025-08-25T13:33:53Z</dc:date>
    </item>
  </channel>
</rss>

