7usec delay seems to be required between SS and SCK on SPI Slave

RE: 7usec delay seems to be required between SS and SCK on SPI Slave

Naeem Maroof — Wed, 03 Jan 2024 13:29:00 GMT

Hello Robert,

The IFTIMING.x registers are only available on the SPIM4 instance.

I have few questions here:

What is your setup? Are you using NRF5340 as a SPI slave? What is your SPI Master? Is it a Nordic Device?

And what do you mean by this:

[quote user=""]when I try it with the external processor's SPI Master the data sent on the MOSI line isn't read correctly by the nRF5340 SPI Slave.[/quote]

What is the CSN to CLK delay you get in this case? (with external master)

[quote user=""]However, I notice about a 7 microsecond delay between the SS going low and the SCK transitions.[/quote]

your SPI master should have control on this? right?

[quote user=""]When I try my own SPI Master there's only about 70ns delay between SS and SCK.[/quote]

What do you mean here? What is "my own SPI Master" vs "External SPI Master"?

I would like to understand your overall setup. Will be nice if you could share h/w and code snapshots.

Regards, Naeem

RE: 7usec delay seems to be required between SS and SCK on SPI Slave

tozz88 — Tue, 02 Jan 2024 20:12:02 GMT

Great. Thanks for the information. However, the linked solution sounds like it only works for SPIM4 and I am using SPI Slave, not master. Is there a way to get a similar behavior for SPI Slave?

RE: 7usec delay seems to be required between SS and SCK on SPI Slave

Naeem Maroof — Tue, 02 Jan 2024 12:22:21 GMT

Hello,

[quote user="tozz88"]Your measured ~6us SS-to-SCK delay jibes with my measurements as well. I must say, I've never encountered a part before that adds 12us to every SPI transaction by design.[/quote]

Please have a look at this ticket which is pretty much same as your concern, and the suggestion from my colleague to use the SPIM4 instance: Reduce CS to CLK Delay

[quote user="tozz88"]Are you saying that I can use this field to reduce the SPI Slave device SS-to-SCK delay[/quote]

No, this is a parameter for extra delay if you want to have controlled delay for synchronization etc. As you want lower delay, you should not use it or have set it to 0.

RE: 7usec delay seems to be required between SS and SCK on SPI Slave

Maria Gilje — Wed, 27 Dec 2023 10:14:46 GMT

We are severely understaffed this week because of the Christmas holidays, and Naeem will have to get back to you on this next week.

Sorry for the inconvenience.

RE: 7usec delay seems to be required between SS and SCK on SPI Slave

tozz88 — Fri, 22 Dec 2023 18:37:33 GMT

Thank you for your timely response. I'm glad, in a way, to hear that the measured delay I am seeing is expected and not something else I have to diagnose on my side. Your measured ~6us SS-to-SCK delay jibes with my measurements as well. I must say, I've never encountered a part before that adds 12us to every SPI transaction by design.

>There is a delay parameter in the spi_cs_control struct which is part of the spi_config.

I have read the documentation on this field here Serial Peripheral Interface (SPI) Bus — Zephyr Project Documentation but it's a bit vague about how to use it and its bounds, etc. Are you saying that I can use this field to reduce the SPI Slave device SS-to-SCK delay on the nRF5340 to below 6? To 1 or even 0?

Could you provide me with an example device tree usage? Since I supplied my device tree entry in the original post if you could show how I might add spi_cs_control to that it would be fantastic.

Sadly, there is no such control on the SPI Master device side other than using a GPIO instead of the SS line and putting delays between the GPIO control and the SPI. So if there is no way to reduce the latency on your part, we'll need to rethink our design here.

Thank you for your time.

RE: 7usec delay seems to be required between SS and SCK on SPI Slave

Naeem Maroof — Fri, 22 Dec 2023 14:33:15 GMT

Hello,

Yes, there would always be delay after the CS has been enabled till the clock is enabled.

I have tested it previously and it was ~6u.

You could send multiple bytes in one transaction and see if it meets your overall requirement.

Over here:

[quote user=""].operation = SPI_WORD_SET(8)[/quote]

You are setting word size as 8 bit, so what you mean by 16 bit transfers are not detected correctly?

[quote user=""]plus the only way I can perform the delay on the SPI Master side is to replace the SS signal with a GPIO that I toggle manually[/quote]

There is a delay parameter in the spi_cs_control struct which is part of the spi_config.

/BR, Naeem