RE: nRF54L15 configurable sQSPI pins feature request

AHaug — Thu, 03 Sep 2026 07:26:26 GMT

Hi Piet,

I assume that the context here's the sQSPI to interface the nRF54L15 and the nRF7001. If that is the case then you're understanding is correct.

sQSPI for VPR/FLPR VIO[0] is P2.1 for the CLK pin. VIO[1-5] are mapped to the pins in my suggested route. This is a hardware limitation in the sQSPI implementation on the L15 where only VIO[0-5] can be used.

Kind regards,
Andreas

RE: nRF54L15 configurable sQSPI pins feature request

Piet0 — Wed, 02 Sep 2026 12:11:50 GMT

Hi Andreas, we have a PCB design featuring the nrf54l15 and the nrf7001 (shared antenna PCB) where the pins are connected in the following way:

sck p2.06
cs p2.05
d0 p2.07
d1 p2.08
d2 p2.09
d3 p2.10

Is this not correct and should be done in the following way? route SCK to P2.01, IO0 to P2.02, IO1 to P2.04, IO2 to P2.03, IO3 to P2.00, CSN to P2.05,

Kind regards,

Piet

RE: nRF54L15 configurable sQSPI pins feature request

AHaug — Tue, 07 Jul 2026 09:13:36 GMT

Hi Ulf,

Yes, you are right here. Took some time to gather the relevant info, but to reiterate/summarize:

From the driver, every use of p_config->pins.* on nRF54L does this:

nrf_gpio_cfg(pin, ...) configures the pad's DIR, INPUT, pull, drive strength on the CPU-side GPIO peripheral.
nrf_gpio_pin_control_select(pin, NRF_GPIO_PIN_SEL_VPR) — sets PIN_CNF.CTRLSEL = VPR on that pad so it listens to its (silicon-fixed) FLPR output channel.

There is no third step where the pin numbers get written into shared RAM / a control-block register / a firmware handshake. So the sQSPI firmware has no runtime knowledge of which pins to drive. It just writes to FLPR output channels 0..5, and whichever pads happen to be wired to those channels are what it drives.

Only the six pins on P2 that the silicon wires to VIO channels 0..5, in this exact role order:

VIO ch	Pin	sQSPI role	Pad direction	Input buffer	Pull
0	P2.01	SCK	Output	Disconnected	No pull
1	P2.02	IO0	Output	Connected	Pull-up
2	P2.04	IO1	Output	Connected	Pull-up
3	P2.03	IO2	Output	Connected	Pull-up
4	P2.00	IO3	Output	Connected	Pull-up
5	P2.05	CSN	Output	Disconnected	No pull

A few sources:

Datasheet, Pin assignments — Dedicated pins: "FLPR — Uses dedicated pins on P2 for emulated peripherals such as QSPI."
Datasheet package pin tables (QFN48 / QFN52 / QFN40 / CSP47): P2.00..P2.05 each list "QSPI D3 / SCK / D0 / D2 / D1 / CSN" as their FLPR (QSPI) dedicated function.
sQSPI porting guide, GPIO configuration: the default GPIO/pad table.
NCS docs, Real-time peripherals — VPR IO: the VIO-index ↔ physical-pin table.

Additional constraints that go with this:

Role order is fixed. Because the sQSPI FLPR firmware (v1.2.1) hardcodes "SCK = VIO ch 0, IO0 = VIO ch 1, ...", you can't e.g. put SCK on P2.02. If you pass a different pin ordering in nrf_sqspi_cfg_t.pins, the CPU driver will configure the wrong pads but the signal will still come out on the six pins above.
P2.06..P2.10 don't work for sQSPI. They exist as VIO channels 6..10, but v1.2.1 sQSPI only writes to channels 0..5.
P0.x and P1.x can never work due to no VIO wiring at all, i.e a hardware limitation.

So for a working PCB layout: route SCK to P2.01, IO0 to P2.02, IO1 to P2.04, IO2 to P2.03, IO3 to P2.00, CSN to P2.05, and no substitutions.

I've asked the softperipheral team for the request/question if it is possible to expand the VIO table to include P2.06-2.10 or if this is restricted by design choice (I'm suspecting the latter)

Kind regards,
Andreas