STM32MP257F_EV1:SPI3 Slave mode_NSS PIN (PB1) Fails to claim

[Radha Kadam]

On the STM32MP257F-EV1 evaluation board, configuring SPI3 in slave mode (spi-slave;) works correctly for the SCK, MOSI, and MISO signals, but the NSS (chip select) pin — PB1, using the documented-correct AF1 alternate function — silently fails to be claimed by the pin controller. No error or warning is logged anywhere. All three other SPI3 pins on the same bus, using the same AF1 value, claim successfully.

[Erwan SZYMANSKI]

Hello ​@Radha Kadam,
Could you please share the information that let you think that the pin fails to be claimed ? I guess you modified the pinctrl device tree to add the NSS pin under spi3_pins_a right ? 

Kind regards,
Erwan.

[Radha Kadam]

Hardware

• Board: STM32MP257F-EV1 (MB1936)
• MPU: STM32MP257FAI3
• OpenSTLinux version: 5.0.15-openstlinux-6.6-yocto-scarthgap-mpu-v26.02.18
• Kernel: Linux 6.6.116-stm32mp-r3

What we are trying to do

Configure SPI3 as an SPI slave (spi-slave; device tree property) so the STM32MP2 can receive data from an external SPI master over the same bus/pins already used for a sensor (previously configured as SPI master).

Configuration used

Custom pinctrl group (added to stm32mp25-pinctrl.dtsi):

spi3_slave_pins_a: spi3-slave-0 {

   pins1 {

       pinmux = <STM32_PINMUX('B', 7, AF1)>, /* SPI3_SCK */

                <STM32_PINMUX('B', 8, AF1)>, /* SPI3_MOSI */

                <STM32_PINMUX('B', 1, AF1)>; /* SPI3_NSS */

       drive-push-pull;

       bias-disable;

       slew-rate = <1>;

   };

   pins2 {

       pinmux = <STM32_PINMUX('B', 10, AF1)>; /* SPI3_MISO */

       bias-disable;

   };

};

Board &spi3 node (stm32mp257f-ev1.dts):

&spi3 {

   pinctrl-names = "default", "sleep";

   pinctrl-0 = <&spi3_slave_pins_a>;

   pinctrl-1 = <&spi3_sleep_pins_a>;

   status = "okay";

   spi-slave;

};

Observed behavior

Kernel boot log:

spi_stm32 400c0000.spi: driver initialized (device mode)

The driver initializes correctly in slave ("device") mode — confirming SPI3's own RIF (Resource Isolation Framework) access grant is valid, since this driver init would fail/be silent entirely if RIF blocked the peripheral itself (we independently observed this exact silent-failure behavior on SPI8, a different bus, where RIF access is not granted, for comparison).

