topic Re: Reducing CS Low Time Before Starting SCLK in SPI Communication in i.MX Processors

Reducing CS Low Time Before Starting SCLK in SPI Communication

mehul_dabhi — Fri, 27 Dec 2024 07:08:09 GMT

I am using the i.MX8MP SoC and have configured the SPI frequency to 25 MHz and am writing 24-bit data. However, I am observing an extended CS (Chip Select) low time of approximately 2.2 µs before the SCLK (Serial Clock) starts, as seen in the captured image.

What steps can I take to reduce the CS low time before the SCLK begins? Any guidance or suggestions?

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

pengyong_zhang — Mon, 30 Dec 2024 05:16:07 GMT

HI @mehul_dabhi

Please share your captured image.

Thanks!

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

mehul_dabhi — Mon, 30 Dec 2024 07:31:25 GMT

Hi @pengyong_zhang ,

I have attached the the waveform image below, the signal in yellow is CS gpio and the blue one is SCK of SPI.

I also tried configuring the cs_setup delay from spi_device structure but it too does not lead to any improvements. I have to write around 300K samples in a sec to a DAC and if this delay persists this will become an impossible thing for me to do.

Thanks,

Mehul

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

pengyong_zhang — Tue, 31 Dec 2024 07:55:03 GMT

Hi @mehul_dabhi

Firstly, Do not use GPIO as CS ctrl, Then you can use the ECSPIx_PERIODREG (CSD_CTL) control the Chip Select Delay.

B.R

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

mehul_dabhi — Tue, 31 Dec 2024 10:07:56 GMT

Hi @pengyong_zhang

I removed the cs-gpios property from the device tree node and have been able to bring down the delay. But what happens is I am trying to transmit 24 bits of data and CS should remain low until all the bits are transferred rather the CS goes high after each transfer of 8-bit. I also tried configuring cs_change to 0 from spi_transfer structure but no improvement with that too. Below is the attached snap.

Thanks
Mehul

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

pengyong_zhang — Thu, 02 Jan 2025 01:44:55 GMT

Hi @mehul_dabhi

But what happens is I am trying to transmit 24 bits of data and CS should remain low until all the bits are transferred rather the CS goes high after each transfer of 8-bit

>>>As long as you don't use gpio to control cs, it's like this. It is normal.

B.R

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

mehul_dabhi — Thu, 02 Jan 2025 07:21:45 GMT

Hi @pengyong_zhang

I want to write samples to DAC continuously over SPI having data and register command lengths of 24 bits. The max frequency supported by DAC is 35MHz and I want to write counts at every us interval.

Now when I use gpio to control CS (i.e. cs-gpios property in dts) I observe a delay of ~2us between CS assertion and SCLK availability for data transfer.

If I use native CS (i.e. do not mention cs-gpios in dts) it goes high for every bits per word transfer (in my case 8-bits).

Also as per reference manual I should be able to transmit 512 bytes in single transfer, but in my case I am unable to transmit 3-bytes in single transfer.

Then how can I achieve my requirement? What is your suggestion/guidance?

FYI I am working on kernel version 6.1.36

Thanks,
Mehul

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

mehul_dabhi — Thu, 02 Jan 2025 09:56:27 GMT

@pengyong_zhang, I could not edit my previous reply so replying on my previous comment.

I am interfacing DAC to ecspi2 and I have gathered following understanding from the reference manual of imx8mp.

With the configuration of ECSPIx_CONREG[SMC] =1, I can immediately start the SPI transfer once the data is in TxFIFO and with ECSPIx_CONFIGREG[SS_CTL] = 0, the data should be transferred without the asserting the CS between the consecutive bursts until the ECSPIx_CONREG[BURST_LENGTH] is transferred . Below are the snaps for this.

Based on this theory we have selected and designed the hardware. So as I mentioned in my previous comment what can be done to meet my requirement? Or is there some problem with the reference manual? Or have I misunderstood something?

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

pengyong_zhang — Fri, 03 Jan 2025 06:01:04 GMT

Hi @mehul_dabhi

I think you are right. you can config the register SS_CTL bit to meet your requirement. But i think you should keep ECSPIx_CONREG[SMC] clear, And writing a 1 to XCH bit starts one SPI burst or multiple SPI bursts according to the SPI SS Wave Form Select (SS_CTL)

B.R

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

mehul_dabhi — Fri, 03 Jan 2025 09:20:47 GMT

Thanks for the response @pengyong_zhang.

I have configured following register bits :

SS_CTL = 0
SMC =0 (also tried setting it to 1 and handle XCH accordingly)
BURST_LENGTH = 7 (for 8-bits and even tried setting it to 0x017 for 24 bits)

With the above configurations I still am facing problem of CS assertion at every byte transfer, so what have I done wrong here and have I missed something within the configurations?

Thanks,
Mehul

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

mehul_dabhi — Tue, 07 Jan 2025 07:03:13 GMT

Hi @pengyong_zhang

I still am facing the issue and have tried the above configurations for trying to make it work. I could use some guidance about what I am doing wrong here to resolve this issue.

Thanks,

Mehul

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

pengyong_zhang — Tue, 07 Jan 2025 07:30:07 GMT

Hi @mehul_dabhi

Working on your this request. and will give you the feedback ASAP.

B.R

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

mehul_dabhi — Tue, 07 Jan 2025 11:10:56 GMT

Ok @pengyong_zhang, I will be looking forward for your response

Thanks

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

pengyong_zhang — Wed, 08 Jan 2025 01:45:36 GMT

Hi @mehul_dabhi

You can disable the DMA to implementation for your needs.

B.R

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

mehul_dabhi — Thu, 09 Jan 2025 10:15:31 GMT

Hi @pengyong_zhang,

Thanks for the timely response. I will test this and report the results here.

Regards,

Mehul

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

mehul_dabhi — Fri, 10 Jan 2025 13:26:30 GMT

Hi @pengyong_zhang,

I have faced a setback for my hardware setup and I will be on leave for next week. So my response to your suggestion will be a bit delayed but will surely post the results whenever I test it.

Thanks,

Mehul

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

mehul_dabhi — Mon, 20 Jan 2025 12:10:00 GMT

Hi @pengyong_zhang,

I followed your suggestion and disabled DMA as a result I have been able to get the delay lowered down to around ~500ns for 1MHz I have attached the snap of it.

But I have following questions :

How does enabling DMA causes the CS pin to go high after each byte transfer?
The project that I am working on also has ADC interfaced to SPI (not the same bus as DAC). So communicating continuously to both ADC and DAC for high sample rates will burden the CPU a lot. For this reason I was thinking of forcing DMA for every transaction over SPI. With your current solution I will not be able to do that. So, is there any way to get this issue resolved with DMA enabled? If not, what can I do to lower the burden from CPU?

Thanks,
Mehul

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

pengyong_zhang — Tue, 21 Jan 2025 01:51:37 GMT

Hi @mehul_dabhi

I think if you must use DMA transfer, You can refer the spidev_test, It depends on your test code. And BTW, i will in spring festival for a long time, If you have any question, you can create a new ticket.

B.R

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

mehul_dabhi — Mon, 27 Jan 2025 11:16:26 GMT

Continued discussion at link

Re: Reducing CS Low Time Before Starting SCLK in SPI Communication

mehul_dabhi — Fri, 28 Feb 2025 11:21:49 GMT

Hi @pengyong_zhang ,

Also, when using HW CS pin, we are observing the high CS idle time of around ~3.4us
I am attaching the snap for the same; kindly look into it.