RE: SPI Master Slave problem with CS/NCS

Vidar Berg — Wed, 22 Jan 2025 07:31:38 GMT

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?

RE: SPI Master Slave problem with CS/NCS

MartinKeySoft — Mon, 20 Jan 2025 15:01:59 GMT

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