SPIS on NRF52840

RE: SPIS on NRF52840

espian — Tue, 11 Jul 2023 15:05:46 GMT

Since there are a number of people subscribed to this ticket, I will document this issue and what fixed it. Then wrap up with some other comments.

The first two things that caused me issues were that the SPI samples I was finding were using the GPIOS definitions for the CS line. In SPIS, that is not allowed. Tracing back the -EINVAL error (and properly enabling the logged message) was the trick to figuring out this first step. (You can see the result of this and the 'fix' above).

Once past this hurdle, I had mentioned multiple times that there seemed to be something that I was fundamentally missing on understanding what within SPIS actually terminated an SPI message. There is so much abstraction and so much that is 'automagically' done within the NRFSDK and Zephyr code bases, it is very difficult to know sometimes when you need to sit back and let the code-base do something for you and when you're required to handle something for yourself. To be clear, I'm not an embedded newbie. I have used SPI in designs starting in the early 1990's, so am pretty well versed in the hardware and typical software to support it. Again, my issues here were largely around the things that were abstracted away and controlled by the software libraries and how they worked.

I finally found in the Zephyr discord channel a mention that when using SPIS the driver expects to use the hardware CS line embedded in the SPI transceiver hardware and a follow-up mention of "don't forget to set your pinctrl's".

In the overlay, I added

<NRF_PSEL(SPIS_CSN, 0, 29)>

&spi1_default {

group1 {

psels = <NRF_PSEL(SPIS_SCK, 0, 31)>,

<NRF_PSEL(SPIS_MOSI, 0, 30)>,

<NRF_PSEL(SPIS_CSN, 0, 29)>,

<NRF_PSEL(SPIS_MISO, 1, 8)>;

};

And almost immediately my code started working. Simply the CS line was not 'connected' to the code and as such the end of message was never being triggered because it relies on the hardware CSN line to detect that state. I'm still not sure where in the codebase this is setup/controlled. I'm quite sure I would struggle to find it partially due to the lack of comments in the code.

The frustrating thing(s) to me about all of this (semi-rant follows):

1) I had expressed where I thought my short-coming was in my understanding (not know what or how an SPI message was terminated) and yet support never seemed to completely read through my messages and information to answer those specific questions.

2) I feel like I went to great lengths to document as much as I could, what I perceived the issues to be and yet, the postings were never read in detail and responded to in a manner that took that information fully into account.

3) There were multiple times that I posted follow-ups and yet the support responses continued to not respond to the most recent postings, but rather something further up the message thread (again not reading everything provided).

4) So much of this codebase is horribly documented. For instance, the spi_nrfx_spis.c file has zero comments (besides the copyright header) throughout 320 lines of code. The comments sprinkled throughout other code files are equally bland--often just describing what an if statement is testing for (well, I can plainly see that) but rarely going into the 'why' .

5) The sample code often has almost no comments within it, as well. It seems like by taking the time to document some of this better, people would be much more likely to diagnose their own issues without bothering Nordic support. (Zero comments in the master-slave sample code or overlay)

6) For both Nordic and Zephyr, if what you are wanting to do is largely in the mainstream, there are often samples that can be leveraged to allow you to develop fairly quickly, often without fully understanding everything that is going on under the hood. If anything that you're working on is outside of the most common use-cases, it can be super difficult to almost reverse engineer what's going on to utilize the libraries properly, partially do to lack of proper documentation/examples/comments and partially due to the level of abstraction going on.

7) The Zephyr docs can be downright horrible. Click on a library documentation and it's largely a list of function prototypes--this is not support documentation, I can read the code myself.

8). I know many people that are much more accomplished and competent software/firmware developers than myself. EVERYONE of them that have used the Nordic/Zephyr code bases had talked about how absolutely painful it is to learn these platforms. Often times representing months of efforts to go up the learning curve to be somewhat proficient. This simply shouldn't be so painful.

Good luck!

RE: SPIS on NRF52840

Naeem Maroof — Fri, 07 Jul 2023 16:39:10 GMT

Hello,

[quote user="espian"]If you are referring to the sample master-slave code example, I had posted that it was, in fact, operating properly, and that I was returning to dealing with the initial issues that I had posted about.[/quote]

Yes, I was referring to the sample code (master/slave) and use with the DK.

I did not test with your code, or with other boards.

