STM32MP257F_EV1:SPI3 Slave mode_NSS PIN (PB1) Fails to claim Despite Correct Configuration
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
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
-
Pin identity confirmed correct —
PB1is documented as the board's designatedSPI3_NSSpin 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
-
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. -
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 fineAF5: entire pin group fails to claim (all 4 pins unclaimed) — confirms AF5 is genuinely invalid for this pinAF7: PB1 unclaimed, other 3 pins claim fine (same as AF1's result)
-
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).
-
Ruled out alternative NSS pins — the datasheet also lists
SPI3_NSSas available onPH12,PC3, andPE5, 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)
-
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 viadrivers/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. -
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
- 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?
- 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?
- Alternatively, is there a known erratum or board-specific limitation affecting PB1's use as
SPI3_NSSin slave mode specifically (as opposed to master mode, where we successfully used PB1 via GPIO-basedcs-gpioschip 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.
