Reducing CS Low Time Before Starting SCLK in SPI Communication

[mehul_dabhi]

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?

[mehul_dabhi]

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.

[pengyong_zhang]

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

[mehul_dabhi]

Continued discussion at link

[pengyong_zhang]

Hi @mehul_dabhi 

You can disable the DMA to implementation for your needs.

B.R

[mehul_dabhi]

Hi @pengyong_zhang,

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

Regards,

Mehul

[mehul_dabhi]

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

[mehul_dabhi]

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 :

1. How does enabling DMA causes the CS pin to go high after each byte transfer?
2. 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

IMX8MPLUS 

[pengyong_zhang]

Hi @mehul_dabhi 

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

B.R

[mehul_dabhi]

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

Thanks

[pengyong_zhang]

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

[mehul_dabhi]

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

[mehul_dabhi]

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

[pengyong_zhang]

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

[mehul_dabhi]

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

[mehul_dabhi]

@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?

[pengyong_zhang]

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

[mehul_dabhi]

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

[mehul_dabhi]

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

 

[pengyong_zhang]

HI @mehul_dabhi 

Please share your captured image.

Thanks!