nRF54L15 configurable sQSPI pins feature request

Hi,

In our PCB using the nRF54L15, we used different P2 pins for the sQSPI, believing after reading the docs and driver API, that one could configure different pins than the defaults. Looking at the C driver, however, it looks like the pin numbers are not exchanged with the FLPR core, and just used for configuring them, so we came to the conclusion that using different GPIO P2 pins for sQSPI is not supported with 1.2.1 sQSPI firmware.

Is this assessment correct?

Would it be possible to make the GPIO pins used for sQSPI configurable in the future, by adding some register for setting that to the shared control block for instance?

Parents

0 AHaug 7 days ago

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

Reply