Zephyr nrf5340 cpu app SPI1 burst read missing byte

Can you take a look at this example for comparison?
https://devzone.nordicsemi.com/f/nordic-q-a/67065/how-to-configure-and-setup-an-spi-device-to-nrf5340/275002#275002

Best regards,
Kenneth

Hi 

I have compared but my issue  is not related with spi configuration or building errors.

I can successfully communicate with adxl362. My issue is if I try 1 byte tx follows multi byte (n bytes) rx transaction with " spi_transceive_dt" function , Rx part clocked out  as 1 byte less, n-1.  When I debug with jlink I can see that AMOUNT and MAXCNT set as n-1 

So some how zephyr spi driver  altering my rx count setting from n to n-1. If I set rxbuf as n+1  to read n bytes , zephyr driver modifies n+1 to n so I can get n bytes. But this bugs me because I need reason why zephyr driver trims my rxbuf lenght,/count.

The issue is not seen for 2 byte tx and n byte rx .

Thanks.

Are you able to provide some simple project I may run on an nRF5340-DK that I can run to replicate this? I assume the adxl362 is not needed to show the problem. 

Just to avoid any confusion , I assume you understand that the amount register will be set to the length of rxbuf or txbuf, whichever is longest, and not an addition of the two. This because the two buffers run in paralell and not after eachother.

Kenneth

Are you able to provide some simple project I may run on an nRF5340-DK that I can run to replicate this? I assume the adxl362 is not needed to show the problem. 

Just to avoid any confusion , I assume you understand that the amount register will be set to the length of rxbuf or txbuf, whichever is longest, and not an addition of the two. This because the two buffers run in paralell and not after eachother.

Kenneth

user2111 said:

This because the two buffers run in paralell and not after eachother.

i will create small project but , i think you have already clarified it.

this 

spi_transceive(spec->bus, &spec->config, tx_bufs, rx_bufs);

Previous projects with SES, i was using this one ( not with zephyr ) and if i remember correctly , it was sending tx then getting the rx to the buffer....It was not writing to the rx buffers during the tx time. 

 	nrf_drv_spi_xfer (nrf_drv_spi_t const *const p_instance, nrf_drv_spi_xfer_desc_t const *p_xfer_desc, uint32_t flags)
 	
 	

But as you said  zephyr driver runs tx rx in parallel. (maybe even before the zephyr, those nrf spi drivers were running the buffer in parallel, i am not sure ). but i was getting only rx data in rx buffer.

Now i tested zephyr driver ,yes it overwrites the 1st rx buffer when sending the tx bytes, then overwrites to 2nd  rx buffer....and i guess if i provide only one rx buffer during the tx&rx transaction it recalculates rx count and filling rx maxcnt counter accordingly... So it divides only one rx buffer for two parts automatically...As i remember previous non zephyr drivers were not behaving like this.

If this is true, i was wondering about  huge gap between tx and rx transactions for zephyr nrf spi driver, so it means cpu switching those buffer arrays between &tx and &rx transactions.... as i remember it was not like that before  for sdk14-15 at least . so zephyr using something like "transaction manager" style driver i guess...

I found the driver code  and i can say they put extra buffer switch things into spi driver , so zephyr driver is not just  like nrfx_spim_xfer( , actually it still uses nrfx_spim_xfer but there is much more such as ; 

it looks like "transaction manager" stye driver.

static inline void *spi_context_get_next_buf(const struct spi_buf **current,
					     size_t *count,
					     size_t *buf_len,
					     uint8_t dfs)
{
	/* This loop skips zero-length buffers in the set, if any. */
	while (*count) {
		if (((*current)->len / dfs) != 0) {
			*buf_len = (*current)->len / dfs;
			return (*current)->buf;
		}
		++(*current);
		--(*count);
	}

	*buf_len = 0;
	return NULL;
}

		++(*current);
		--(*count);

static void event_handler(const nrfx_spim_evt_t *p_event, void *p_context)
{
	struct spi_nrfx_data *dev_data = p_context;

	if (p_event->type == NRFX_SPIM_EVENT_DONE) {
#ifdef CONFIG_SOC_NRF52832_ALLOW_SPIM_DESPITE_PAN_58
		anomaly_58_workaround_clear(dev_data);
#endif
		spi_context_update_tx(&dev_data->ctx, 1, dev_data->chunk_len);
		spi_context_update_rx(&dev_data->ctx, 1, dev_data->chunk_len);

		transfer_next_chunk(dev_data->dev);
	}
}

I think you understand what is occuring now, so I don't think there is anything I can add, but just to clarify a bit on how it works:

In SPI there is a clock signal that synchronously output/input the MOSI (from tx_buf)/MISO(to rx_buf) signals, this is done in parallel by hardware. It should always have been this, though it might have been small changes whether the entire transaction was handled in one transfer and/or on byte level depending on the software/hardware implementation. Depending on the driver/library it might have been that the above described low level buffering was masked out on higher abstraction layers (e.g. that you didn't observe that the low level hardware buffer was +1 byte).

Best regards,
Kenneth