<?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: What should PortPinSlewRate be configured for SPI pins? (NXP MCAL 4.2.2) in MPC5xxx</title>
    <link>https://community.nxp.com/t5/MPC5xxx/What-should-PortPinSlewRate-be-configured-for-SPI-pins-NXP-MCAL/m-p/2256996#M28226</link>
    <description>&lt;P&gt;Hello,&lt;/P&gt;
&lt;DIV&gt;
&lt;P&gt;What does PortPinSlewRate do?&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;It controls how fast the pin transitions between logic levels (rise/fall time).&lt;/LI&gt;
&lt;LI&gt;Options typically include:
&lt;UL&gt;
&lt;LI&gt;FullDriveWithoutSlewRate (fastest switching, no slew rate limitation)&lt;/LI&gt;
&lt;LI&gt;Slow or Medium slew rate (adds delay to reduce EMI and ringing)&lt;/LI&gt;
&lt;LI&gt;Sometimes called Slew Rate Enabled/Disabled in hardware registers.&lt;/LI&gt;
&lt;/UL&gt;
&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;NXP’s Recommendation for SPI Pins&lt;/P&gt;
&lt;P&gt;For high-speed interfaces like SPI (SCK, MOSI, MISO, CS), NXP generally recommends:&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;Disable slew rate limitation (i.e., use FullDriveWithoutSlewRate) for reliable high-speed communication.&lt;/LI&gt;
&lt;LI&gt;Reason: Slew rate limiting can distort edges and cause timing violations at higher SPI baud rates, leading to data corruption.&lt;/LI&gt;
&lt;LI&gt;This is consistent with the hardware default: SRE = 0 → fast slew rate on most NXP MCUs.&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Why did your tests confirm this?&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;When you used FullDriveWithoutSlewRate, the SPI signals had sharp edges, meeting timing requirements.&lt;/LI&gt;
&lt;LI&gt;With slower slew rates, the rise/fall times increased, causing setup/hold violations and corruption.&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Official Guidance&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;NXP community and application notes indicate that for SPI and other high-speed signals, fast slew rate (no limitation) is preferred.&lt;/LI&gt;
&lt;LI&gt;Slower slew rates are mainly for GPIO or low-frequency signals to reduce EMI, not for SPI&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Best regards,&lt;/P&gt;
&lt;P&gt;Peter&lt;/P&gt;
&lt;/DIV&gt;</description>
    <pubDate>Mon, 08 Dec 2025 08:47:58 GMT</pubDate>
    <dc:creator>petervlna</dc:creator>
    <dc:date>2025-12-08T08:47:58Z</dc:date>
    <item>
      <title>What should PortPinSlewRate be configured for SPI pins? (NXP MCAL 4.2.2)</title>
      <link>https://community.nxp.com/t5/MPC5xxx/What-should-PortPinSlewRate-be-configured-for-SPI-pins-NXP-MCAL/m-p/2256140#M28223</link>
      <description>&lt;P&gt;Hi,&lt;BR /&gt;I am using NXP MCAL 4.2.2 and configuring SPI communication with an external slave device.&lt;BR /&gt;In the Port configuration, there is a parameter called PortPinSlewRate.&lt;/P&gt;&lt;P&gt;For SPI pins (SCK, MOSI, MISO, CS), what is the recommended value for PortPinSlewRate?&lt;/P&gt;&lt;P&gt;In my testing, I am observing data corruption in all modes except when PortPinSlewRate is configured as FullDriveWithoutSlewRate.&lt;BR /&gt;I want to confirm what NXP officially recommends for SPI communication.&lt;/P&gt;&lt;P&gt;Thanks.&lt;/P&gt;</description>
      <pubDate>Fri, 05 Dec 2025 12:43:47 GMT</pubDate>
      <guid>https://community.nxp.com/t5/MPC5xxx/What-should-PortPinSlewRate-be-configured-for-SPI-pins-NXP-MCAL/m-p/2256140#M28223</guid>
      <dc:creator>AkshayNaik1907</dc:creator>
      <dc:date>2025-12-05T12:43:47Z</dc:date>
    </item>
    <item>
      <title>Re: What should PortPinSlewRate be configured for SPI pins? (NXP MCAL 4.2.2)</title>
      <link>https://community.nxp.com/t5/MPC5xxx/What-should-PortPinSlewRate-be-configured-for-SPI-pins-NXP-MCAL/m-p/2256996#M28226</link>
      <description>&lt;P&gt;Hello,&lt;/P&gt;
&lt;DIV&gt;
&lt;P&gt;What does PortPinSlewRate do?&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;It controls how fast the pin transitions between logic levels (rise/fall time).&lt;/LI&gt;
&lt;LI&gt;Options typically include:
&lt;UL&gt;
&lt;LI&gt;FullDriveWithoutSlewRate (fastest switching, no slew rate limitation)&lt;/LI&gt;
&lt;LI&gt;Slow or Medium slew rate (adds delay to reduce EMI and ringing)&lt;/LI&gt;
&lt;LI&gt;Sometimes called Slew Rate Enabled/Disabled in hardware registers.&lt;/LI&gt;
&lt;/UL&gt;
&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;NXP’s Recommendation for SPI Pins&lt;/P&gt;
&lt;P&gt;For high-speed interfaces like SPI (SCK, MOSI, MISO, CS), NXP generally recommends:&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;Disable slew rate limitation (i.e., use FullDriveWithoutSlewRate) for reliable high-speed communication.&lt;/LI&gt;
&lt;LI&gt;Reason: Slew rate limiting can distort edges and cause timing violations at higher SPI baud rates, leading to data corruption.&lt;/LI&gt;
&lt;LI&gt;This is consistent with the hardware default: SRE = 0 → fast slew rate on most NXP MCUs.&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Why did your tests confirm this?&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;When you used FullDriveWithoutSlewRate, the SPI signals had sharp edges, meeting timing requirements.&lt;/LI&gt;
&lt;LI&gt;With slower slew rates, the rise/fall times increased, causing setup/hold violations and corruption.&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Official Guidance&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;NXP community and application notes indicate that for SPI and other high-speed signals, fast slew rate (no limitation) is preferred.&lt;/LI&gt;
&lt;LI&gt;Slower slew rates are mainly for GPIO or low-frequency signals to reduce EMI, not for SPI&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Best regards,&lt;/P&gt;
&lt;P&gt;Peter&lt;/P&gt;
&lt;/DIV&gt;</description>
      <pubDate>Mon, 08 Dec 2025 08:47:58 GMT</pubDate>
      <guid>https://community.nxp.com/t5/MPC5xxx/What-should-PortPinSlewRate-be-configured-for-SPI-pins-NXP-MCAL/m-p/2256996#M28226</guid>
      <dc:creator>petervlna</dc:creator>
      <dc:date>2025-12-08T08:47:58Z</dc:date>
    </item>
  </channel>
</rss>

