<?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>MCX MicrocontrollersのトピックFlexIO0 SPI-controller TX shifter (SHIFTCTL, PINCFG=11b) never drives its output pin, despite SHIFTS</title>
    <link>https://community.nxp.com/t5/MCX-Microcontrollers/FlexIO0-SPI-controller-TX-shifter-SHIFTCTL-PINCFG-11b-never/m-p/2404602#M5778</link>
    <description>&lt;P&gt;&lt;STRONG&gt;Board:&lt;/STRONG&gt; FRDM-MCXN236 (MCX N236, dual Cortex-M33)&lt;BR /&gt;&lt;STRONG&gt;Toolchain:&lt;/STRONG&gt; MCUXpresso IDE 25.6.136, bare-metal register-level C (no SDK peripheral drivers)&lt;BR /&gt;&lt;STRONG&gt;RM reference:&lt;/STRONG&gt; MCX N23x Reference Manual Rev. 4, 2025-03-05, Chapter 53 (FlexIO), Table 453 (SPI controller, CPHA=0 configuration)&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;What I am building:&lt;/STRONG&gt;&lt;/P&gt;&lt;P class=""&gt;FlexIO0 configured as an SPI controller per RM Table 453: 2 shifters (shifter0 = TX, shifter1 = RX) + 1 timer (timer0 = SCK, dual 8-bit counter baud mode), reading a BME280 sensor over SPI. Pins: P1_0/P1_1/P1_2 muxed to ALT6 (FLEXIO0_D8/D9/D10), confirmed correct via PORT1-&amp;gt;PCR readback.&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Observation:&lt;BR /&gt;&lt;/STRONG&gt;The RX shifter and the SCK timer output both work perfectly — SCK toggles cleanly and on-schedule (confirmed via two independent registers, see below), and SHIFTSTAT/TIMSTAT report normal, on-time, error-free completion of every transfer. But the &lt;STRONG&gt;TX shifter's own output pin (SDO, D8) never shows any electrical movement whatsoever&lt;/STRONG&gt;, regardless of what's written to it, under every variation I've been able to think of. The chip-ID register read back from the sensor is always 0x00, never the expected 0x60 (which a separate, working FlexComm/LPSPI3 driver on the same board, same sensor, same boot, reads correctly).&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Register configuration (matches RM Table 453 exactly, PINSEL substituted for real pins)&lt;BR /&gt;&lt;/STRONG&gt;&lt;BR /&gt;SHIFTCFG0 = 0x0000_0000 (RM: 0000_0000h -- start/stop bit disabled)&lt;BR /&gt;SHIFTCTL0 = 0x0083_0002 (RM: 0083_0002h, PINSEL=8 for our real D8/SDO)&lt;BR /&gt;decodes to: TIMSEL=0, TIMPOL=1(neg edge), PINCFG=3(11b, driven output),&lt;BR /&gt;PINSEL=8, PINPOL=0, SMOD=2(Transmit) -- every field verified against RM's&lt;BR /&gt;literal example, only PINSEL substituted&lt;BR /&gt;SHIFTCFG1 = 0x0000_0000&lt;BR /&gt;SHIFTCTL1 = 0x0000_0101 (RM: 0000_0101h, PINSEL=10 for our real D10/SDI)&lt;BR /&gt;TIMCMP0 = derived per RM's own formula (8-bit frames, baud divider for 1MHz SCK)&lt;BR /&gt;TIMCFG0 = 0x0100_2222 (RM literal value, no pin substitution needed)&lt;BR /&gt;TIMCTL0 = 0x01C3_0201 (RM: 01C3_0201h, PINSEL=9 for our real D9/SCK)&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;What I've ruled out, each via direct hardware evidence (debugger register/memory inspection, no oscilloscope available):&lt;BR /&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Pin mux not reaching ALT6 -- PCR readback confirms correct ALT6 config on all four pins used.&lt;/LI&gt;&lt;LI&gt;Sensor/wiring fault -- a separate, working FlexComm/LPSPI3 SPI driver reads the chip ID (0x60) correctly from the same physical sensor, same boot.&lt;/LI&gt;&lt;LI&gt;SCK never toggling on the physical pin -- confirmed toggling via TWO independent registers sampled at the same instants: FLEXIO0-&amp;gt;PIN (bit 9) and GPIO1-&amp;gt;PDIR (bit 1, a completely separate peripheral block with no FlexIO-internal logic in its path). Both agree, in real time, sample for sample.&lt;/LI&gt;&lt;LI&gt;TX byte-lane placement in SHIFTBUFBIS (the bit-swapped alias register) -- tried the low byte, the high byte (re-derived from RM 53.3.1's shift-register microarchitecture description, not just the summary table), and a byte-lane-&lt;EM&gt;agnostic&lt;/EM&gt; full 32-bit alternating write (0xAAAAAAAA) -- all produce an identical, permanently flat SDO.&lt;/LI&gt;&lt;LI&gt;TX buffer underrun (SHIFTERR) -- reads 0x0 (clean) every time, captured immediately after a successful RX-ready wait.&lt;/LI&gt;&lt;LI&gt;Pin/pad-specific fault -- retargeted shifter0's PINSEL to a completely different physical pin (D9 instead of D8); still flat. The timer, using the identical PINCFG=11b "driven output" mechanism, drives either pin correctly.&lt;/LI&gt;&lt;LI&gt;"Implicit load on enable" (RM 53.3.1: the shifter status flag sets "when data has been loaded from SHIFTBUF into the shifter &lt;STRONG&gt;or when the shifter is initially configured for Transmit mode&lt;/STRONG&gt;" -- i.e. a possible stale first-cycle load) -- ruled out via a throwaway first transfer followed by a traced, unambiguously-second transfer: identical flat result.&lt;/LI&gt;&lt;LI&gt;SHIFTBUFBIS alias write-path asymmetry -- wrote the same byte-lane-agnostic pattern through the plain, non-aliased SHIFTBUF[0] register instead of SHIFTBUFBIS[0]: identical flat result.&lt;/LI&gt;&lt;LI&gt;FLEXIO0-&amp;gt;PINOUTD/PINOUTE/PINOUTDIS (the global per-pin software output-override registers, RM 53.3.3.3) -- live readback shows all zero, meaning "controlled by timer/shifter configuration" (the normal state) on both the working SCK pin and the non-working SDO pin identically. Not the cause.&lt;/LI&gt;&lt;LI&gt;FLEXIO0-&amp;gt;PIN readback itself being unreliable -- see #3 above; independently confirmed via GPIO1-&amp;gt;PDIR.&lt;/LI&gt;&lt;LI&gt;Shifter0-instance-specific defect -- reproduced the identical flat result using &lt;STRONG&gt;shifter2&lt;/STRONG&gt; instead, configured with the bit-for-bit identical SHIFTCTL value. Same failure. Not instance-specific.&lt;/LI&gt;&lt;LI&gt;RM 53.7.1.27's documented two-step PINCFG write sequence (write 10b first, then a separate write to 11b, to avoid a brief low glitch on first configuration) -- applied directly: identical flat result.&lt;/LI&gt;&lt;/OL&gt;&lt;P class=""&gt;I also checked the one published mask-set errata document for this part (MCXN23x_0P21K Rev. 2.0) -- no FlexIO-related entries at all -- and NXP's own FlexIO-SPI application note (AN12780), which adds no guidance beyond what RM Table 453 already documents.&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Question:&lt;BR /&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Given the shifter's internal bookkeeping (SHIFTSTAT, SHIFTERR, TIMSTAT) reports completely normal, on-schedule, error-free Transmit-mode operation on every test — including the TX-ready flag correctly clearing and re-setting across multiple transfers within the same CS-bracketed transaction, which per RM 53.3.1 should only happen on a genuine timer-triggered reload — and the shift clock itself (same PINCFG=11b "driven output" mechanism, just via TIMCTL instead of SHIFTCTL) is independently proven to reach its physical pin correctly:&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Is there a known silicon behavior, an undocumented prerequisite, or an RM gap that would prevent a shifter's SHIFTCTL.PINCFG=11b Transmit-mode output specifically (as opposed to a timer's identical PINCFG=11b output) from reaching its assigned pin, on the MCXN23x mask set, even though every register-level configuration matches RM Table 453's own worked example exactly?&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Happy to share the full register-level project source and a complete, append-only investigation log (every hypothesis tried, every retraction, with exact hardware evidence for each) if useful.&lt;/P&gt;&lt;P class=""&gt;&lt;STRONG&gt;&amp;nbsp;&lt;/STRONG&gt;&lt;/P&gt;&lt;P class=""&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Thu, 13 Aug 2026 14:24:23 GMT</pubDate>
    <dc:creator>hafeezmhd</dc:creator>
    <dc:date>2026-08-13T14:24:23Z</dc:date>
    <item>
      <title>FlexIO0 SPI-controller TX shifter (SHIFTCTL, PINCFG=11b) never drives its output pin, despite SHIFTS</title>
      <link>https://community.nxp.com/t5/MCX-Microcontrollers/FlexIO0-SPI-controller-TX-shifter-SHIFTCTL-PINCFG-11b-never/m-p/2404602#M5778</link>
      <description>&lt;P&gt;&lt;STRONG&gt;Board:&lt;/STRONG&gt; FRDM-MCXN236 (MCX N236, dual Cortex-M33)&lt;BR /&gt;&lt;STRONG&gt;Toolchain:&lt;/STRONG&gt; MCUXpresso IDE 25.6.136, bare-metal register-level C (no SDK peripheral drivers)&lt;BR /&gt;&lt;STRONG&gt;RM reference:&lt;/STRONG&gt; MCX N23x Reference Manual Rev. 4, 2025-03-05, Chapter 53 (FlexIO), Table 453 (SPI controller, CPHA=0 configuration)&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;What I am building:&lt;/STRONG&gt;&lt;/P&gt;&lt;P class=""&gt;FlexIO0 configured as an SPI controller per RM Table 453: 2 shifters (shifter0 = TX, shifter1 = RX) + 1 timer (timer0 = SCK, dual 8-bit counter baud mode), reading a BME280 sensor over SPI. Pins: P1_0/P1_1/P1_2 muxed to ALT6 (FLEXIO0_D8/D9/D10), confirmed correct via PORT1-&amp;gt;PCR readback.&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Observation:&lt;BR /&gt;&lt;/STRONG&gt;The RX shifter and the SCK timer output both work perfectly — SCK toggles cleanly and on-schedule (confirmed via two independent registers, see below), and SHIFTSTAT/TIMSTAT report normal, on-time, error-free completion of every transfer. But the &lt;STRONG&gt;TX shifter's own output pin (SDO, D8) never shows any electrical movement whatsoever&lt;/STRONG&gt;, regardless of what's written to it, under every variation I've been able to think of. The chip-ID register read back from the sensor is always 0x00, never the expected 0x60 (which a separate, working FlexComm/LPSPI3 driver on the same board, same sensor, same boot, reads correctly).&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Register configuration (matches RM Table 453 exactly, PINSEL substituted for real pins)&lt;BR /&gt;&lt;/STRONG&gt;&lt;BR /&gt;SHIFTCFG0 = 0x0000_0000 (RM: 0000_0000h -- start/stop bit disabled)&lt;BR /&gt;SHIFTCTL0 = 0x0083_0002 (RM: 0083_0002h, PINSEL=8 for our real D8/SDO)&lt;BR /&gt;decodes to: TIMSEL=0, TIMPOL=1(neg edge), PINCFG=3(11b, driven output),&lt;BR /&gt;PINSEL=8, PINPOL=0, SMOD=2(Transmit) -- every field verified against RM's&lt;BR /&gt;literal example, only PINSEL substituted&lt;BR /&gt;SHIFTCFG1 = 0x0000_0000&lt;BR /&gt;SHIFTCTL1 = 0x0000_0101 (RM: 0000_0101h, PINSEL=10 for our real D10/SDI)&lt;BR /&gt;TIMCMP0 = derived per RM's own formula (8-bit frames, baud divider for 1MHz SCK)&lt;BR /&gt;TIMCFG0 = 0x0100_2222 (RM literal value, no pin substitution needed)&lt;BR /&gt;TIMCTL0 = 0x01C3_0201 (RM: 01C3_0201h, PINSEL=9 for our real D9/SCK)&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;What I've ruled out, each via direct hardware evidence (debugger register/memory inspection, no oscilloscope available):&lt;BR /&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Pin mux not reaching ALT6 -- PCR readback confirms correct ALT6 config on all four pins used.&lt;/LI&gt;&lt;LI&gt;Sensor/wiring fault -- a separate, working FlexComm/LPSPI3 SPI driver reads the chip ID (0x60) correctly from the same physical sensor, same boot.&lt;/LI&gt;&lt;LI&gt;SCK never toggling on the physical pin -- confirmed toggling via TWO independent registers sampled at the same instants: FLEXIO0-&amp;gt;PIN (bit 9) and GPIO1-&amp;gt;PDIR (bit 1, a completely separate peripheral block with no FlexIO-internal logic in its path). Both agree, in real time, sample for sample.&lt;/LI&gt;&lt;LI&gt;TX byte-lane placement in SHIFTBUFBIS (the bit-swapped alias register) -- tried the low byte, the high byte (re-derived from RM 53.3.1's shift-register microarchitecture description, not just the summary table), and a byte-lane-&lt;EM&gt;agnostic&lt;/EM&gt; full 32-bit alternating write (0xAAAAAAAA) -- all produce an identical, permanently flat SDO.&lt;/LI&gt;&lt;LI&gt;TX buffer underrun (SHIFTERR) -- reads 0x0 (clean) every time, captured immediately after a successful RX-ready wait.&lt;/LI&gt;&lt;LI&gt;Pin/pad-specific fault -- retargeted shifter0's PINSEL to a completely different physical pin (D9 instead of D8); still flat. The timer, using the identical PINCFG=11b "driven output" mechanism, drives either pin correctly.&lt;/LI&gt;&lt;LI&gt;"Implicit load on enable" (RM 53.3.1: the shifter status flag sets "when data has been loaded from SHIFTBUF into the shifter &lt;STRONG&gt;or when the shifter is initially configured for Transmit mode&lt;/STRONG&gt;" -- i.e. a possible stale first-cycle load) -- ruled out via a throwaway first transfer followed by a traced, unambiguously-second transfer: identical flat result.&lt;/LI&gt;&lt;LI&gt;SHIFTBUFBIS alias write-path asymmetry -- wrote the same byte-lane-agnostic pattern through the plain, non-aliased SHIFTBUF[0] register instead of SHIFTBUFBIS[0]: identical flat result.&lt;/LI&gt;&lt;LI&gt;FLEXIO0-&amp;gt;PINOUTD/PINOUTE/PINOUTDIS (the global per-pin software output-override registers, RM 53.3.3.3) -- live readback shows all zero, meaning "controlled by timer/shifter configuration" (the normal state) on both the working SCK pin and the non-working SDO pin identically. Not the cause.&lt;/LI&gt;&lt;LI&gt;FLEXIO0-&amp;gt;PIN readback itself being unreliable -- see #3 above; independently confirmed via GPIO1-&amp;gt;PDIR.&lt;/LI&gt;&lt;LI&gt;Shifter0-instance-specific defect -- reproduced the identical flat result using &lt;STRONG&gt;shifter2&lt;/STRONG&gt; instead, configured with the bit-for-bit identical SHIFTCTL value. Same failure. Not instance-specific.&lt;/LI&gt;&lt;LI&gt;RM 53.7.1.27's documented two-step PINCFG write sequence (write 10b first, then a separate write to 11b, to avoid a brief low glitch on first configuration) -- applied directly: identical flat result.&lt;/LI&gt;&lt;/OL&gt;&lt;P class=""&gt;I also checked the one published mask-set errata document for this part (MCXN23x_0P21K Rev. 2.0) -- no FlexIO-related entries at all -- and NXP's own FlexIO-SPI application note (AN12780), which adds no guidance beyond what RM Table 453 already documents.&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Question:&lt;BR /&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Given the shifter's internal bookkeeping (SHIFTSTAT, SHIFTERR, TIMSTAT) reports completely normal, on-schedule, error-free Transmit-mode operation on every test — including the TX-ready flag correctly clearing and re-setting across multiple transfers within the same CS-bracketed transaction, which per RM 53.3.1 should only happen on a genuine timer-triggered reload — and the shift clock itself (same PINCFG=11b "driven output" mechanism, just via TIMCTL instead of SHIFTCTL) is independently proven to reach its physical pin correctly:&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Is there a known silicon behavior, an undocumented prerequisite, or an RM gap that would prevent a shifter's SHIFTCTL.PINCFG=11b Transmit-mode output specifically (as opposed to a timer's identical PINCFG=11b output) from reaching its assigned pin, on the MCXN23x mask set, even though every register-level configuration matches RM Table 453's own worked example exactly?&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Happy to share the full register-level project source and a complete, append-only investigation log (every hypothesis tried, every retraction, with exact hardware evidence for each) if useful.&lt;/P&gt;&lt;P class=""&gt;&lt;STRONG&gt;&amp;nbsp;&lt;/STRONG&gt;&lt;/P&gt;&lt;P class=""&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 13 Aug 2026 14:24:23 GMT</pubDate>
      <guid>https://community.nxp.com/t5/MCX-Microcontrollers/FlexIO0-SPI-controller-TX-shifter-SHIFTCTL-PINCFG-11b-never/m-p/2404602#M5778</guid>
      <dc:creator>hafeezmhd</dc:creator>
      <dc:date>2026-08-13T14:24:23Z</dc:date>
    </item>
  </channel>
</rss>