[quote user="espian"]I actually just found a major reason for it,[/quote]

Good that you that you found the issue.

RE: SPIS on NRF52840

espian — Thu, 06 Jul 2023 17:08:21 GMT

What issue have you not been able to replicate?

If you are referring to the sample master-slave code example, I had posted that it was, in fact, operating properly, and that I was returning to dealing with the initial issues that I had posted about.

Are you referring to the code and overlay that I followed up with, above? That code has issues and definitely reacts the way I've described. I actually just found a major reason for it, but have not had time to post the reason and the fix.

RE: SPIS on NRF52840

Naeem Maroof — Thu, 06 Jul 2023 16:02:35 GMT

Hi Keith,

Sorry for the delayed response

I am note able to reproduce the issue that you are having.

Are you able to compile and run the sample correctly?

Can you send a complete zip folder which I could build for nrf52840dk to reproduce the error you are having?

If there are any other special considerations, do let me know as well.

RE: SPIS on NRF52840

espian — Mon, 03 Jul 2023 14:17:30 GMT

Naeem,

Any further thoughts?

Thanks,

Keith

RE: SPIS on NRF52840

espian — Wed, 28 Jun 2023 14:22:09 GMT

I did fix a couple of items in my original code. However, the issue remains that the call back function is never called. I have changed the buffer size up and down to check for impact there and nothing. It doesn't seem to matter if I underflow, overflow, or perfectly match the buffer size with the spi incoming data, the cb is never called.

I'm still not clear as to what triggers the 'end' of an spi transaction in the driver and I suspect that is the fundamental issue that I'm having.

I've included everything that I can think of below. The GPIO registers, the code properly waits for the cs line to go active (low) and then beings the spi call back setup, pauses and then waits.

Thanks for having a look.

Here is my full current code:

#include <zephyr/kernel.h>
#include <zephyr/device.h>
#include <zephyr/dt-bindings/gpio/gpio.h>
#include <zephyr/devicetree.h>
#include <zephyr/drivers/spi.h>
#include <nrfx_spis.h>
#include <zephyr/logging/log.h>

// #define NRFX_LOG_MODULE MY_CODE
// #include <nrfx_log.h>

LOG_MODULE_REGISTER(my_module);

#define SPI_DEVICE_NAME "my_spis"
#define BUFFER_SIZE 1
static uint8_t buffer[BUFFER_SIZE] = {0};
// static uint8_t ack_message[] = "ACK";

static struct k_poll_signal spi_slave_done_sig = K_POLL_SIGNAL_INITIALIZER(spi_slave_done_sig);

static struct device *spi_dev;

static struct spi_config spi_cfg = {
	.operation = SPI_WORD_SET(8) | SPI_OP_MODE_SLAVE | SPI_TRANSFER_MSB |
				 SPI_LINES_SINGLE,
	.frequency = 1000000,
	.slave = 0,
};

#define MY_SPIS DT_NODELABEL(my_spis)
const struct device *gpio_dev;
#define CS_GPIO_NODE DT_NODELABEL(cs_gpio)
const struct device *gpio_dev = DEVICE_DT_GET(CS_GPIO_NODE);
const uint32_t cs_pin = 29;

void spi_slave_callback(const struct device *dev, int result, void *data)
{
	// Check for errors in the result
	if (result < 0)
	{
		printk("SPI transaction failed with error code %d\n", result);
		return;
	}

	// Print the received data
	printk("Received data: ");
	for (int i = 0; i < BUFFER_SIZE; i++)
	{
		printk("%02x ", buffer[i]);
	}

	printk("\n");

	// Print the result of the SPI transaction
	k_poll_signal_raise(&spi_slave_done_sig, result);
	printk("SPI transaction completed with status %d\n", result);
}

static int spi_begin_transaction(struct device *spi_dev, const struct spi_buf_set *rx)
{
	int err;
	printk("In spi_check_for_message. \n");
	k_poll_signal_reset(&spi_slave_done_sig);
	__asm__ volatile("nop");
	err = spi_transceive_cb(spi_dev, &spi_cfg, NULL, rx, spi_slave_callback, &spi_slave_done_sig);
	__asm__ volatile("nop");
	printk("Out of spi_transceive_cb\n RET: %d\n", err);
	return (err);
}

