<?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のトピックRe: s32k312 Software reset time</title>
    <link>https://community.nxp.com/t5/S32K/Re-s32k312-Software-reset-time/m-p/2163144#M52383</link>
    <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/253285"&gt;@sensen_1&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;I imagine you mean 2ms and 4.5ms for the response after a reset, correct?&lt;/P&gt;
&lt;P&gt;You could try skipping most initialization until &lt;EM&gt;after&lt;/EM&gt; you respond to the UDS. For example, check for a functional reset with&amp;nbsp;&lt;SPAN&gt;Power_Ip_GetResetReason() API. After this, don’t switch to FXOSC/PLL until&amp;nbsp;after&amp;nbsp;the first UDS reply. FIRC is available quickly by default; FXOSC stabilization and PLL lock could cause additional overhead when initializing.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;You can also try sending an NRC&amp;nbsp;0x78 (&lt;SPAN&gt;ResponsePending&lt;/SPAN&gt;) command before issuing the reset to buy some time to respond to upper computer.&lt;/P&gt;
&lt;P&gt;Best regards,&lt;BR /&gt;Julián&lt;/P&gt;</description>
    <pubDate>Wed, 03 Sep 2025 21:46:35 GMT</pubDate>
    <dc:creator>Julián_AragónM</dc:creator>
    <dc:date>2025-09-03T21:46:35Z</dc:date>
    <item>
      <title>Re: s32k312 Software reset time</title>
      <link>https://community.nxp.com/t5/S32K/Re-s32k312-Software-reset-time/m-p/2162444#M52382</link>
      <description>hi，julian:&lt;BR /&gt;Sorry, I made a mistake. I used block0 as the boot program area and block1 as the app program area. From the upper computer giving the boot program reset command, to the boot reset and jumping to the app for UDS response, the upper computer gave 0.2 seconds, but the normal response takes about 0.45 seconds after the reset command.</description>
      <pubDate>Wed, 03 Sep 2025 01:02:56 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/Re-s32k312-Software-reset-time/m-p/2162444#M52382</guid>
      <dc:creator>sensen_1</dc:creator>
      <dc:date>2025-09-03T01:02:56Z</dc:date>
    </item>
    <item>
      <title>Re: s32k312 Software reset time</title>
      <link>https://community.nxp.com/t5/S32K/Re-s32k312-Software-reset-time/m-p/2163144#M52383</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/253285"&gt;@sensen_1&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;I imagine you mean 2ms and 4.5ms for the response after a reset, correct?&lt;/P&gt;
&lt;P&gt;You could try skipping most initialization until &lt;EM&gt;after&lt;/EM&gt; you respond to the UDS. For example, check for a functional reset with&amp;nbsp;&lt;SPAN&gt;Power_Ip_GetResetReason() API. After this, don’t switch to FXOSC/PLL until&amp;nbsp;after&amp;nbsp;the first UDS reply. FIRC is available quickly by default; FXOSC stabilization and PLL lock could cause additional overhead when initializing.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;You can also try sending an NRC&amp;nbsp;0x78 (&lt;SPAN&gt;ResponsePending&lt;/SPAN&gt;) command before issuing the reset to buy some time to respond to upper computer.&lt;/P&gt;
&lt;P&gt;Best regards,&lt;BR /&gt;Julián&lt;/P&gt;</description>
      <pubDate>Wed, 03 Sep 2025 21:46:35 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/Re-s32k312-Software-reset-time/m-p/2163144#M52383</guid>
      <dc:creator>Julián_AragónM</dc:creator>
      <dc:date>2025-09-03T21:46:35Z</dc:date>
    </item>
  </channel>
</rss>

