SPI Master Slave problem with CS/NCS

[MartinKeySoft]

Hi,

I am trying establish connection between SPI MASTER and SPI SLAVE on two boards nRF52 DK. I am using example "ncs-spi-master-slave-example" SPI Master/Slave example

SDK v2.6.0, Toolv2.6.0

pin connections:
       master board:  slave board:
MOSI:  P0.30  --->    P0.12
MISO:  P0.29  <---    P0.13                 
SCLK:  P0.31  --->    P0.11
CS/CSN:P0.28  --->    P0.14

When the SPI Master activates the CS pin and attempts to start communication, CS will be turned off at the same time as the first clock appears. This will cause the transmission to fail.

Do you have any idea what this could be? I'm attaching a log from the logic analyzer.

I tried changing the CSN to Active:Low, but without success.

My second question is whether this example works on a single board (if the appropriate pins are connected).

Martin

[MartinKeySoft]

I answer myself and ask new questions.

Only now I noticed that the pin used as CSN (P0.14) for SPI SLAVE is also used for BUTTON1. So I changed the pin assigned to BUTTON1 to unused pin (P0.02).

&button1 {
	gpios = <&gpio0 2 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
};

I also tried changing ".delay" in the configuration for SPI MASTER (spi_cfg).

static struct spi_config spi_cfg = {
	.operation = SPI_WORD_SET(8) | SPI_TRANSFER_MSB | /*SPI_MODE_CPOL | SPI_MODE_CPHA*/ SPI_OP_MODE_MASTER,
	.frequency = 1000000,
	.slave = 0,
	.cs = {.gpio = MY_SPI_MASTER_CS_DT_SPEC, .delay = 20},			// MS 0 ---> 20
};

After these changes, the example starts working, but I'm afraid that the ".delay" change is not intended for such purposes.

Is there correct solution for CS timing of the SPI MASTER? Why Button1 affects the CSN @ SPI SLAVE?

Martin

[Vidar Berg]

Thanks for the update. The CS signal must always be de-asserted after the transaction is complete. The delay sets how long to wait both before and after the transaction before asserting and de-asserting the CS signal. The scope trace you posted earlier shows that it is released way too early, which indicates that there is a problem with the configuration, but I'm not sure what it may be. Did you try to use the original pinout from the sample to see if you got the same result?