AM623: SPI Chip select taking longer time to deactivate

The MCSPI Switching Characteristics table in the AM62x datasheet needs to be updated to include more accurate table notes that defines parameters SM8 and SM9. The next revision of the AM62x datasheet will include the same notes that can be found in the MCSPI Switching Characteristics table of the AM62Ax datasheet. Please review the table notes in the AM62Ax datasheet to see if that helps resolve your issue.

Regards,
Paul

Thanks for the reply. 

The Internal SPI clock is 50 MHz and I'm using 6.25 Mhz for SPI frequency, the SPI clock divider is 8 (Fratio). TCS (from SPI_CH(i)CONF register) is 0.

TSPICLKREF=1/Internal SPI clock frequency​=1/50 MHz​=20 ns.

P=160ns (SPI Freq = 6.25Mhz)

A = (TCS + 0.5) * Fratio * TSPICLKREF

A = (0+0.5)*8 *20ns = 80ns

SM8 = 80ns - 4 = 76ns

B= (0+0.5) *8*20ns = 80ns

SM9 = 80ns - 4 = 76ns

According to calculation above, I suppose to get 76ns for the SPIn_CSi delay time for SM8 or SM9, is my calculation above correct? may i know why i got 3uS for the spi chip select delay instead of 76ns? Any mistake here? How can i shorten the SPI chip select time?

Hello yen mei goh

Thank you for the inputs.

I am reviewing the inputs and will update you.

Regards,

Sreenivasa

Hello yen mei goh

I have a few additional questions.

Is this a custom board.  Can you share the connection information.

Are you observing this issue on a specific device or on multiple devices.

Would it be possible for you to share a scope picture of the observation.

Regards,

Sreenivasa

Yes, this is custom board that having SPI 0 connected to a SPI device. In fact, I have only 1 spi device connected to this SPI0 and I noticed that this TCS only applicable to multiple channels as stated in section 12.2.3.4.3.7, where MCSPI_MODULCTRL(0) SINGLE bit needs to be 0 (multiple channels). Hence, I have added few more spi devices into DTS as shown in picture below. However, when I read back the SINGLE register bit, it's always set to 1. Any idea? How to change it to multiple channels? Could it impact the chip select timing control? Any mistake here that causing the chip select taking that long?

DTS:

Here is my scope capture:

Hello yen mei goh

Thank you.

Checking if it would be possible for you to share the schematics of the SoC and attached device connections?

Regards,

Sreenivasa

yen mei goh

Are you using the SPI controlled CS or software controlled CS?   Can you give us the value of the CS2 padconfig register? 

--Paul 

I suppose it should be SPI controlled CS. 

PadConfig register

This is the value of the CS2 padconfig register:

devmem2 0xF41D0h

0x0000 0001

This is my schematic connection for my spi device

Hello yen mei goh

Can you please confirm if you have a 22 R resistor on the SPI0_CLK output signal.

Regards,

Sreenivasa

Hi,

Yes, there are 47 Ohm resistor on my SPI0_CLK, MOSI and CS.

Below are the CLK and chip select measurement using scope:

SPI0_CLK:

SPI0_CS:

yen mei goh

Thanks for the padconfig value a confirming SPI0_CS2  is the mux mode selected.  

From your previous comments, looks like you are using Linux, correct? I will check with the software team on how they control the SPI CS signals 

Could you provided the dump of the SPI0 registers? 

--Paul 

Yes, I'm using Linux. Below are the spi registers values for channel 2 with 200K speed for experiment purpose:

:

Hello Paul,

Thank you for the query.

I copied the previous query customer had in one of the previous message. Any suggestion on how this could be set to multiple channel?

Yes, this is custom board that having SPI 0 connected to a SPI device. In fact, I have only 1 spi device connected to this SPI0 and I noticed that this TCS only applicable to multiple channels as stated in section 12.2.3.4.3.7, where MCSPI_MODULCTRL(0) SINGLE bit needs to be 0 (multiple channels). Hence, I have added few more spi devices into DTS as shown in picture below. However, when I read back the SINGLE register bit, it's always set to 1. Any idea? How to change it to multiple channels? Could it impact the chip select timing control? Any mistake here that causing the chip select taking that long?

DTS:

Regards,

Sreenivasa

Hello yen mei goh

I will Reassign the thread to the Linux expert to provide support on setting interface to multiple channel

Regards,

Sreenivasa

I understand that the goal is to use device-hardware to control the SPI chip select behavior. The current Linux driver uses the FORCE bit to assert and keep SPIEN active between SPI words, and does not have any capability to let the hardware control this signal based on SPI activity. Besides this, if I read the TRM correctly the SPI-module driven SPIEN handling only seems to be applicable for single-word transfers (meaning up to 32 bits at a time), which does not seem all that useful as typically SPI transfers are much longer than that.

If you need tight control over the SPI timing behavior you might want to consider using one of the PRU cores to drive the signals, or perhaps control the SPI module from the M4 core.

Regards, Andreas

Yes, I highly suspected this is due to single channel mode too, but i can't change it to multi channel mode, any idea how to change to multi channel mode?

According to TRM, if it's using multi channel mode, the SPIEN is controlled by HW, so currently the TI SPI driver does not support that? We need to modify the TI driver to support that? I need the fast de-assertion of the SPIEN, currently, the SPIEN takes 3-4uS to de-assert, however, usually HW-controlled SPIEN will only take less than 100ns.