Pin claim status (/sys/kernel/debug/pinctrl/*/pinmux-pins):

pin 17 (PB1):  UNCLAIMED

pin 23 (PB7):  device 400c0000.spi function analog group PB7   [SCK, correct]

pin 24 (PB8):  device 400c0000.spi function analog group PB8   [MOSI, correct]

pin 26 (PB10): device 400c0000.spi function analog group PB10  [MISO, correct]

Three of four pins in the exact same pinctrl group, using the exact same AF1 value, claim successfully. Only PB1 (NSS) fails — silently, with no kernel warning or error message anywhere in dmesg, even after ruling out all other configuration issues on the board (see below).

What we have already verified/ruled out

1. Pin identity confirmed correct — PB1 is documented as the board's designated SPI3_NSS pin in three independent official sources:

   • UM3359 (board user manual) Table 29, GPIO connector pinout
   • UM3359 Table 32, full board I/O assignment
   • STM32MP257 datasheet, pin description table

2. AF value confirmed correct — the STM32MP257 datasheet's "Alternate functions AF0 to AF7" table shows PB1 → AF1 = SPI3_NSS/I2S3_WS, matching the same AF1 value used successfully by SCK/MOSI/MISO on the same peripheral.

3. Tested multiple AF values directly on hardware to rule out a simple documentation/numbering error:

   • AF1 (documented-correct value): PB1 unclaimed, other 3 pins claim fine
   • AF5: entire pin group fails to claim (all 4 pins unclaimed) — confirms AF5 is genuinely invalid for this pin
   • AF7: PB1 unclaimed, other 3 pins claim fine (same as AF1's result)

4. Ruled out a pin/peripheral conflict — no other enabled peripheral in our device tree claims PB1. GPIOB bank is confirmed enabled (other GPIOB pins PB7/PB8/PB10 work correctly).

5. Ruled out alternative NSS pins — the datasheet also lists SPI3_NSS as available on PH12, PC3, and PE5, but all three are already committed to essential on-board functions per UM3359 Table 32:

   • PH12 → Ethernet 1 (ETH1.RXD3)
   • PC3 → Ethernet 2 (ETH2.RX_CTL)
   • PE5 → microSD card (SDMMC1_D1)

6. Ruled out a leftover/conflicting configuration — we had separately (and unsuccessfully) attempted SPI8 slave mode on a different pin (PA14), which produced a different, clearly-logged error (invalid function 4 on pin 14, i.e., PA14, confirmed via drivers/pinctrl/stm32/pinctrl-stm32.c:825). After fully disabling that SPI8 configuration, PB1 still fails with zero log output — ruling out this as a confound.

7. RIF (Resource Isolation Framework) considered — SPI3's own RIF grant (access-controllers = <&rifsc 24>;) is clearly valid (driver initializes successfully). We suspect RIF may filter this specific physical pin/pad independently of the peripheral's own grant (STM32 RIF can secure individual GPIO pads separately from the peripherals using them), which would explain a silent, unlogged failure — but we have not found documentation confirming or denying this, and could not locate per-pin RIF configuration in the OP-TEE or TF-A source trees we examined.

Question for ST

1. Is there a known RIF restriction (or other pad-level security mechanism) on PB1 specifically for the STM32MP257 that would prevent Linux (non-secure world) from configuring it for the SPI3_NSS alternate function, even though the SPI3 peripheral itself has confirmed non-secure access?
2. If so, is there a way to grant this specific pin's alternate-function configuration to the non-secure world (e.g., via OP-TEE/TF-A RIF configuration), and if so, where is that configured for this board?
3. Alternatively, is there a known erratum or board-specific limitation affecting PB1's use as SPI3_NSS in slave mode specifically (as opposed to master mode, where we successfully used PB1 via GPIO-based cs-gpios chip select)?

Additional context

PB1 works correctly today as a GPIO-controlled chip select (cs-gpios = <&gpiob 1 GPIO_ACTIVE_LOW>;) when SPI3 is configured as master. The issue only manifests when attempting to use PB1's genuine hardware NSS alternate function in slave mode.

[Erwan SZYMANSKI]

Hello ​@Radha Kadam ,
Are you sure you did respect every property mentioned in the wiki article to setup SPI slave mode ? See https://wiki.st.com/stm32mpu/wiki/SPI_device_tree_configuration#Example_of_SPI_master-2Fslave_communication_on_STM32MP157F-DK2_board

By respecting the properties define here (and changing the pinctrl in both spi3_pins and sleep_pins), you should see something like that (I just have made the manip on my side to reproduce):

root@stm32mp2-e3-ad-dd:~# cat /sys/kernel/debug/pinctrl/soc@0:pinctrl@44240000/pinmux-pins | grep spi
pin 17 (PB1): device 400c0000.spi function analog group PB1
pin 23 (PB7): device 400c0000.spi function analog group PB7
pin 24 (PB8): device 400c0000.spi function analog group PB8
pin 26 (PB10): device 400c0000.spi function analog group PB10

Please can you retry and confirm on your side ?

Kind regards,
Erwan.

PS: As I see that your other pins are in alternate function “analog”, I guess you forgot to declare the NSS in sleep pins and so it only takes the one declared. It is possible that when you will start your SPI3 instance to make it work, the IOs will switch to real AF function, and your NSS can appear at this time.

 

[Radha Kadam]

STM32MP257F-EV1: SPI3 Slave Mode — NSS Pin (PB1) Fails to Claim Despite Correct Configuration

Summary

On the STM32MP257F-EV1 evaluation board, configuring SPI3 in slave mode (spi-slave;) works correctly for the SCK, MOSI, and MISO signals, but the NSS (chip select) pin — PB1, using the documented-correct AF1 alternate function — silently fails to be claimed by the pin controller. No error or warning is logged anywhere. All three other SPI3 pins on the same bus, using the same AF1 value, claim successfully.

Hardware

• Board: STM32MP257F-EV1 (MB1936)
• MPU: STM32MP257FAI3
• OpenSTLinux version: 5.0.15-openstlinux-6.6-yocto-scarthgap-mpu-v26.02.18
• Kernel: Linux 6.6.116-stm32mp-r3

What we are trying to do

Configure SPI3 as an SPI slave (spi-slave; device tree property) so the STM32MP2 can receive data from an external SPI master over the same bus/pins already used for a sensor (previously configured as SPI master).

Configuration used (current)

Custom pinctrl group (added to stm32mp25-pinctrl.dtsi), following the grouping convention from ST's own wiki article on SPI master/slave configuration (NSS grouped with MISO as an input-only pin, matching the reference STM32MP157F-DK2 example):

spi3_slave_pins_a: spi3-slave-0 {
    pins1 {
        pinmux = <STM32_PINMUX('B', 7, AF1)>, /* SPI3_SCK */
                 <STM32_PINMUX('B', 8, AF1)>; /* SPI3_MOSI */
        drive-push-pull;
        bias-disable;
        slew-rate = <1>;
    };
    pins2 {
        pinmux = <STM32_PINMUX('B', 10, AF1)>, /* SPI3_MISO */
                 <STM32_PINMUX('B', 1, AF1)>;  /* SPI3_NSS */
        bias-disable;
    };
};