static int spi_slave_check_for_message(void)
{
	int signaled, result;
	k_poll_signal_check(&spi_slave_done_sig, &signaled, &result);
	if (signaled != 0)
	{
		return 0;
	}
	else
		return -1;
}

void main(void)
{

	static int err, loop_count;

	// log_init();

	printk("Entering Main\n");


	if (!device_is_ready(gpio_dev))
	{
		printk("Device not ready.\n");
		return;
	}

	spi_dev = DEVICE_DT_GET(DT_NODELABEL(my_spis));
	if (!spi_dev)
	{
		printk("Could not find %s!\n", SPI_DEVICE_NAME);
		return;
	}

	printk("Found %s!\n", SPI_DEVICE_NAME);

	spi_cfg.cs = NULL;

	/* configure the pin as input */
	int ret = gpio_pin_configure(gpio_dev, cs_pin, GPIO_INPUT);
	if (ret != 0)
	{
		printk("Didn't configure pin.\n");
		/* handle error */
	}

	if (!device_is_ready(spi_dev))
	{
		printk("SPI device not ready \n");
	}
	else
	{
		printk("SPI device ready \n");
	}

	LOG_ERR("Test Error Message to confirm log works\n");
	loop_count = 0;
	while (1)
	{
		// printk("Loop %d\n", loop_count++);
		const struct spi_buf rx_buf = {
			.buf = buffer,
			.len = BUFFER_SIZE,
		};
		const struct spi_buf_set rx = {
			.buffers = &rx_buf,
			.count = 1,
		};
		/*
				const struct spi_buf tx_buf = {
					.buf = buffer,
					.len = BUFFER_SIZE,
				};
				const struct spi_buf_set tx = {
					.buffers = &tx_buf,
					.count = 1,
				};
		*/

		// LOG_ERR("About to Call pin_get\n");
		int cs_state = gpio_pin_get(gpio_dev, cs_pin);
		// LOG_ERR("Just after calling pin_get\n");
		if (cs_state < 0)
		{
			printk("error in reading cs pin state.\n"); /* handle error */
		}
		else if (cs_state == 0)
		{
			//cs is active so, begin transaction and setup callback and then wait for callback to be called.
			err = spi_begin_transaction(spi_dev, &rx);
			printk("Starting Wait. \n");

			k_msleep(1);
			printk("Done waiting. \n");
			/* CS line is active, ready to transceive data */
			printk("waiting... ");
			do
			{
				err = spi_slave_check_for_message();
				printk(".");
			} while (err < 0);
			printk("\n");
			printk("Received data: ");
			for (int i = 0; i < BUFFER_SIZE; i++)
			{
				printk("%02x ", buffer[i]);
			}

			printk("\n");
		}

		else
		{

			__asm__ volatile("nop");
		}

		if (err < 0)
		{
			printk("SPI transceive error: %d\n", err);
		}
	}
}

Here is the current proj.conf:

CONFIG_GPIO=y

CONFIG_SPI=y
CONFIG_SPI_ASYNC=y

CONFIG_SPI_SLAVE=y
# nothing here
#CONFIG_SPI=y
#CONFIG_GPIO=y
#CONFIG_GPIO_NRFX=y
#CONFIG_SPI_SLAVE=y
#CONFIG_SPI_ASYNC=y
CONFIG_DEBUG=y
#CONFIG_PRINTK=y
#CONFIG_LOG_PRINTK=y
CONFIG_LOG_MODE_IMMEDIATE=y
#CONFIG_NRFX_SPIS1=y
#CONFIG_USERSPACE=n
CONFIG_LOG=y
#CONFIG_LOG_BACKEND_RTT=n
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_PRINTK=y
CONFIG_LOG_DEFAULT_LEVEL=4 
CONFIG_UART_CONSOLE=y
#CONFIG_PM=n

#CONFIG_STACK_SENTINEL=y




#CONFIG_HEAP_MEM_POOL_SIZE=50512
#CONFIG_IDLE_STACK_SIZE=2048
#CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
#CONFIG_MAIN_STACK_SIZE=8192



#CONFIG_USE_SEGGER_RTT=n
#CONFIG_RTT_CONSOLE=n
CONFIG_SERIAL=y

Here is a copy of the console output:

Here is a screen shot of the logic analyzer capture feeding the dk:

RE: SPIS on NRF52840

espian — Wed, 28 Jun 2023 13:15:51 GMT

