SPIS00 configuration issue on nRF54L15

[Gregory C]

Hi,

We developed our custom BLE electronic board based on the nRF54L15 SoC. On this project the nRF54L15 firmware setup a SPI slave interface in order to receive commands from a host MCU. All SPI lines are currently mapped on GPIO port P2. According to the nRF54L15 datasheet, I understand we have to use SPIS00 peripheral since it is the only one SPIS instance that can be mapped on this port without using dedicated pins.

The problem is this SPIS00 is not triggering any NRFX_SPIS_XFER_DONE event when receiving a SPI command from the host (looks like SPIS driver is not configured correctly).
In order to verify that this behavior isn't due to a hardware issue from our custom board, I realized the same test on the Nordic nRF54L15 DK board. Strangely I am able to communicate over SPI when selecting SPIS30 instance, but I doesn't work with SPIS00 too.

I used the following pins mapping on the Nordic nRF54L15 DK

	SPIS00	SPIS30
MOSI Pin	P2.0	P0.0
MISO Pin	P2.1	P0.1
SCK Pin	P2.2	P0.2
CSN Pin	P2.3	P0.3

To perform this test on the nRF54L15 DK I had to realize a couple of board settings / solder bridge configurations :

• I disabled UART0 through the Nordic Board Configuration tool to disconnect P0.0 to P0.3 from on-board debugger.
• I cut solder bridges SB11 to SB16 to disconnect P2.0 to P2.3 from QSPI flash memory and shortcut solder bridges SB17 to SB22 to connect P2.0 to P2.3 to the P2 GPIO connector.

On software side, I created a new application started from the nrfx_spim_spis Non-blocking example. I removed all part concerning SPIM driver.

I created a device tree overlay to support "nordic,nrf-spis" driver on both SPI00 and SPI30 peripherals and I enabled CONFIG_NRFX_SPIS00 and CONFIG_NRFX_SPIS30 configurations in prj.conf.

In the he nrfx_spim_spis Non-blocking example, SPIS pins mapping are directly declared inside the source code and doesn't use the pins description of the device tree. Looking deeper inside the Nordic nfx_spis library, I realized that the SPI pin number set inside the nrfx_spis_config_t structure shall combine the GPIO port number and the pin number (this is not really obvious in the structure description). So I used the NRF_GPIO_PIN_MAP() macro  to declare these SPI pin numbers.

You can see on the SPI communication traces bellow that the nRF54L15 correctly returns the Tx buffer content when using SPIS30, but MISO line stay flat when using SPIS00 intance.

Any idea if I missed something in the project configuration ?

SPI transfer with SPIS30 instance

SPI transfer with SPIS00 instance

spis_nrf54.zip

[Kenneth]

Hi

Looking at the pin assignments information I can find there are very specific pins on Port2 that can be used by SPIS00/20, ref:
https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/chapters/pin.html 

Can you make sure to use those?

It doesn't seem as there any specific requirement for which pin that can be used as CSN though.

Kenneth

[Gregory C]

Hi Kenneth,

Thank you so much for these hints. We are progressing... Indeed, when I select the specific pins specified in the "Pin assignments" chapter of the datasheet I can see an activity on the SPI slave interface.

By the way, there are some mismatches in the datasheet Nordic should fix : The SPIS Peripheral - Configuration chapter specifies that SPIS00 instance can be mapped on GPIO port P2 without indicating that specific pins have to be used (at the opposite of SPIS20/21/22 instances).

Unfortunately, I am now facing another issue : as you can see on the new SPI communication trace, the SPIS peripheral only transmits ORC bytes, not the Tx buffer content. Furthermore, the NRFX_SPIS_XFER_DONE event is never triggered by the library. It looks like nrfx_spis_buffers_set command doesn't configure correctly the SPI transaction even if the returned status is NRFX_SUCCESS.

Do you have an idea what's going wrong ?

[Kenneth]

Hi,

Reading the hardware description for the SPIS I get the sense it's related to RELEASE is not done, see Figure 2:
https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/spis.html 

Can you set different value for DEF and ORC to confirm if that is the case?

Also, I assume nrfx_spis_buffers_set() is called before CSN go low.

Edit: If nothing still doesn't work, try to see if enabling constlat make any difference, ref:
#include <nrfx_power.h> 
nrfx_power_constlat_mode_request();

Kenneth

[Gregory C]

Hi,

I understand your point of view but it sounds quite strange the same code perfectly works for the SPIS30 instance and not for the SPIS00 !!!

Anyway, I changed the ORC value to 0xAA in my example and I added the following lines before initializing the SPIS driver :

---

    // Initialize the POWER module

    nrfx_power_config_t power_config = {0};

    status = nrfx_power_init(&power_config);

    NRFX_ASSERT(status == NRFX_SUCCESS);

    // Request constant latency mode

    status = nrfx_power_constlat_mode_request();

    NRFX_ASSERT(status == NRFX_SUCCESS);

---

I also enabled the nrfx POWER driver in the prj.conf

CONFIG_NRFX_POWER=y

 

But I am facing the same troubles with ORC bytes transmitted on SDO line :

Could it be a problem related to the DMA init or transfer on SPIS00 instance ?

[Kenneth]

Hello,

I updated the \v2.9.0\zephyr\tests\drivers\spi\spi_controller_peripheral\ example to use spi00 with the specified gpios, and it seems to work here. Attaching relevant files. Hope it can be of use.

Kenneth

0385.nrf54l15dk_nrf54l15_cpuapp.overlay