Board &spi3 node (stm32mp257f-ev1.dts):

&spi3 {
    pinctrl-names = "default", "sleep";
    pinctrl-0 = <&spi3_slave_pins_a>;
    pinctrl-1 = <&spi3_sleep_pins_a>;
    status = "okay";
    spi-slave;
};

Observed behavior

Kernel boot log:

spi_stm32 400c0000.spi: driver initialized (device mode)

The driver initializes correctly in slave ("device") mode — confirming SPI3's own RIF (Resource Isolation Framework) access grant is valid.

Pin claim status (/sys/kernel/debug/pinctrl/*/pinmux-pins):

pin 17 (PB1):  UNCLAIMED
pin 23 (PB7):  device 400c0000.spi function analog group PB7   [SCK, correct]
pin 24 (PB8):  device 400c0000.spi function analog group PB8   [MOSI, correct]
pin 26 (PB10): device 400c0000.spi function analog group PB10  [MISO, correct]

Three of four pins in the exact same pinctrl group, using the exact same AF1 value, claim successfully. Only PB1 (NSS) fails — silently, with no kernel warning or error message anywhere in dmesg.

What we have already verified/ruled out

1. Pin identity confirmed correct — PB1 is documented as the board's designated SPI3_NSS pin in three independent official sources (UM3359 Table 29, UM3359 Table 32, STM32MP257 datasheet pin description table).

2. AF value confirmed correct — the STM32MP257 datasheet's "Alternate functions AF0 to AF7" table shows PB1 → AF1 = SPI3_NSS/I2S3_WS, matching the same AF1 value used successfully by SCK/MOSI/MISO on the same peripheral. Verified independently via both automated PDF text extraction and direct visual inspection of the datasheet table by us.

3. Tested multiple AF values directly on hardware:

   • AF1 (documented-correct value): PB1 unclaimed, other 3 pins claim fine
   • AF5: entire pin group fails to claim (all 4 pins unclaimed) — confirms AF5 is genuinely invalid for this pin
   • AF7: PB1 unclaimed, other 3 pins claim fine (same as AF1's result)

4. Ruled out a pin/peripheral conflict — no other enabled peripheral in our device tree claims PB1. GPIOB bank is confirmed enabled (other GPIOB pins PB7/PB8/PB10 work correctly).

5. Ruled out alternative NSS pins — the datasheet also lists SPI3_NSS as available on PH12, PC3, and PE5, but all three are already committed to essential on-board functions per UM3359 Table 32 (PH12→Ethernet 1, PC3→Ethernet 2, PE5→microSD card).

6. Ruled out a leftover/conflicting configuration — a separate, unsuccessful SPI8 slave-mode attempt on a different pin (PA14) was fully disabled; confirmed via a clean dmesg with zero errors afterward (PB1 still silently fails with no confound present).

7. RIF (Resource Isolation Framework) checked directly via /sys/kernel/debug/stm32_firewall/rifsc — SPI3's own RIF grant is confirmed fully open (NSEC/NPRIV/no CID filtering). GPIO pin-level RIF configuration (st,protreg in the board's OP-TEE -rif.dtsi file) was also checked directly: PB1's RIF configuration is byte-for-byte identical to the three working pins (RIF_UNUSED, RIF_UNLOCK, RIF_NSEC, RIF_PRIV, RIF_CID1, RIF_SEM_DIS, RIF_CFEN), ruling out a pin-specific RIF restriction as the cause.

8. Tested electrical property grouping — following ST's own wiki documentation example for SPI master/slave configuration (which groups NSS with MISO as an input-only pin, using only bias-disable, rather than with SCK/MOSI's output-driver properties drive-push-pull/ slew-rate), we restructured our pinctrl groups to match this exact pattern. Result: no change — PB1 still fails to claim.

Question for ST

1. Is there a known silicon erratum, ROM-code-level restriction (e.g., BSEC/OTP fuse-based pin muxing restriction), or other mechanism — invisible to device tree, RIF configuration, and kernel logging — that would prevent PB1 specifically from being configured for the SPI3_NSS alternate function in slave mode, despite every other verifiable configuration parameter being correct?
2. Is there a known erratum or board-specific limitation affecting PB1's use as SPI3_NSS in slave mode specifically (as opposed to master mode, where we successfully use PB1 via GPIO-based cs-gpios chip select today)?
3. Given that even matching ST's own reference wiki documentation's exact pin-grouping/electrical-property convention did not resolve this, what further diagnostic step would ST recommend?

Additional context

PB1 works correctly today as a GPIO-controlled chip select (cs-gpios = <&gpiob 1 GPIO_ACTIVE_LOW>;) when SPI3 is configured as master. The issue only manifests when attempting to use PB1's genuine hardware NSS alternate function in slave mode.

[Erwan SZYMANSKI]

Hello ​@Radha Kadam ,
Are you sure the pin is still UNCLAIMED if you declare the NSS pin in your spi3_sleep_pins_a node ? See my message above.

Kind regards,
Erwan.