I'm quite sure that the sample code is running properly. However, I'm not going to see the UART output.

I'm using a Fanstel eval kit (which is almost a carbon copy of the NRF52840DK), however the Fanstel module that is mounted on my board (BT840X) does not expose UART0 because it uses that on-module to control a PA. This was very non-obvious and only mentioned in one line in their data sheet.

I'm going to go back up in this thread to the actual issue/question as my CB is never being called. I'll post more code related to that soon.

RE: SPIS on NRF52840

Naeem Maroof — Tue, 27 Jun 2023 10:34:47 GMT

[quote user="espian"]I get a toggling LED, as expected from the code. However, I can not see any of the printk messages.[/quote]

I am using the same sample for 52840DK and I can see the messages on console (printing both messages on the same line).

[quote user="espian"] 1) changing several of the printk's to printf's[/quote]

What do you mean by this? printk() is zephyr kernel function, and is supposed to be used with ncs/zephyr for console messages.

It is also important that you connect to the correct serial port.

RE: SPIS on NRF52840

espian — Mon, 26 Jun 2023 16:58:02 GMT

My last set of comments were with the GitHub master slave code with the only change being 1) changing several of the printk's to printf's and 2) the above changes to the proj.conf file.

RE: SPIS on NRF52840

Naeem Maroof — Mon, 26 Jun 2023 14:36:20 GMT

[quote user="espian"]As soon as I modify the proj.conf file so that I can see the printk output, I start having issues. [/quote]

I am not sure why such is happening.

can you send your minimal project, just enough to show what you are facing. Please strip it down to minimal version just to show the functionality and error.

RE: SPIS on NRF52840

espian — Fri, 23 Jun 2023 14:06:03 GMT

Ok, here are some interesting results.

I started a new project and pulled in the files from the master/slave GitHub repository (including the proj.conf file). Modify nothing, build, and flash. I get a toggling LED, as expected from the code. However, I can not see any of the printk messages.

As soon as I modify the proj.conf file so that I can see the printk output, I start having issues. Here is the output:

[00:00:00.249,93[00:00:00.250,244] <dbg> mpu: region_init: [2] 0x20012000 0x150b000a
SPI master/slave example started
--- 37 messages dropped ---
SPI SLAVE TX: 0x00, 0x00
SPI TX: 0x00, 0x00
[00:00:00.250,427] <dbg> spi_nrfx_spim: spi_context_buffers_setup: tx_bufs 0x20012fc8 - rx_bufs 0x20012fb8 - 1
[00:00:00.250,457] <dbg> spi_nrfx_spim: spi_context_buffers_setup: current_tx 0x20012fd0 (1), current_rx 0x20012fc0 (1), tx buf/len 0x200007e4/2, rx buf/len 0x200007e0/2
[00:00:00.250,488] <dbg> spi_nrfx_spim: spi_context_update_tx: tx buf/len (nil)/0
[00:00:00.250,518] <dbg> spi_nrfx_spim: spi_context_update_rx: rx buf/len (nil)/0
[00:00:00.250,549] <dbg> spi_nrfx_spim: finish_transaction: Transaction finished with status 0
SPI RX: 0x00, 0x00
[00:00:00.250,640] <dbg> os: z_tick_sleep: thread 0x20000600 for 32768 ticks
[00:00:00.250,671] <dbg> mpu: z_arm_configure_dynamic_mpu_regions: configure thread 0x20000000's domain
[00:00:00.250,701] <dbg> mpu: z_arm_configure_dynamic_mpu_regions: configure domain: 0x20001448
[00:00:00.250,701] <dbg> mpu: z_arm_configure_dynamic_mpu_regions: configure domain: 0x20001448
[00:00:00.250,732] <dbg> mpu: z_arm_configure_dynamic_mpu_regions: configure user thread 0x20000000's context
[00:00:00.250,762] <dbg> mpu: mpu_configure_region: Configure MPU region at index 0x2
[00:00:00.250,793] <dbg> mpu: region_allocate_and_init: Program MPU region at index 0x2
[00:00:00.250,793] <dbg> mpu: region_init: [2] 0x20002000 0x150b000a
[00:00:00.249,938] <dbg> mpu: mpu_configure_region: Configure MPU region at index 0x2
[00:00:00.250,976] <err> os: ***** MPU FAULT *****
[00:00:00.251,007] <err> os:   Data Access Violation
[00:00:00.251,007] <err> os:   MMFAR Address: 0x20002010
[00:00:00.251,037] <err> os: r0/a1:  0x200020e0  r1/a2:  0x0000001c  r2/a3:  0x00000000
[00:00:00.251,068] <err> os: r3/a4:  0x20002094 r12/ip:  0x0000000e r14/lr:  0x0000258f
[00:00:00.251,068] <err> os:  xpsr:  0x01000000
[00:00:00.251,098] <err> os: Faulting instruction address (r15/pc): 0x00000bda
[00:00:00.251,159] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
[00:00:00.251,190] <err> os: Current thread: 0x20000000 (logging)
[00:00:01.086,059] <err> os: Halting system

Here is the modified proj.conf file:

CONFIG_GPIO=y

CONFIG_SPI=y
CONFIG_SPI_ASYNC=y

CONFIG_SPI_SLAVE=y

CONFIG_DEBUG=y
CONFIG_PRINTK=y
#CONFIG_NRFX_SPIS1=y
CONFIG_USERSPACE=y
CONFIG_UART_CONSOLE=n
CONFIG_LOG=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_PRINTK=y
CONFIG_LOG_DEFAULT_LEVEL=4 
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_SERIAL=y

CONFIG_HEAP_MEM_POOL_SIZE=50512
CONFIG_IDLE_STACK_SIZE=4096
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_MAIN_STACK_SIZE=4096

I had also tried a version to route the console to the UART, but was still not seeing output (am connected to UART0, UART0 is enabled and connected to the console per the dts file, UART1 is disabled per the overlay).

RE: SPIS on NRF52840

Naeem Maroof — Thu, 22 Jun 2023 10:29:17 GMT

Hi,

I am not sure why it is happening like this, while the code looks pretty much same like the SPI Master/Slave Sample.

Have you tested the sample? Can you start with that and then modify / incorporate the changes you want.

RE: SPIS on NRF52840

espian — Wed, 21 Jun 2023 18:29:06 GMT

More information.....

I changed my code to operate similar to the master/slave SPI example that is referenced in various Nordic SPI threads: NCS spi master/slave example

In particular, adding in the kpoll method to watch for spi transaction completion. Here are a couple of code snippets:

	k_poll_signal_reset(&spi_slave_done_sig);
	__asm__ volatile("nop");
	err = spi_transceive_cb(spi_dev, &spi_cfg, NULL, &rx, spi_slave_callback, &spi_slave_done_sig);
	__asm__ volatile("nop");
	printf("Out of spi_transceive_cb\n RET: %d\n", err);
	return (err);

.................

			printf("waiting... ");
			do
			{
				err = spi_slave_check_for_message();
			    printf(".");
			} while (err < 0);
			printf("\n");
			
.......................

static int spi_slave_check_for_message(void)
{
	int signaled, result;
	k_poll_signal_check(&spi_slave_done_sig, &signaled, &result);
	if (signaled != 0)
	{
		return 0;
	}
	else
		return -1;
}

The code/device sits and waits for the cs line to drop. Once that happens the kpoll reset occurs and spi_transceive_cb is called as shown. Then the code goes into the do while loop to look for completion of the SPI reception. The completion never occurs and the device keeps printing '.' 's to the console. It doesn't matter if I underflow the transmission, have it match the buffer definition exactly (8 bytes) or overflow, the spi reception never 'completes'.

It seems as though I'm missing something very fundamental here. Thank you in advance for any insights.

RE: SPIS on NRF52840

espian — Wed, 21 Jun 2023 13:56:51 GMT

Thank you for confirming this.

I have code that now manually monitors a cs line and triggers a call to spi_transceive_cb. (see below). The first SPI transaction calls spi_transceive_cb and it returns a zero. The second transaction throws up some debug messages from the MPU module (see further below). In both cases I never see output from my callback function.

I'll continue to debug on this, but if there is something obvious that I'm not doing correctly, please let me know.

I have verified with a logic analyzer that the SPI transmission to the NRF are happening correctly.

struct spi_config spi_cfg = {
	.operation = SPI_WORD_SET(8) | SPI_OP_MODE_SLAVE | SPI_TRANSFER_MSB |
				 SPI_LINES_SINGLE,
	.frequency = 4000000,
	.slave = 0,
};

...................

while (1)
	{
		//printf("Loop %d\n", loop_count++);
		const struct spi_buf rx_buf = {
			.buf = buffer,
			.len = BUFFER_SIZE,
		};
		const struct spi_buf_set rx = {
			.buffers = &rx_buf,
			.count = 1,
		};
		/*
				const struct spi_buf tx_buf = {
					.buf = buffer,
					.len = BUFFER_SIZE,
				};
				const struct spi_buf_set tx = {
					.buffers = &tx_buf,
					.count = 1,
				};
		*/
		// receive data packet
		//LOG_ERR("About to Call pin_get\n");
		int cs_state = gpio_pin_get(gpio_dev, cs_pin);
		//LOG_ERR("Just after calling pin_get\n");
		if (cs_state < 0)
		{
			printf("error in reading cs pin state.\n"); /* handle error */
		}
		else if (cs_state == 0)
		{
			__asm__ volatile("nop");
			err = spi_transceive_cb(spi_dev, &spi_cfg, NULL, &rx, spi_slave_callback, NULL);
			__asm__ volatile("nop");
			printf("Out of spi_transceive_cb\n RET: %d\n", err);
			/* CS line is active, ready to transceive data */
		}
		else
		{
			/* CS line is not active */
			__asm__ volatile("nop");
		}

		if (err < 0)
		{
			printf("SPI transceive error: %d\n", err);
		}
	}

Here is the callback:

void spi_slave_callback(const struct device *dev, int result, void *data)
{
	// Check for errors in the result
	if (result < 0)
	{
		printf("SPI transaction failed with error code %d\n", result);
		return;
	}

	// Check if the buffer contains data
	if (buffer == NULL || BUFFER_SIZE == 0)
	{
		printf("Buffer is empty or not initialized\n");
		return;
	}

	// Print the received data
	printf("Received data: ");
	for (int i = 0; i < BUFFER_SIZE; i++)
	{
		printf("%02x ", buffer[i]);
	}

	printf("\n");

	// Print the result of the SPI transaction
	printf("SPI transaction completed with status %d\n", result);
}

Here is the console output:

Out of spi_transceive_cb

RET: 0

[00:00:35.624,877] <dbg> mpu: mpu_configure_region: Configure MPU region at index 0x2

[00:00:35.633,087] <dbg> mpu: region_allocate_and_init: Program MPU region at index 0x2

[00:00:35.641,510] <dbg> mpu: region_init: [2] 0x200015c0 0x150b000a

RE: SPIS on NRF52840

Naeem Maroof — Tue, 20 Jun 2023 12:35:01 GMT

Hi Keith,

Thank you for being patient.

Device yaml files define the device bindings and that can be used as guidelines for writing overlays.

If some properties are marked as required, then those must be define in the DT overlays for those devices.

As you are using nordic spis driver, looking at the driver code suggests the same what you were referring to.

The spi_nrfx_transceive function, under the hood, calls transceive function which in turn calls device configure (configure(dev,spi_cfg)) function. If, in calling transceive from nrf_spis driver, spi_cfg->cs is defined then it would return error. So definitely, putting NULL in the cs should resolve this issue.

RE: SPIS on NRF52840

Naeem Maroof — Mon, 19 Jun 2023 15:21:55 GMT

Hi Keith,

Thank you for contacting DevZone at NordicSemi.

I have been assigned this ticket and I did not get a chance to look at it.

I will come back to it tomorrow.

Regards,

Naeem

RE: SPIS on NRF52840

espian — Mon, 19 Jun 2023 13:27:16 GMT

As I understand this now, the SPI Slave code does not support monitoring a GPIO line assigned as a CS control line. This is still a bit opaque from the zephyr and other documentation.

Passing a NULL value into spi_cfg.cs allows the spi_transceive_cb to be called without an immediate error being thrown.

I'm in the process of manually checking for the state of a cs line and should have some more code ready test later today.

Does anyone know if there is a decent write-up on the SPI support software and its functionality for NRF running zephyr?

RE: SPIS on NRF52840

espian — Sun, 18 Jun 2023 02:37:23 GMT

Ok, I have the log information now going. The -EINVAL is from this error message: spi_nrfx_spis: CS control via GPIO is not supported

I am assuming at this point that something in my overlay is not quite right with regards to the CS definition. This information should be in the previous post.

Thanks in advance for any thoughts.

-Keith